Catching up... Waiting for RIPE-666 would be superb indeed ;-) More seriously, I believe that the document goal is to ease the job of end-users wanting to deploy IPv6 by selecting good solid devices off the shelves (i.e. also offered by several vendors) and not to pressure vendors to add new features. Let's be pragmatic here, RIPE is not the IETF. The RA-guard is kind of interesting because without the further refinements at work at the IETF, it is not so interesting anymore as it can be evaded but still useful for misconfigured devices of course. RFC 6620 (SAVI FCFS) RFC 6583 (NDP cache exhaustion) are also becoming available (at least for enterprise grade switches and should be there as well). As a vendor, we have an issue with 'MLD snooping (RFC 4541)' for a layer-3 device/switch which of course if you are a layer-3 port, you implement MLD (RFC 3810) as stated in RIPE 554 but you do not implement the snooping which is applicable to a layer-2 port. It can appear as splitting hair but you cannot imagine the number of hours/calls I have to spend on this hair splitting... So, please remove the MLD snooping requirement from a layer-3 device. Last one, we could argue that OSPF trailer authentication is now a RFC 6506 even if it brings little value anyway and could be too fresh to have multiple implementations. Hope this helps -éric
-----Original Message----- From: ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of MarcoH Sent: mardi 28 mai 2013 08:43 To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] RIPE 554 Errata Page
Let's also split off the generic discussion from the concrete matter at
hand for ripe-554: do we have a draft of the errata? ifnot yet, anyone volunteering one?
The one mistake that I am aware of is:
- Requirements for enterprise/ISP grade "Layer 2 switch" equipment Mandatory support:
Router Advertisement (RA) filtering [RFC4862]
Where this should be probably be a requirement for RFC 6105 which actually is called "IPv6 Router Advertisement Guard".
Marco