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

[David Farmer <[e-mail]>]

Sorry let me try that again, that got launched early. You probably figured
out what I meant, but just in case, What I meant to say is below.

On Mon, Aug 13, 2018 at 2:41 PM, Ole Troan <[e-mail]> wrote:

>
>
> On 13 Aug 2018, at 21:28, David Farmer <[e-mail]> wrote:
>
>
> On Mon, Aug 13, 2018 at 1:56 PM, Ole Troan <[e-mail]> wrote:
>
>>
>>
>> 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.
>>
>
> Yes, if and only if there is a PIO with A=1, are you saying there MUST
> always be a /64 PIO with A=1?
>
>
> No, I would imagine manual configuration would be more common for this
> scenario.
>
> However, I believe C does say one thing about the rest of the /64, it
> can't somehow be on-link or otherwise associated with a different link
> network either.
>
>
> It can. The fact that L=1 means just that.
> If you generated a set of addresses out of a /64, then advertised /80s
> (from the /64) on a set of links and place hosts with corresponding
> addresses on the links, you would be perfectly within the letter of rfc4291.
>
> DAD wouldn’t work well though.
>

The last of RFC4291 section 2.1 says;

   Currently, IPv6 continues the IPv4 model in that a subnet prefix is
   associated with one link.  Multiple subnet prefixes may be assigned
   to the same link.

In my mind assigning any part of the /64 to any other link network would
violate that rule. Or is a PIO with A=1 not a subnet prefix either?



> Cheers
> Ole
>
>
>
>> 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
>> --------------------------------------------------------------------
>>
>>
>
>
> --
> ===============================================
> David Farmer               Email:[e-mail]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE
> <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g>
>       Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>
>


-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================