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

From: David Farmer <[email-masked]>
Date: Mon, 13 Aug 2018 15:06:25 -0500

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 <[email-masked]> wrote:

>
>
> On 13 Aug 2018, at 21:28, David Farmer <[email-masked]> wrote:
>
>
> On Mon, Aug 13, 2018 at 1:56 PM, Ole Troan <[email-masked]> wrote:
>
>>
>>
>> On 13 Aug 2018, at 20:18, 神明達哉 <[email-masked]> wrote:
>>
>> At Sun, 12 Aug 2018 16:07:25 -0500,
>> David Farmer <[email-masked]> 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
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>
>
> --
> ===============================================
> David Farmer               Email:[email-masked]
> 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: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>
>

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

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Aug 2018 22:48:39 +0200

David,

> On 13 Aug 2018, at 22:06, David Farmer <[email-masked]> wrote:
> 
> 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.
> 
>>>>> > 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.
>>>>> 
>>>>> > 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.
>>>>> 
>>>>> > So, Mark do you support some kind of clarification on that the IID length
>>>> 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.
>>> 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.
>> 
>> 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.
>> 
> 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?
> 

From rfc4861:

Stateless Address Autoconfiguration must also obtain subnet prefixes as part of configuring addresses. Although the prefixes used for address autoconfiguration are logically distinct from those used for on-link determination, autoconfiguration information is piggybacked on Router Discovery messages to reduce network traffic. Indeed, the same prefixes can be advertised for on-link determination and address autoconfiguration by specifying the appropriate flags in the Prefix Information options. See [ADDRCONF] for details on how autoconfiguration information is processed.

So to answer your question, no I don’t believe a PIO with A=1,L=0 is a section 2.1 subnet prefix.

A fundamental difference between IPv4 and IPv6 is that in IPv6, a host and a default router does not both need to have an address within the same subnet prefix. 

Cheers 
Ole

---

From: David Farmer <[email-masked]>
Date: Mon, 13 Aug 2018 16:15:32 -0500

On Mon, Aug 13, 2018 at 3:48 PM, Ole Troan <[email-masked]> wrote:

> Stateless Address Autoconfiguration must also obtain subnet prefixes
>    as part of configuring addresses.  Although the prefixes used for
>    address autoconfiguration are logically distinct from those used for
>    on-link determination, autoconfiguration information is piggybacked
>    on Router Discovery messages to reduce network traffic.  Indeed, the
>    same prefixes can be advertised for on-link determination and address
>    autoconfiguration by specifying the appropriate flags in the Prefix
>    Information options.  See [ADDRCONF <https://tools.ietf.org/html/rfc4861#ref-ADDRCONF>] for details on how
>    autoconfiguration information is processed.
>
>
I hope A=1, L=1 is a subnet prefix, otherwise I'm at a loss as to what is
subnet prefix. :)

So, then I think I'm hearing;
A=1,L=1 is a subnet prefix as discussed in RFC4291
A=1,L=0 not a subnet prefix as discussed in RFC4291
A=0,L=1 not a subnet prefix as discussed in RFC4291
A=0,L=0 clearly not a subnet prefix, its meaning is defined RFC8043

That most definitely needs to be clarified somewhere, because I'm not sure
that is intuitive, at least it's not to me.

I feel like we might be getting somewhere.

Thank you.

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Aug 2018 23:27:45 +0200

> On 13 Aug 2018, at 23:15, David Farmer <[email-masked]> wrote:
> 

Why not?

Cheers 
Ole

---

From: David Farmer <[email-masked]>
Date: Mon, 13 Aug 2018 16:43:34 -0500

> A=0,L=1 not a subnet prefix as discussed in RFC4291

Well, you said it doesn't say anything about an IID. In the /112 example I
provided.

And my response was then it must not be a subnet prefix, maybe you missed
that.

The diagram in RFC4291 section 2.5 defines a clear relationship between a
subnet prefix and an IID.

   |          n bits               |           128-n bits            |

If it is a subnet prefix it clearly has an IID length of 16. Or you also
need to clarify that diagram as well.

Oh, and I confused RFC8043 with RFC8028 in the previous table.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Aug 2018 14:37:35 +1200

> A=0,L=0 clearly not a subnet prefix, its meaning is defined RFC8043

It is given a specific meaning in RFC8028, so I think you need to cite both.

Regards
   Brian