Re: <draft-ietf-6man-rfc4291bis-09.txt>

[Mark Smith <[e-mail]>]

On 6 July 2017 at 16:40, David Farmer <[e-mail]> wrote:
>
>
> On Wed, Jul 5, 2017 at 3:34 PM, Bob Hinden <[e-mail]> wrote:
>>
>> Hi David,
>>
>> > On Jul 3, 2017, at 1:22 PM, David Farmer <[e-mail]> wrote:
>>
>> > However, I still think the following paragraph is still too easily
>> > misunderstood to imply subnets must be /64 or 64 bits for both address
>> > generation and on-link determination.
>> >
>> >    Interface Identifiers are 64 bit long except if the first three bits
>> >    of the address are 000, or when the addresses are manually
>> >    configured, or by exceptions defined in standards track documents.
>> >    The rationale for using 64 bit Interface Identifiers can be found in
>> >
>> >    [RFC7421].  An example of a standards track exception is [RFC6164]
>> >    that standardises 127 bit prefixes on inter-router point-to-point
>> >    links.
>> >
>> >
>> > How about a note clarifying the intent of the this paragraph, something
>> > like this;
>> >
>> >       Note: While the previous paragraph does imply 64 bit subnet
>> > prefixes
>> >       are typically assigned to most links. It does not imply anything
>> >       about what portion, if any, of a subnet is considered to be
>> > on-link,
>> >       see Section 2.1 for more discussion. However, Router
>> > Advertisements
>> >       [RFC4861] specifying 64 bit on-link prefixes are typically
>> >       configured on most links.
>>
>> Now that the text you refer to is in Section 2.4.1. "Interface
>> Identifiers”, it is about Interface Identifiers, very little is said about
>> prefixes (except that IIDs are required to be unique on a prefix, but even
>> that is about IIDs).  I don’t think it is implying anything one way or about
>> on-link properties.  I think that is covered pretty well in the new
>> paragraph in Section 2.1 "Addressing Model” that includes the link to
>> RFC5942.
>
>
> As long as the others that who were insisting that the statement "IIDs MUST
> be 64" means that subnets must be 64 bits for both address generation and
> on-link determination are satisfied that this is not the case for on-link
> determination based on what has been added to section 2.1, then I could live
> without this.

I'm confused by this and have been on the occasions it has been
discussed. I also don't understand why it matters and is related to
the on-link property of a subnet prefix.

"2.4. Unicast Addresses" says that IIDs are 128 bits minus the size of
the subnet prefix.

If the subnet prefix is a /64, then the IID is 64 bits; for a /127,
the IID is 1 bit in size. Of course, conversely, a 64 bit IID results
in a 64 bit subnet prefix.

If you're describing some other property of the bits that are not part
of the subnet prefix, and that part isn't 128-subnet prefix size i.e.
the IID, then IID is not the accurate term for it and it needs to be
explained at least here if not in the RFC and given another name.

>
> However, I like the idea of having some kind of recommendation for the
> on-link prefix.  I don't think there is guidance anywhere else as to what
> the on-link prefix should normally be, at least explicitly, and the
> addressing architecture seems like as good of a place as any to recommend
> something in this regard.
>

I'm not sure what an "on-link prefix" is in the sense of the above paragraph.

A subnet-prefix is assigned to a link, which is a statement of where
that the set of addresses (or IIDs) that fall within the subnet-prefix
are present within the network topology. It is a statement to the
forwarding domain as to the network location of a set or range of
addresses.

On-link or not for a subnet-prefix is a statement to the hosts
attached to a link whether they are to try to directly reach other
addresses within the subnet-prefix across the link, or whether they're
to use their default router to reach them. A host doesn't have to have
an address from within the subnet-prefix for it to consider
destinations within the subnet-prefix reachable directly across the
link.

e.g.

Host address: 2001:db8::1234

RA PIOs host receives : 2001:db8::/64 [on-link], 2001:db8:abcd::/64 [on-link]

With those RA PIOs, the host will attempt to directly send across the
link to destinations 2001:db8::5678 and 2001:db8:abcd::fffe, and will
do so for all addresses within the 2001:db8::/64 and
2001:db8:abcd::/64 subnet-prefixes.


If the host instead had just received

RA PIOs host receives : 2001:db8:abcd::/64 [on-link]

Then it would only try to directly send across the link to
destinations that fall within 2001:db8:abcd::/64. It would not try to
directly send to destinations inside 2001:db8::/64, even though its
2001:db8::1234 address is within that same /64, as, per RFC5942, all
destinations are by default off-link except for Link-Local
destinations.


So to me an "on-link prefix" is a subnet-prefix that hosts will
attempt to send directly to across the link they're attached to,
indicated to the host by RA PIOs, ICMP redirects or manual
configuration on the host (per RFC5942). What you and others are
describing as an "on-link prefix" sounds like something different to
that.


> Instead of directly recommending 64 bits, maybe in section 2.1 recommend
> that in most cases on-link prefixes are configured the same as the subnet
> prefixes they are associated with.  Combined this with 64 bit IIDs and
> therefore 64 bit subnet prefixes, you get a recommendation for 64 bit
> on-link prefixes in most cases.
>
> While IIDs were the primary controversy, there were several other points
> raised during the Last Call discussion, is there a plan to revisit any of
> these as well?