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