Re: New Version Notification for draft-farmer-6man-exceptions-64-05.txt

[Ole Troan <[e-mail]>]

> On 13 Aug 2018, at 20:18, 神明達哉 <[e-mail]> wrote:
> 
> At Sun, 12 Aug 2018 16:07:25 -0500,
> David Farmer <[e-mail]> wrote:
> > 
> > However, in RFC4291;
> > 
> >    A slightly sophisticated host (but still rather simple) may
> >    additionally be aware of subnet prefix(es) for the link(s) it is
> >    attached to, where different addresses may have different values for
> >    n:
> > 
> >    |          n bits               |           128-n bits            |
> >    +-------------------------------+---------------------------------+
> >    |       subnet prefix           |           interface ID          |
> >    +-------------------------------+---------------------------------+
> > 
> >    Though a very simple router may have no knowledge of the internal
> >    structure of IPv6 unicast addresses, routers will more generally have
> >    knowledge of one or more of the hierarchical boundaries for the
> >    operation of routing protocols.  The known boundaries will differ
> >    from router to router, depending on what positions the router holds
> >    in the routing hierarchy.
> > 
> > Combined with;
> > 
> >    For all unicast addresses, except those that start with the binary
> >    value 000, Interface IDs are required to be 64 bits long
> > 
> > This text clearly implies subnet prefixes are 64-bit in length, and it does
> > not clearly exempt routing and on-link determination from that implication.
> 
> You are right.  And, at least rfc4291bis-09 tries to clarify that a
> little bit:
> 
>    IPv6 unicast routing is based on prefixes of any valid length up to
>    128 [BCP198].
> 
> > Further, since the paragraph following the diagram above immediately goes
> > on to talk about routing, it seems quite logical that it is meant to imply
> > that at least the subnet prefixes used in routing are implied to be 64-bit
> > in length.
> 
> That's an understandable concern.  The "Though a very simple
> router..." paragraph should probably be more clarified to avoid
> confusion.
> 
> > So, Mark do you support some kind of clarification on that the IID length
> > does not imply that the subnet prefixes for routing and on-link
> > determination are required to be 64 bit in length?
> 
> I can't speak for others, but I think that kind of clarification is
> very helpful.  It's also related to why I asked this question for
> draft-farmer-6man-exceptions-64-05:
> 
> >  configuration: if you do
> >  ifconfig en0 2001:db8:1:2::bad prefixlen 80
> [....]
> > - Section 2.2: related to the previous point, if we manually configure
> >  an address as above, what's the IID of this address?  Is it the
> >  lower 48 bits (0:0:bad)?  Or should the IID be considered empty as
> >  the address in this case is to be considered an "opaque 128-bit
> >  quantity"?
> 
> Either way, the fact that 2001:db8:1:2::/80 is an on-link prefix in
> this case does not contradict the addressing architecture (and it
> would make sense to clarify/emphasize that point explicitly in
> draft-farmer-6man-exceptions-64).  And, regarding the IID, I believe
> we could adopt either explanation:
> 
> A: the IID length is 48 bits in this case.  This will have to be
>    considered an exception to Section 2.5.1 of RFC4291.
> B: the IID is empty (or does not exist) in this case.  An address
>    configured this way should be considered to have no internal
>    structure (as shown in the first diagram of Section 2.5 of
>    RFC4291).  In that sense it could still be considered compliant to
>    RFC4291, but it's probably helpful if we also clarify that this is
>    a "kind of exception" in that only the "minimum" form of
>    architecture applies and Section 2.5.1 of RFC4291 is simply "not
>    applicable".

C: 64-bit IID with /80 on-link prefix. For SLAAC that’s a /64 PIO with A=1 and L=0 and a PIO with /80 L=1.  Meaning there is nothing said about the on-link properties of the rest of the /64.
I don’t think this is an exception. 

Cheers,
Ole

> 
> According to the recent messages of this thread, option #B seems to be
> preferred (and I personally also prefer that option).  I'd also note
> that an "exception" of RFC6164 can be explained as an instance of this
> option in practice, since the addresses assigned on inter-router p2p
> links are most likely to be configured manually.
> 
> --
> JINMEI, Tatuya
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------