excuse bad email form. this is an ipad. randy
On Nov 22, 2010, at 9:27, "George, Wes E [NTK]" <wesley.e.geo...@sprint.com> wrote: > In general, I support advancement of this draft, since it is largely > documenting an existing practice, but I think that Mark brings up a few > points that should be incorporated as clarification in the draft. More > comments below inline > > Wes George > >> -----Original Message----- >> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of >> Miya Kohno >> Sent: Sunday, November 21, 2010 8:42 AM >> To: Mark Smith >> Cc: 6man Mailing List >> Subject: RE: 6MAN WG Last Call: <draft-ietf-6man-prefixlen-p2p-00.txt> >> >> Hi Mark, >> >> (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. >> >> (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. >> >> (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: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] 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 <bob.hin...@gmail.com> 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 >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> ------------------------------------------------------------------- >> - >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
