{SPAM?} Re: IPv6 Deployment for the LAN

Fri Oct 23 03:15:58 UTC 2009

On Oct 22, 2009, at 2:31 PM, TJ wrote:

>>
>>
>>>> Then let me say it. RA needs to be able to be completely turned  
>>>> off.
>> DHCPv6 needs to be able to completely configure all requesting hosts.
>
>
> Those two statements are not synonymous ...
>
They may not be synonymous, but, there is a set of operators for whom  
both
are true.

>
> Sure, leave RA in the IPv6 stack. The market will decide, and we  
> will see if
>> it is still on by default on soho routers and in IOS 15.4T in 2015.
>>
>> That is a more sensible statement.  And were I to be a gambling man  
>> I would
> say it will indeed be on by default ... we'll talk more about it  
> then :).
>
>
> Also, I would like to add - there is a difference between the default
> gateway information and other things, such as NTP|DNS|SIP server
> information.

Maybe.

> The default gateway, by definition, is an on-link thing.  IMHO, this  
> makes
> the router a good source for information about the router.

It does in some cases.  In other cases, it does not.

> I am not saying use cases for "fully spec'ed DHCPv6" don't exist or  
> should
> be ignored.
> Making the router capable of sharing the "missing piece" that covers  
> ~95% of
> use cases is also a Good Thing.
>
I don't think most people are arguing that it should not be possible  
to configure
a network for RA/SLAAC with the RA providing the gateway information.   
In fact,
I think most of us would like to see RA/SLAAC capable of providing the  
other
needed pieces of the puzzle.

That said, there is a group of operators for whom RA is a bad thing,  
SLAAC is
also a bad thing, and, their current usage of DHCPv4 does not map to any
existing IPv6 technology, so, they are crying foul and want their  
needs addressed.
I think that is 100% legitimate, regardless of whether Iljitsch thinks  
we are old
enough to play with power tools or not.

> Thinking out loud, we could also re-create the idea of an auto-magic  
> DNS by
> creating a special use case within ULA-space - say FD00::/96, saving  
> the
> last 32 bits for something like ::53 and using anycast.

That's a fine solution for part of the problem space, but, moving the  
router
assignment function for hosts to a device controlled by the host  
administrator
is a necessary administrative boundary issue for a number of  
organizations.

> *(Could abstract same idea to any stateless and/or light-session-based
> service ... FD00::123 for Automagic ULA-based anycast NTP, etc.   
> Need 32
> bits if we don't want to hex convert the >9999 things, just in  
> case ...)*
>
NOOO... If you're going to do fd00:: for this, the 123 case really  
should
be fd00::7b, not fd00::123

Owen