New draft document available: Requirements For IPv6 in ICT Equipment
(apologies for any duplicate emails) Dear Colleagues, 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@ripe.net. Regards, Marco Hogewoning IPv6 WG co-chair
On 1.10.10 10:23, Marco Hogewoning wrote:
(apologies for any duplicate emails)
Dear Colleagues,
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@ripe.net.
Hi @all. Can't believe we did it right first time :) Maybe nobody read it and nobody cares. Recommandation for "what to demand in terms of IPv6 when buying ICT equipment" is badly needed for further deployment of IPv6 in all sectors and communities, can somebody please read that and give us feedback - we need to publish a document that makes sense. Thank you all for your time and efforts, Jan Zorz go6.si
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@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
On 7 Oct 2010, at 10:41, Jan Zorz @ go6.si wrote:
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?
Apple is an organisation. It does not take decisions. People at Apple do. In this case, you need to talk to Stuart Cheshire.
- 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.
+1
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.
how is a host-based mechanism based on prevention of outgoing packets ever going to work? I mean, it can prevent accidents (perhaps, it is not a guarantee, look at usual list of ad-hoc Wifi SSIDs at any event) but it sure won't prevent intentional unauthorised RAs. Distinguishing authorised from non-authorised is of course no simple matter, probably needing pre-auth, which kind of takes the automation out of the equation. It's almost like the IPv6 designers didn't have access to real networks during protocol development (no DHCP initially, silly TLA/SLA crap...)
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.
is this one v6 specific? Joao
Hi, On Thu, Oct 07, 2010 at 11:11:17AM +0200, João Damas wrote:
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.
how is a host-based mechanism based on prevention of outgoing packets ever going to work? I mean, it can prevent accidents (perhaps, it is not a guarantee, look at usual list of ad-hoc Wifi SSIDs at any event) but it sure won't prevent intentional unauthorised RAs.
RA-guard is not host-based but switch-based. You configure the switch "*this* is the port where the router lives" and RAs on all other ports are filtered. See draft-ietf-v6ops-ra-guard-*.txt Gert Doering -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 7.10.10 16:30, Gert Doering wrote:
how is a host-based mechanism based on prevention of outgoing packets ever going to work? I mean, it can prevent accidents (perhaps, it is not a guarantee, look at usual list of ad-hoc Wifi SSIDs at any event) but it sure won't prevent intentional unauthorised RAs.
RA-guard is not host-based but switch-based. You configure the switch "*this* is the port where the router lives" and RAs on all other ports are filtered.
See draft-ietf-v6ops-ra-guard-*.txt
Gert Doering
Exacty :) +1 /jan
Joao hi, Thnx for comments. Please see my thoughts inline. On 7.10.10 11:11, João Damas wrote:
Apple is an organisation. It does not take decisions. People at Apple do. In this case, you need to talk to Stuart Cheshire.
Anyone knows or have contact with Stuart Cheshire @Apple?
- 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.
+1
ack.
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.
how is a host-based mechanism based on prevention of outgoing packets ever going to work? I mean, it can prevent accidents (perhaps, it is not a guarantee, look at usual list of ad-hoc Wifi SSIDs at any event) but it sure won't prevent intentional unauthorised RAs. Distinguishing authorised from non-authorised is of course no simple matter, probably needing pre-auth, which kind of takes the automation out of the equation. It's almost like the IPv6 designers didn't have access to real networks during protocol development (no DHCP initially, silly TLA/SLA crap...)
This is meant to work on switch ports level. You declare "router" port and let RA packets go through only on that physical port, "snooping" for RA pachets in the switch and blocking RA packets on all ather ports...
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.
is this one v6 specific?
No. Same story on v4. Thnx, /jan
On 8 Oct 2010, at 10:11, Jan Zorz @ go6.si wrote:
Joao hi,
Thnx for comments. Please see my thoughts inline.
On 7.10.10 11:11, João Damas wrote:
Apple is an organisation. It does not take decisions. People at Apple do. In this case, you need to talk to Stuart Cheshire.
Anyone knows or have contact with Stuart Cheshire @Apple?
Stuart Cheshire <cheshire@apple.com> is his public address.
This is meant to work on switch ports level. You declare "router" port and let RA packets go through only on that physical port, "snooping" for RA pachets in the switch and blocking RA packets on all ather ports...
yep, I was tricked by the wording in the original text. Perhaps that is the part that need a bit of work? Joao
On Oct 8, 2010, at 10:41 AM, João Damas wrote:
On 8 Oct 2010, at 10:11, Jan Zorz @ go6.si wrote:
Apple is an organisation. It does not take decisions. People at Apple do. In this case, you need to talk to Stuart Cheshire.
Anyone knows or have contact with Stuart Cheshire @Apple?
Stuart Cheshire <cheshire@apple.com> is his public address.
Sorry for late reply. I also dislike the lack of DHCPv6 in MacOSX, but trying to contact an engineer is not the way to go (unless you're lucky to hit one that I actually can influence that decision at all...) (Shane also told me that Apple are supporters of the zeroconf philosophy, so they are of a different opinion of how things should be solved. Share: correct me if I interpreted you wrong) I also know an engineer at Apple, and according to him, the only way of influencing decisions of what should be fixed / added etc. is to bugreport it (@ https://bugreport.apple.com). The more people that do this, the better, and more likelier that it will be implemented. So, spread the word... let Apple know what you think about (the lack of) DHCPv6. I thought I sent this to this list long time ago, but it must have been in my own virtual reality... Regards, /P
(Shane also told me that Apple are supporters of the zeroconf
Fredrik Pettai wrote on 15.11.2010 15:37:24: philosophy,
so they are of a different opinion of how things should be solved. Share: correct me if I interpreted you wrong)
Hi Fredrik, yes you are right, Apples zeroconf initiative called Bonjour ( www.apple.com/bonjour).
I also know an engineer at Apple, and according to him, the only way of influencing decisions of what should be fixed / added etc. is to bugreport it (@ https://bugreport.apple.com). The more people that do this, the better, and more likelier that it will be implemented.
So, spread the word... let Apple know what you think about (the lack of) DHCPv6.
But, what is the need for dhcpv6 if you have technologys like IPv6 SAC mechanism with (for example) MulticastDNS ( draft-cheshire-dnsext-multicastdns.txt) support. IMHO at least 80% of standard (office) environments don`t need any dhcpv6 support. Let me know what you are think about it. Regards Michael
On Nov 15, 2010, at 9:07 PM, Michael Schneider/calispera.com wrote:
(Shane also told me that Apple are supporters of the zeroconf
Fredrik Pettai wrote on 15.11.2010 15:37:24: philosophy,
so they are of a different opinion of how things should be solved. Share: correct me if I interpreted you wrong)
Hi Fredrik, yes you are right, Apples zeroconf initiative called Bonjour ( www.apple.com/bonjour).
I also know an engineer at Apple, and according to him, the only way of influencing decisions of what should be fixed / added etc. is to bugreport it (@ https://bugreport.apple.com). The more people that do this, the better, and more likelier that it will be implemented.
So, spread the word... let Apple know what you think about (the lack of) DHCPv6.
But, what is the need for dhcpv6 if you have technologys like IPv6 SAC mechanism with (for example) MulticastDNS ( draft-cheshire-dnsext-multicastdns.txt) support.
IMHO at least 80% of standard (office) environments don`t need any dhcpv6 support. Let me know what you are think about it.
For the home user that's fine, but maybe not for a enterprise network. It's not just about provisioning DNS/resolver configuration to clients. It's about access control, e.g. to be able to centrally manage which client that are connected/assigned an IP. Traceability e.g. which client where connect a specific time etc. to name a few of the common things you do with a centralized DHCP(v4) solution today. (I do confess that I'm not up to speed on the IPv6 development since ~1 year back) Regards, /P
Fredrik Pettai <pettai@nordu.net> wrote on 16.11.2010 16:02:09:
For the home user that's fine, but maybe not for a enterprise network. ack.
It's not just about provisioning DNS/resolver configuration to clients. It's about access control, e.g. to be able to centrally manage which client that are connected/assigned an IP. DHCP is IMHO not the right way to implement access control. What is your security credential in this solution? I understand what you mean, but i think this is not a primary requirement for dhcp. In my view the use of dhcp for access control in your example is only a workaround and can`t be the solution for security.
Traceability e.g. which client where connect a specific time etc. to name a few of the common things you do with a centralized DHCP(v4) solution today. Please understand me right, i think we must have a look from the requirements side. IMHO we must consider the IPv4 solutions for IPv6 and perhaps can`t use it 1to1 in the IPv6-world.
Regards Michael
On Nov 16, 2010, at 6:13 PM, Michael Schneider/calispera.com wrote:
Fredrik Pettai <pettai@nordu.net> wrote on 16.11.2010 16:02:09:
For the home user that's fine, but maybe not for a enterprise network. ack.
It's not just about provisioning DNS/resolver configuration to clients. It's about access control, e.g. to be able to centrally manage which client that are connected/assigned an IP. DHCP is IMHO not the right way to implement access control. What is your security credential in this solution?
Maybe I used the wrong wording here, maybe "inventory/provisioning system" is describing it better. Sorry.
I understand what you mean, but i think this is not a primary requirement for dhcp. In my view the use of dhcp for access control in your example is only a workaround and can`t be the solution for security.
Traceability e.g. which client where connect a specific time etc. to name a few of the common things you do with a centralized DHCP(v4) solution today. Please understand me right, i think we must have a look from the requirements side. IMHO we must consider the IPv4 solutions for IPv6 and perhaps can`t use it 1to1 in the IPv6-world.
No, I can agree with that. But what other alternatives do we have today (even counting drafts)? /P
Thus wrote Jan Zorz @ go6.si (jan@go6.si):
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?
On second thought, require both IKEv2 (some of its features are rather useful) and ISAKMP; thus you're very likely to be able to talk to your counterpart. To clarify:
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.
Now it is: - RA snooping must be used in the network to block unsolicited RA messages I think it should read: - RA filtering must be used in the network to block unauthorized RA messages i.e. I assume you are thinking of the right thing, but using the wrong words.
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"
enterprise/ISP grade switch, mandatory support: - DHCPv6 filtering (port based suppression of origination of DHCPv6 messages is ok) - Router Advertisement (RA) snooping - RA filtering to block unauthorized RA messages (port based RA origination supression ok) - Dynamic "IPv6 neighbour solicitation/advertisement" inspection (note the typo, it's RFC2461 not RFC24611) - IPv6 neighbour solicitation/advertisement filtering similar to "Dynamic ARP inspection". ... - Neighbour Unreachability Detection [NUD, RFC2461] snooping - NUD filtering - Duplicate Address Detection [DAD, RFC4429] snooping and filtering. It must be possible to restrict DAD message source addresses originating on a port. (note the typo, DUD -> DAD) optional support: [...] - IPv6 Routing Header [RFC2460, Next Header value 43] snooping - IPv6 Routing Header filtering (port based suppression ok) - UPNP filtering (I'm assuming this is Universal Plug & Play UPnP) 'customer ports' does not have sufficient meaning. In an enterprise none of your ports is populated by a customer. We need an expression for "neither router nor DHCP server nor trunk". Also, why would you specifically try to avoid UPnP to do something useful, but allow useless messages to pass?
- 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.
You expect a switch to actually support filtering on RA and -not- be able to support logging in via IPv6?! All new switches on the small side I met recently supported adding v6 addresses for management if they supported v6 at all, but I haven't had a device that supported RA filtering in my fingers yet. [BGP 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.
eeeewyuck. Well, it'll not be my funeral :-P
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.
But if someone signs your text they sign that I have at least three staff that have CERTIFICATION by a vendor on general knowledge of the IPv6 protocol, IPv6 network planning and IPv6 security. It does not say "certification or knowledge". It says "they need to have a certificate". It also says that they need to know their stuff, but that is an AND, not an OR.
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.
But they also have to have a piece of paper. I.e. -you- would currently be disqualified, since you don't have certification on IPv6 if I read your no correctly. Being an expert is not enough if you keep that wording. regards, spz -- spz@serpens.de (S.P.Zeidler)
Petra, hi Thnx for comments, please see my thoughts inline :) On 7.10.10 23:16, S.P.Zeidler wrote:
Thus wrote Jan Zorz @ go6.si (jan@go6.si):
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?
On second thought, require both IKEv2 (some of its features are rather useful) and ISAKMP; thus you're very likely to be able to talk to your counterpart.
OK. So where IKEv2 is required I add ISAKMP. Which RFCs you suggest to reference? @list: do we agree on that?
To clarify:
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.
Now it is: - RA snooping must be used in the network to block unsolicited RA messages I think it should read: - RA filtering must be used in the network to block unauthorized RA messages
i.e. I assume you are thinking of the right thing, but using the wrong words.
Ok, changing "unsolicited" to "unauthorized"
enterprise/ISP grade switch, mandatory support: - DHCPv6 filtering (port based suppression of origination of DHCPv6 messages is ok) - Router Advertisement (RA) snooping - RA filtering to block unauthorized RA messages (port based RA origination supression ok) - Dynamic "IPv6 neighbour solicitation/advertisement" inspection (note the typo, it's RFC2461 not RFC24611) - IPv6 neighbour solicitation/advertisement filtering similar to "Dynamic ARP inspection". ... - Neighbour Unreachability Detection [NUD, RFC2461] snooping - NUD filtering - Duplicate Address Detection [DAD, RFC4429] snooping and filtering. It must be possible to restrict DAD message source addresses originating on a port. (note the typo, DUD -> DAD)
optional support: [...] - IPv6 Routing Header [RFC2460, Next Header value 43] snooping - IPv6 Routing Header filtering (port based suppression ok) - UPNP filtering (I'm assuming this is Universal Plug& Play UPnP)
'customer ports' does not have sufficient meaning. In an enterprise none of your ports is populated by a customer. We need an expression for "neither router nor DHCP server nor trunk".
Well, I would remove word "customer". Just "ports".
Also, why would you specifically try to avoid UPnP to do something useful, but allow useless messages to pass?
This part is suggested by Torbjorn, he's on the list. I suggest we change "must" to "should". Changed L2 enterprise grade list: Mandatory support: - MLDv2 snooping [RFC4541] - DHCPv6 filtering [RFC3315] DHCPv6 messages must be blocked between subscribers and the network so no false DHCPv6 servers can distribute addresses - Router Advertisement (RA) filtering [RFC2462, RFC5006] RA filtering must be used in the network to block unauthorized RA messages - Dynamic "IPv6 neighbour solicitation/advertisement" inspection [RFC2461] There must be an IPv6 neighbour solicitation/advertisement inspection as in IPv4 “Dynamic ARP inspection”. The table with MAC-address and link-local and other assigned IPv6-addresses must be dynamically created by SLAAC or DHCPv6 messages. - Neighbour Unreachability Detection [NUD, RFC2461] filtering There must be a NUD filtering function so false NUD messages cannot be sent. - Duplicate Address Detection [DAD, RFC4429] snooping and filtering. Only allowed addresses must be allowed as source IPv6-addresses in DAD messages from each port. Optional support (management) - IPv6 Basic specification [RFC2460] - IPv6 Addressing Architecture basic [RFC4291] - Default Address Selection [RFC3484(bis)] - ICMPv6 [RFC4443] - SLAAC [RFC4862] - SNMP protocol [RFC3411] - SNMP capabilities [RFC3412, RFC3413, RFC3414] - IPv6 Routing Header [RFC2460, Next Header value 43] filtering IPv6 Routing Header messages must not be allowed between subscriber ports and subscriber and uplink to prevent routing loops [See also RFC5095, Deprecation of Type 0 Routing Headers in IPv6] -UPNP filtering UPNP messages must always be blocked between customer ports. There may be a possibility to filter different Ether types to allow only 0x86dd between subscriber ports. And most probably you must also permit 0×800 and 0×806 for IPv4.
- 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.
You expect a switch to actually support filtering on RA and -not- be able to support logging in via IPv6?! All new switches on the small side I met recently supported adding v6 addresses for management if they supported v6 at all, but I haven't had a device that supported RA filtering in my fingers yet.
Ok. Since this comment came up many times, I'm moving IPv6 on management to mandatory section.
[BGP 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.
eeeewyuck. Well, it'll not be my funeral :-P
Well, this "if requested" moves the decision on customer side. I presume discussion on BGP-and-firewall-on-same-box is not the case in this document, but I suggest we make one and say "don't do that".
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.
But if someone signs your text they sign that I have at least three staff that have CERTIFICATION by a vendor on general knowledge of the IPv6 protocol, IPv6 network planning and IPv6 security.
It does not say "certification or knowledge".
It says "they need to have a certificate".
It also says that they need to know their stuff, but that is an AND, not an OR.
Good point. You suggest "certification or knowledge". How can we measure "knowledge"? We need to describe that, if we use above wording. Do we want to include "years of experience"? Cert, knowledge and experience are sometimes very different animals.
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.
But they also have to have a piece of paper. I.e. -you- would currently be disqualified, since you don't have certification on IPv6 if I read your no correctly. Being an expert is not enough if you keep that wording.
Agree. /jan
Hi Jan, Thus wrote Jan Zorz @ go6.si (jan@go6.si):
OK. So where IKEv2 is required I add ISAKMP. Which RFCs you suggest to reference?
RFC2407, RFC2408, RFC2409 (Internet DOI, ISAKMP, IKEv1) [...]
Good point. You suggest "certification or knowledge". How can we measure "knowledge"? We need to describe that, if we use above wording. Do we want to include "years of experience"?
In fact I'd ask for 'knowledge' (because that's what matters if the contract is supposed to get served well). A certification without knowledge exists, but doesn't help the customer a lot. But with good certification (it exists! :), you get a cue that the skills are likely to be there: --- snip --- Vendors and reseller that offer system integration services must have at least three employees who have valid certificates of competency from the equipment manufacturers for the equipment that is sold as part of the tender. These employees additionally must have general knowledge of the IPv6 protocol, IPv6 network planning and IPv6 security (as eg indicated by certification for these skills also). If it becomes obvious during ... --- snip --- First sentence stays the same, second asks for knowledge of IPv6 and uses certification as a possible hint that the skillset is there. If it shouldn't be, with or without certificates, the tender initiator can boot the system integrator. regards, spz -- spz@serpens.de (S.P.Zeidler)
On 12.10.10 20:59, S.P.Zeidler wrote:
Hi Jan,
Thus wrote Jan Zorz @ go6.si (jan@go6.si):
OK. So where IKEv2 is required I add ISAKMP. Which RFCs you suggest to reference?
RFC2407, RFC2408, RFC2409 (Internet DOI, ISAKMP, IKEv1)
[...]
Hi, Thank you very much for your comments, appreciated... I think we are somehow heading in a sensible direction... Added ISAKMP to the list. - ISAKMP [RFC2407, RFC2408, RFC2409]
--- snip --- Vendors and reseller that offer system integration services must have at least three employees who have valid certificates of competency from the equipment manufacturers for the equipment that is sold as part of the tender. These employees additionally must have general knowledge of the IPv6 protocol, IPv6 network planning and IPv6 security (as eg indicated by certification for these skills also). If it becomes obvious during ... --- snip ---
Agree. I like this wording. I propose to generate new version of the draft, so please @everybody - if you have any thoughts or suggestions - tell them now, before Chris generates new version on the RIPE-NCC document store. Thnx, /jan
Dear list, chairs... There is new version of the draft "Requirements For IPv6 in ICT Equipment" in RIPE Document Store: http://www.ripe.net/ripe/draft-documents/ipv6-ict-requirements.html This version reflects comments and changes proposed in discussion here, please see if this version fits more in where we want to go with the document and possibly publish it as BCP. Thank you, Jan Zorz P.S: See you all in Rome, can't wait :)
participants (7)
-
Fredrik Pettai -
Gert Doering -
Jan Zorz ＠ go6.si -
João Damas -
Marco Hogewoning -
Michael Schneider/calispera.com -
S.P.Zeidler