Re: DHCP6 and RA,M=1,PIO,A=0

[Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>]

Hi James,

On Thu, 20 Nov 2008 19:19:27 -0600
james woodyatt <jhw@apple.com> wrote:

> On Nov 20, 2008, at 17:22, Fred Baker wrote:
> > On Nov 20, 2008, at 10:40 AM, Rémi Denis-Courmont wrote:
> >> On Thursday 20 November 2008 18:14:41 Fred Baker, you wrote:
> >>>
> >>> So I understand your comment as less than supportive of the  
> >>> document. In what ways do you believe it needs to change?
> >>
> >> I am just dubious about the DHCPv6 solution. I think it needs to be  
> >> better studied, so that we understand what (if anything) it would  
> >> solve.
> >
> > I think operational folks can tell you pretty quickly what it  
> > solves. It enables an operator to specify an address for an end  
> > system as opposed to letting the end system dream one up.
> 
> Strictly speaking, it enables an operator to translate the MAC address  
> of an endpoint interface into its assigned IPv6 interface address.   
> It's ICMPv6 RA that specifies that an endpoint interface isn't allowed  
> to dream up its own address.  I mention this distinction because it's  
> important to the point I make below.
> 
> > If the argument is "I just think people should be using  
> > autoconfiguration", I have no problem with autoconfiguration, but I  
> > know network managers that do. "I don't like it" is no where near as  
> > useful a comment as "I have identified a problem".
> 
> Network managers who think it's important to be able to control the  
> assignment of IPv6 interface addresses to physical interfaces often  
> make the mistake of assuming that MAC addresses are fixed on hardware  
> manufacturing lines and cannot be changed in user software.
> 
> I'm here to say that's a painfully stupid mistake.
> 
> Whatever could possibly be the point of disabling address self- 
> assignment on a subnet when the network management system cannot be  
> certain either A) that the device presenting a specific MAC address to  
> the network is the same device that presented it last time, or B) that  
> the device presenting you a particular MAC address this time will ever  
> present that MAC address to you again in the future?
> 
> If you deploy a network management system that insist on pairing a MAC  
> address with a specific managed entity [especially, a *billable*  
> entity], then you will be forcing people like me to make MAC address  
> cloning even easier to do than it already is... (and don't think I'm  
> at a loss for ideas about how to do that).
> 

The remedy to that problem or threat already exists in some carrier
equipment. Some ADSL DSLAMs are able to perform MAC
address translation (yes, NAT at layer 2 :-( ), converting customer's
MAC addresses, regardless of what they are, into locally assigned
addresses, unique within the ethernet backhaul network. 

Of course, the same old NAT issues of addresses embedded in the payload
come up. This works fine with PPPoE (no CPE addresses in payload IIRC),
and I think IPv4 ARP (they translate the MAC addresses in the payload),
but I don't think layer 2 NAT is supported for IPv6 ND/RA yet. I don't
really like the idea, but with people like you around ... :-)

> Is encouraging MAC address cloning what we are trying to do here?   
> Because I have a hard time believing it.
> 
> 

Regards,
Mark.