Hi Miya,

I don't find your answers acceptable I'm afraid, but aren't willing to
spend any more of my time addressing them. Even though I disagree
with /127s in principle, my secondary goal of trying to ensure this
standards-track ID, if published, wasn't ambiguous, vague and
conflicting with other standards track IPv6 RFCs also seems to be a
lost cause.

Regards,
Mark.

On Sun, 21 Nov 2010 21:42:05 +0800
Miya Kohno <mko...@juniper.net> wrote:

> Hi Mark,
> 
>  (a)-(c): 
> Link local is orthogonal in this topic. This document does not address
> it. 
> 
>  (d)-(f):
> Static IPv6 neighbor has been used occasionally. There are quite a few
> sources which describe it, so please refer to them. 
> 
>  (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
--------------------------------------------------------------------

Reply via email to