Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes

I personally think that the question "4.2 Should nodes respond to Ping to FF0x::1" in the recommendations section is an interesting one. Just as I would expect there is guidance (but don't know if there is) regarding responses to IPv4 broadcast ICMP echo requests, it seems it could be helpful to provide guidance to OS or OS firewall manufacturers regarding if or how nodes should respond to ICMPv6 echo requests via multicast addresses (if this guidance doesn't already exist).

Bill Cerveny

On Sep 20, 2014, at 7:25 PM, Nalini Elkins <nalini.elkins@insidethestack.com> wrote:

> 
> On 20/09/2014 15:15, Nalini Elkins wrote:
> > Situation:  node A is on a subnet with 25 other nodes (B-Z)
> >
> > 1.  Node A sends 10 ICMP ping requests to FF02::1
> > 2.  Nodes B through Z send Node A back ICMP 10 ping replies each
> >
> > Impact: with very little work by Node A, he has made B - Z do work &
> > created network congestion with 250+ packets.
> 
> >If the hosting provider has any sense, this will count towards node A's 
> >bandwidth allocation and if they persist in doing this, they will end up 
> >with a large bill as well as having trashed their connectivity.
> 
> >The lesson is that if you shoot yourself in the foot, it will hurt.  If 
> >your network design is such that shooting yourself in the foot causes other 
> >hosts to be shot in the foot, then your network design may have a problem.
> 
> >If you are a commercial hosting provider who provides third party shared 
> >tenancy networks which use this design, then you should expect problems of 
> >this sort.
> 
> >Most hosting providers know these things and there is no need for the IETF 
> >to remind them.
> 
> Really?
> 
> So then, are you saying that the hosting company example we gave was for a 
> particularly ignorant or incompetent firm?   That most hosting providers of IPv6
> services and most end user enterprises (because our draft is for them as well)
> are quite well aware of the potential drawbacks and implications of IPv6 link-local 
> and multicast traffic in the design of their subnets or broadcast domains.
> And, furthermore take such traffic and / or the need for isolation of nodes for
> security or regulatory purposes into account when doing their network design?
> 
> And, basically, the issues that we are trying to bring up are quite well known 
> to everyone.   You could be right (but I am betting against it!).    
> 
> Maybe my co-author, who works for a large end-user enterprise, and whose 
> organization is trying to implement IPv6, can chime in and let us know how 
> well known these issues are in his own organization and those he speaks to
> regularly.
> 
> Maybe other enterprise customers on the list can speak as well.  Would love
> to hear from them.  Having said that, probably if they are on this email list,
> they are probably orders of magnitude more sophisticated than most.
> 
> I can also take an informal poll.   I can call 2 -3 other hosting companies 
> to see what their IPv6 addressing structure is & let you all know.   I can also
> call 5 - 10 large enterprise companies in the US (Fortune 500 & large federal 
> agencies & the like) to tell you if they take such things into consideration.   
> 
> A few years ago, I compiled IPv6 addressing plans (subnet structure,
> naming conventions, etc) from 6 - 7 universities (commercial entities will
> generally not speak publicly about how they do things).   I can tell you there
> were no such considerations in their plans.  I can go back and ask them
> if they will allow me to distribute their plans publicly.
> 
> 
> 
> All this will take me a few days, so maybe we can pick up the discussion
> on Wed / Thurs of next week.
> 
> I believe that guidance on network design is needed for end-user sites -
> including hosting companies.   That was the reason for our draft.  If I am 
> wrong and no such guidance is needed, then I will be quiet and withdraw
> the draft.
> 
> Nalini
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops