This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/
[ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment
- Previous message (by thread): [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment
- Next message (by thread): [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jan Zorz @ go6.si
jan at go6.si
Thu Oct 7 10:41:28 CEST 2010
>> Jan Zorz and Sander Steffan have prepared a document to serve as a guide what >> the requirements should be when asking for IPv6 in a tender or contract. It >> is our intention to publish this document as a RIPE document BCP so people >> can use this as an external reference. >> >> The draft version of this document is available at >> http://www.ripe.net/ripe/draft-documents/ipv6-ict-requirements.html >> >> Your comments and feedback can be sent to the IPv6 working group mailing-list >> on ipv6-wg at ripe.net. List, chairs... I received some feedback and comments offlist, I thought to share them with the list, maybe to encourage a bit the discussion. I'm leaving out names, as I presume if this people would like to be exposed they would send response to the list and not to me directly. You know who you are, so please come forward if you like :) First comment was: >> Maybe because people do not like the idea that they will not be able >> to buy/use OSX? >> >> >> Requirements for "host" equipment >> >> Mandatory support: >> >> DHCPv6 client [RFC3315] I agree. I use Mac OSX regularly as my primary OS and can't understand what went wrong at Apple still lacking the DHCPv6 client. Do we have any mechanism to remind them about this issue? > Yes I do like the document and it's clear and simple layout. Somebody likes the document :) > Hi Jan, I have been extremly busy for some days so i havn't have time > to respond or answer but the draft where looking good I think! Another one (a bit in hurry I presume). > Ok, since you're asking for it :-) Ok, let's discuss. > > Host: > - IKEv2 mandatory: why? > You are aware that IKEv2 systems won't play with IKEv1 systems and that > IKEv2 is not very popular at present, too? I suggest that one at least > should ask for ISAKMP too, this keeps all options open what will > be used. Not sure. We could move that to optional, but can't decide. Suggestions? > - ULA optional: I don't exactly see how a host could support IPv6 at all > and not do ULA. It's just Yet Another Prefix. Agree. Moving to mandatory. > > Enterprise switch: > - RA-guard: your enemy is not -unsolicited- RA, your enemy is > -unauthorized- RA. As in, the laptop your sales guy brought in > announcing itself as the gateway to the world, even if RA was solicited. AFAIK RA-guard prevents RA packets being sent from ports, that are "declared" as "hosts" ports and connected hosts not authorized to send RA as such. > entire section: > to snoop means "to listen secretly". You don't want to listen > to those packets, you want to block them, selectively. That is called > filtering. Half the section wants s/snoop/filter/ This was also Ole Troan's comment: "Would change snooping to inspection in some cases. Or use SAVI terminology" Looks like we need to change this somehow, but not sure where to use "snooping", where "inspection" and where "filter" > - optional IPv6 basic, SNMP > How do you plan to admin that switch in a v6-only network? walk by and > use a serial cable? Enterprise class equipment also really should do > SNMP We thought of putting in mandatory requirements stuff that is already imlemented, so we are not necessarily eliminating too much equipment and put some stuff in optional for vendors implementing optional requirements to get more points on tenders - encouraging them to deploy more optional requirements. When this gets implemented we can move that to mandatory. Do we have any info, what percentage of "enterprise/ISP" grade switches supports IPv6 for management/SNMP now, today? If we have a solid percentage, then I'm happy to move that requirement to mandatory section. > > Router: > - ULA optional doesn't make a lot of sense here either, except perhaps as > requiring the ability to set routes into the bitbucket. Agree. Moving to mandatory. > > Firewall (etc): > - an application firewall that speaks BGP? at all? usefully? > I've seen (D)DoS blackholing devices that speak BGP, otherwise that > part of routing is not really best run on firewalls. That's why it says "if requested". I agree that BGP is not best run on firewall, but some people practice that idea, mainly because of cutting-costs and for small-mid companies it might work out well ofr most of the time. > > Skill requirements: much as a certificate does not guarantee skill, its > absence doesn't guarantee the absence of skill either. Do you have any > IPv6 certificates that have any meaning? No. Not at all. That's why I took a declaration from one government tender and modified it to include also IPv6. This is self-regulation, if systems integrator is sure, that his staff is good-to-go for the job that needs to be done, they will sign that declaration. Rmember, it says "declares, under criminal and material responsibility". That's not a joke, if you sign that and have no competent people to do the job properly. Thank you all for your comments, hope that we can trigger a bit more discussion on that before Rome meeting. Jan Zorz go6.si
- Previous message (by thread): [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment
- Next message (by thread): [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]