Re: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)

[David Farmer <[e-mail]>]

On Sun, Jul 9, 2017 at 9:03 PM, Lorenzo Colitti <[e-mail]> wrote:

> On Mon, Jul 10, 2017 at 6:09 AM, David Farmer <[e-mail]> wrote:
>
>> So, What should we say in RFC4291bis? Personally I'd prefer we eliminate
>> the term subnet from RFC4291bis, but assuming that won't happen how about
>> the following;
>>
>> 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.  The relationship between links and IPv6 subnet prefixes differs
>> from the IPv4 model in that the prefixes used for on-link determination are
>> separate and may differ from the assigned subnet prefixes. However, on-link
>> prefixes identical with assigned subnet prefixes are recommended. A prefix
>> length associated with a manually configured address determines the on-link
>> prefix associated with the manually configured address. See [RFC5942] "The
>> IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" for
>> more details.
>>
>>
>> Note: Any on-link prefixes longer than a covering assigned subnet prefix
>> must be associated with the same link as the assigned subnet prefix. Also,
>> any assigned subnet prefixes longer than a covering on-link prefix must be
>> associated with the same link as the on-link prefix.
>>
>>
>> ----
>>
>> IPv6 unicast routing is based on on-link prefixes of any valid length up
>> to 128 [BCP198], which are not necessarily the same as the subnet prefixes
>> assigned to a link.
>>
>>
>> ----
>>
>> When forming or assigning unicast addresses, except those that start with
>> the binary value 000, Interface IDs are required to be 64 bits long.  The
>> rationale for using 64 bit Interface Identifiers can be found in [RFC7421].
>>
>> Note: the previous paragraph implies nothing about on-link determination
>> which as discussed in section 2.1 is separate from subnet assignment in
>> IPv6.
>>
>>
> Thanks for putting this all together. I think it's the best assessment of
> the current state of the standards that I've seen so far.
>

Glad it was useful.


> I'm not sure the text covers RFC6164 though; I'm not sure whether current
> deployments of /127 meet the "Any on-link prefixes longer than a covering
> assigned subnet prefix must be associated with the same link as the
> assigned subnet prefix" text. I'd expect many networks to number entirely
> separate links using /127s that are all drawn from one covering /64; at
> least, I know that I've written addressing plans that do that and are still
> in use.
>

I agree it doesn't really cover RFC6164, and an exception covering it needs
to be added. However, I wasn't sure how narrow or broad of an exception to
add. This is basically comes back to Brian's question, where is the right
balance point "between excessive rigidity and excessive flexibility".

We could add a very narrowly scoped exception basically adding, "or when
used for point-to-point router links [RFC6164]", or very broad exception,
"or when the addresses are manually configured", or possible something
focused on routers only, "or when used on a link with only routers and not
any hosts."

As you bring up, assigning a bunch of point-to-point router links out of a
single /64 could be quite common.  However there are other considerations
too, like router loopback /128s, maybe /126s for point-to-point, or small
networks connecting only routers.  I think it could also be quite common to
assign router loopbacks out of a common /64, maybe even the same one as the
point-to-point router links. And then I've seen some networks use /126s to
coincide with /30s for IPv4, instead of /127s with /31s for IPv4. Also, if
you connect a small group of routers but no hosts should you have to use
/64 assigned subnets?

So, what is the right balance?   Do we need an RFCs explicitly allowing
/128 router loopbacks and small networks connecting only routers?  Or, how
broad of an exception should we make?

Thanks.

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