IPv6 Confusion

Owen DeLong owen at delong.com
Wed Feb 18 20:22:04 UTC 2009


On Feb 18, 2009, at 11:53 AM, Jack Bates wrote:

> Kevin Loch wrote:
>> Just how DO we get the message to the IETF that we need all the  
>> tools we
>> have in v4 (DHCP, VRRP, etc) to work with RA turned off?
>
> You don't, because there isn't really a technical reason for turning  
> off RA. RA is used as a starting point. It can push you to DHCPv6 or  
> any number of other options (such as SLAAC). The same argument goes  
> for multicast versus broadcast. The idea is to add an extra level  
> that allows for better manipulation and versatility.
>
There is a reason for turning off RA and the IETF (and you) just don't  
seem to
get it.

There are real world situations in which not all routers are created  
equal and
it is important for the DHCP server to tell the correct host which  
router to use
for default.

There are also a number of security issues available in the "Just  
trust some
unsolicited broadcast about where to send all your network traffic."  
approach
to host bootstrapping that bother some people.

We can argue all you want about how pathological these cases are, but,
the fact remains that trusting some unsolicited broadcast from a device
claiming to be a router as your starting point isn't viable in a  
number of
real world installations and an alternative needs to be made available.

> Of course, better support and vendor implementation of all the  
> different options would be nice.
>
Sure, but, so would DHCP functionality equivalent to what we have in  
IPv4.

If you want SLAAC or RA or whatever, more power to you.  Some  
installations
do not.  They want DHCP equivalent functionality with the same  
security model.

> Most networks have broadcast controls that are mostly vendor  
> specific hacks. Now they'll have multicast controls, which is good  
> to have anyways.
>
This assumes a lot, but, even if it's true, it doesn't change the fact  
that some
organizations like the existing DHCP model and there's no reason not to
provide equivalent functionality in IPv6.

Owen





More information about the NANOG mailing list