2011/12/26 Masataka Ohta <mohta@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