IPv6 RA vs DHCPv6 - The chosen one?

Mon Dec 26 13:49:20 UTC 2011

2011/12/26 Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>

> TJ wrote:
>
> > I  think perhaps you are confusing "what must be supported by
> > implementations" (and ignoring the text describing the requirements) as
> > stated in 6434, with operational usage.
>
> There is not much difference.
>

I disagree; there is a huge difference between what a node must _support_
and what an environment must _do_.
The node support is meant to define what is generally possible, and an
environment will use a subset of that.

> > For example - SLAAC must be supported by the implementations, but an
> > environment isn't required to use it.
>
> Still, if ND, which SHOULD be implemented, is not implemented,
> SLAAC CAN NOT be implemented.
>

While I agree the wording is sub-optimal, this is where the descriptive
text is important - the entirety of ND is "only optional" if the media has
no need for discovering a MAC address (think a serial link, and NBMA link
types require additional considerations as well) ... while a range of
sub-categories of ND are required.

>
> And, if RA is obsoleted, which is a point of discussion, there
> is no reason to keep so bloated ND only for address resolution.
>

I've been avoiding this part of the conversation, but I'll toss my
unsolicited opinion in here as well; RA/SLAAC are both fine. DHCPv6 is
fine.  Use whichever your environment benefits from most, and having a
couple choices is not a bad thing.

   - RA/SLAAC - I'd vote to stop extending now'ish (DNS (address + suffix)
   is important), but moving on I'd leave it as-is.  If others really want to
   extend it (say, with NTP options) I wouldn't vehemently object.
   - DHCPv6 - I think it is fine without a default route option, but if
   others want to craft the standard and can get vendors to implement it so be
   it.

*(I think a router providing information about itself is just fine ... )*

/TJ