IPv6 RA vs DHCPv6 - The chosen one?
trejrco at gmail.com
Mon Dec 26 07:49:20 CST 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
*(I think a router providing information about itself is just fine ... )*
More information about the NANOG