[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AD Review of draft-ietf-ipv6-rfc2462bis-06.txt



(This message is a response to a unicasted message, which Margaret
said should have actually been sent to the list.  So I'm cc'ing to the
wg list)

>>>>> On Thu, 21 Oct 2004 14:30:24 -0400, 
>>>>> Margaret Wasserman <margaret@xxxxxxxxxxxxxx> said:

> What I think we should do is make it very clear that the M&O bits are 
> not used for either Neighbor Discovery (in 2461bis) or Address 
> Autoconfiguration (in 2462bis).  In other words, the values of these 
> bits can be completely ignored for purposes of ND, DAD, AddrConf, 
> etc. -- we will autoconfigure exactly the same address, in exactly 
> the same way, regardless of the value of these bits. This is true, 
> right?

Yes, I think so.  Whatever the "stateful" protocol(s) is, or however
we invoke the protocol(s) based on the M/O flags, it is completely a
separate process from the base ND protocol or stateless address
autoconfiguration (or DAD for that matter).  In particular, we can (or
"should" when necessary) run stateless address autoconfiguration and
DHCPv6 for address allocation concurrently.

One subtle point is that DAD should apply to addresses allocated
through DHCPv6.  But I believe we can handle this separately from the
meaning/usage of the M/O flags.

I believe the existing documents (2461/2462) already clarify the point
to some extent, but perhaps we'll need to be more specific.

> You could then optionally include an informational reference to a 
> document that describes the meaning and use of these bits and/or say 
> that they meaning and use of these bits will be described in a 
> document to be published later.

> But, I'd leave out the partial description of the meaning of these 
> bits from both 2461bis and 2462bis, as that only creates the 
> impression that these bits have some implications for the protocols 
> described in this document.

Point taken, and I tend to agree.

Since this may cause a significant change to the current version of
the document, I'll make a separate thread on this specific issue.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@xxxxxxxxxxxxxxxxxxxxx

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@xxxxxxxx
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------