[ipv6-wg] RIPE 554 Errata Page

On 29 May 2013, at 08:43, Eric Vyncke (evyncke) <evyncke at cisco.com> wrote:

> Catching up...
> 
> Waiting for RIPE-666 would be superb indeed ;-)

Be careful what you wish for. I got some (apparently very serious!) emails about making light of the devil when I proposed 6/6/6 as the date to turn off the 6bone and routing of 3ffe::/16.

> 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.

No, but the RIPE community should give the best possible advice to its members (and many, many non-members who are pointed at RIPE-554). The question here is defining "best". Is it best for the members' networking needs for the next five+ years that they will live with their purchasing decision for, or best in terms of making the vendors' job to tick all the boxes easy, because it's all already done.  There is probably a middle ground to be found.

> 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).

So do you think RIPE-666 (or whatever it becomes :)) should cite these RFCs? I certainly do.  The question if so is how.  They are not mandatory, but they can certainly add value to a deployment. Similar to (perhaps) requesting 802.1X support in a switch.

I think this discussion has agreed to do a minor errata update of 554, and to discuss what 554-bis might look like. In that case, should the above type of RFCs, and the ones I mentioned yesterday, be included? If so, how?  Are they mandatory?  Are they optional?  Are they tagged as features that readers should ask vendors for their roadmaps for (and yes, I'm sure we've all been bitten by broken roadmap promises, but you have to take some leap of faith at some point for features that don't exist yet).

> 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.

You say "layer-3 device/switch", I think you really mean "layer 3-only device". If the device offers any layer 2 functionality, MLD snooping becomes important. We had this issue with a specific brand of printer that fell over in the face of seeing a few HD IPv6 IP-TV channels only last month.

> 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

Discussion is good :)

Tim

> 
> -éric
> 
>> -----Original Message-----
>> From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf
>> Of MarcoH
>> Sent: mardi 28 mai 2013 08:43
>> To: ipv6-wg at 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
>> 
> 
>