Hi Wes, all, > > (a)-(c): > > Link local is orthogonal in this topic. This document does not address > > it. > > [WES] Then my recommendation would be to explicitly state this in the > document. Perhaps something specifying that this document only discusses > use > of /127 for global scope IPv6 space, and link-local /127 links is out of > scope for the document.
In the "3. Scope of the Memo" section, it says "this document is applicable to cases where operators assign specific addresses on inter-router point-to-point links and do not rely on link-local addresses. In order to make it explicit, we will state that link local is out of the scope of the document. > > (d)-(f): > > Static IPv6 neighbor has been used occasionally. There are quite a few > > sources which describe it, so please refer to them. > > [WES] No, you should have informative references to them in the document > rather than leaving the reader to infer/find them. And specifically for D > and E, you need to provide some guidance to implementers on what should be > done in these cases. The "no need for ND" was an extreme case example and we didn't mean to recommend it in general. So we don't want to provide a specific guidance for this case. Let us remove this to avoid confusion. Thank you for your feedback. We will modify the points above in the -01 version. With regard to the recommendation in other thread to update/obsolete RFC3627, we'd defer to the chairs. Regards, Miya > > (g): > > This document didn't go any further into the definition of IID. But it > > did prevent addresses with all zeros in the rightmost 64 bits. > > > > Thanks, > > Miya > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On Behalf > > Of > > > Mark Smith > > > Sent: Sunday, November 21, 2010 8:22 AM > > > Cc: 6man Mailing List > > > Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-prefixlen-p2p- > > 00.txt> > > > > > > > > > (a) is link local addressing required/supported on these types of > > > links? > > > > > > (b) if so, what is their prefix length? > > > > > > (c) if so, how are the IIDs automatically determined/derived? > > > > > > (d) if ND is switched off on multi-access technology (e.g. ethernet) > > > point-to-point links, as the draft says it can be, how are neighbor > > > cache entries for the remote layer 3 to layer 2 address mappings > > > created? Manual? Promiscuous mode on the receiving end? > > > > > > (e) How is the situation that one end switches off ND but the other > > end > > > doesn't handled? > > > > > > (f) if ND is switched off, how is DAD and/or NUD performed on the > > > addresses? Link state can't be assured to be a NUD indicator on > > > multi-access links, and DAD would be useful to prevent IID collisions > > > when there is a 50:50 chance of getting it wrong. > > > > > > (g) IPV6CP uses IID of zero to indicate an unset IID, to which the > > peer > > > will respond with a suggested non-zero IID - > > > > > > " If the two interface identifiers are different but the received > > > interface identifier is zero, a Configure-Nak is sent with a > > non-zero > > > interface-identifier value suggested for use by the remote peer. > > > Such a suggested interface identifier MUST be different from the > > > interface identifier of the last Configure-Request sent to the > > peer." > > > > > > How is that supposed to now work when /127s create ::0 IIDs? > > > > > > > > > > > > > > > > > > On Thu, 18 Nov 2010 16:34:45 -0800 > > > Bob Hinden <[email protected]> wrote: > > > > > > > All, > > > > > > > > This message starts a 6MAN Working Group Last Call on advancing: > > > > > > > > Title : Using 127-bit IPv6 Prefixes on Inter-Router > > > Links > > > > Author(s) : M. Kohno, et al. > > > > Filename : draft-ietf-6man-prefixlen-p2p-00.txt > > > > Pages : 9 > > > > Date : 2010-10-15 > > > > > > > > http://tools.ietf.org/html/draft-ietf-6man-prefixlen-p2p-00 > > > > > > > > as a Proposed Standard. Substantive comments and statements of > > support > > > for advancing this document should be directed to the mailing list. > > > Editorial suggestions can be sent to the authors. This last call > > will > > end > > > on December 6, 2010. > > > > > > > > Regards, > > > > Bob Hinden & Brian Haberman > > > > 6MAN Chairs > > > > > > > > ------------------------------------------------------------------- > > - > > > > IETF IPv6 working group mailing list > > > > [email protected] > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > ------------------------------------------------------------------- > > - > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > [email protected] > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [email protected] > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
