v6 subnet size for DSL & leased line customers

Owen DeLong owen at delong.com
Tue Dec 25 06:24:07 UTC 2007



On Dec 24, 2007, at 9:43 PM, Kevin Loch wrote:

>
> Iljitsch van Beijnum wrote:
>> On 24 dec 2007, at 20:00, Kevin Loch wrote:
>>>> RA/Autoconf won't work at all for some folks with deployed server
>>>> infra,
>> That's just IPv4 uptightness. As long as you don't change your MAC  
>> address you'll get the same IPv6 address every time, this works  
>> fine for servers unless you need a memorable address. BTW, I don't  
>> know anyone who uses DHCP for their servers.
>>> Hopefully vrrpv6 will work with RA turned completely off.
>> With router advertisements present you don't need VRRP because you  
>> have dead neighbor detection.
>
> And that helps the hosts on the same l2 segment that need different
> gateways how?  Or hosts with access to multiple l2 segments with
> different gateways?
>
I think the point is that RA and VRRPv6 are not designed to depend on  
each
other in any way.

While you can certainly run both on any given segment, it is hard to  
imagine
many cases where one would want to do so.

In places where all you need is to know a valid gateway that can do  
the right
thing with your packets, RA is probably the right solution.  This,  
generally,
turns out to be the vast majority of LAN segments.  Clearly, RA is  
intended
only for scenarios where a gateway is a gateway is a gateway.

In places where you need tighter control over the usage of various  
gateways
on a common L2 segment, VRRP probably makes more sense.  However,
as things currently stand, that means static routing configuration on  
the host
since for reasons passing understanding, DHCP6 specifically won't do
gateway assignment.

I don't know the state of the current VRRP6 draft or protocol, but, I  
can't
imagine what would be left in VRRP6 if it couldn't be statically  
configured
without RA.  If that's the case, then, what would it possibly do,  
exactly, that
would be different from RA without VRRP?

Owen




More information about the NANOG mailing list