Subject: RE: ipv6 Digest, Vol 167, Issue 70

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 28 Mar 2018 21:23:54 +0000

>     > The more I think about it, the more I realise that it's the mass-market CE
> routers
>     > that maintain the /64 boundary, not the text of any RFC.
> 
>     it certainly seems that there need to be continued efforts made to
>     change the prefix assignment mindset to be generous with IPv6 and
>     allow sufficient subnets to users!
> 
> Let's move on !
[[Dusan]] 
What is a flexible host algorithm?

RFC2464: 
   An IPv6 address prefix used for stateless autoconfiguration [ACONF]
   of an Ethernet interface must have a length of 64 bits.

Can we change this definition? For example:

.. For stateless autoconfiguration [ACONF], an Ethernet interface MUST have 
...at least one /64, or shorter, bits IPv6 address prefix. In addition, the interface can have 
   other prefixes of any length. A host can use all the prefixes for SLAAC and might 
...prefer creating SLAAC addresses using only longer than /64 prefixes.
.
rfc6724#section-5, SASA rule 8 will prefer longer prefixes.

Thanks,
Dusan

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Mar 2018 12:42:07 +0200

Le 28/03/2018 à 23:23, Mudric, Dusan (Dusan) a écrit :
> [[Dusan]] What is a flexible host algorithm?
> 
> RFC2464: An IPv6 address prefix used for stateless autoconfiguration
> [ACONF] of an Ethernet interface must have a length of 64 bits.
> 
> ... For stateless autoconfiguration [ACONF], an Ethernet interface
> MUST have at least one /64, or shorter, bits IPv6 address prefix.
> In addition, the interface can have other prefixes of any length. A
> host can use all the prefixes for SLAAC and might prefer creating
> SLAAC addresses using only longer than /64 prefixes.

I would support improvement of RFC2464 along these lines.

The reason is that RFC2464 is a basis for many other IPv6-over-foo RFCs
which have nothing to do with Ethernet. (e.g. 802.15.4, NFC, and
others).  These links can very well use other IID sizes.

> .. rfc6724#section-5, SASA rule 8 will prefer longer prefixes.

YEs, Rule 8 should use longest prefix matches, instead of fixed length 
matches (64).  It is good.

But that RFC6724 could be updated too in its definition of the 
CommonPrefixLen function.

RFC6724 says:
>  For
>    example, CommonPrefixLen(fe80::1, fe80::2) is 64.

Such a function can never issue 64 if it does not have a 3rd parameter 
saying that it is Ethernet.  Just comparing fe80::1 to fe80::2, with no 
other help, such a function can only output 126.

If the hint is Ethernet, then the output will be 64.
If the hint is "IPv6 addressing architecture" with first 10 bits
1111 1110 10 (hextet fe80), then the output will be 10.

Alex

> 
> Thanks, Dusan
> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 29 Mar 2018 14:34:21 +0000

> -----Original Message-----
> From: Alexandre Petrescu [mailto:[email-masked]]
> Sent: Thursday, March 29, 2018 6:42 AM
> To: Mudric, Dusan (Dusan); [email-masked]
> Subject: Re: SLAAC on non-/64 networks
> 
> 
> 

[[Dusan]] 
[[Dusan]] 
Or, instead:

rfc6724, "2.2.  Common Prefix Length

   We define the common prefix length CommonPrefixLen(S, D) of a source
   address S and a destination address D as the length of the longest
   prefix (looking at the most significant, or leftmost, bits) that the
   two addresses have in common, up to the length of S's prefix (i.e.,
   the portion of the address not including the interface ID).  For
   example, CommonPrefixLen(fe80::1, fe80::2) is 64."

Define the 'Common Prefix Length' as:
   the common prefix length CommonPrefixLen(S/P_S, D/P_D) of a {source
   address S, source prefix P_S) and a {destination address D, destination prefix P_D} as 
   the number of common MSB bits, up to the length of the shortest
   prefix (looking at the P_S and P_D), that the two addresses have in common.
   For example if a source host A is assigned 2001:db8:1aaa:1bbb::/64 and 
   a more specific prefix 2001:db8:1aaa:1bbb:1ccc::/80, and host A wants to use both prefixes for SLAAC,
   when host A needs to reach host B with the prefix 2001:db8:1aaa:1bbb:1ccc:f::/88
   CommonPrefixLen (2001:db8:1aaa:1bbb:1ccc::100/80, 2001:db8:1aaa:1bbb:1ccc:f::300/88)=80,
    is greater than CommonPrefixLen (2001:db8:1aaa:1bbb::200/64, 2001:db8:1aaa:1bbb:1ccc:f::300/88)=64.
   If host A needs to reach host C with the prefix 2001:db8:1aaa::/48
   CommonPrefixLen (2001:db8:1aaa:1bbb:1ccc::100/80, 2001:db8:1aaa:1bbb:1ccc:f::400/48)=48,
    is equal to CommonPrefixLen (2001:db8:1aaa:1bbb::200/64, 2001:db8:1aaa:1bbb:1ccc:f::400/48)=48.
   If host A needs to reach host D with the prefix 2001:db8:1ddd::/48
   CommonPrefixLen (2001:db8:1aaa:1bbb:1ccc::100/80, 2001:db8:1ddd:1bbb:1ccc:f::500/48)=36,
    is equal to CommonPrefixLen (2001:db8:1aaa:1bbb::200/64, 2001:db8:1ddd:1bbb:1ccc:f::500/48)=36.

RFC6724 definition has a problem when D's prefix is shorter that S's prefix and MSB bits in D's IID match LSB bits in S. This means not all S's prefix bits can be used for the comparison. For example, when A wants to reach C, where C IID=1bbb:1ccc:f::400, RFC6724 will compare all S's prefix bits against D_C and CommonPrefixLen (2001:db8:1aaa:1bbb:1ccc::100/80, 2001:db8:1aaa:1bbb:1ccc:f::400/48)=80.

The new rule does not compare IID bits against prefix bits. It allows comparison of address of any prefix length.

---

From: DY Kim <[email-masked]>
Date: Fri, 30 Mar 2018 07:54:52 +0900

And… I don’t think it suffices to revise RFC2462 and/or RFC6724.

We have to remove ’64’ from RFC4291, too, I’d think.

---
DY

> On 29 Mar 2018, at 19:42, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
>>> it certainly seems that there need to be continued efforts made to change the prefix assignment mindset to be generous with IPv6 and allow sufficient subnets to users!
>>> Let's move on !
> YEs, Rule 8 should use longest prefix matches, instead of fixed length matches (64).  It is good.
> 
> But that RFC6724 could be updated too in its definition of the CommonPrefixLen function.
> 
> RFC6724 says:
>> For
> Such a function can never issue 64 if it does not have a 3rd parameter saying that it is Ethernet.  Just comparing fe80::1 to fe80::2, with no other help, such a function can only output 126.
> 
>> -------------------------------------------------------------------- IETF IPv6 working group mailing list [email-masked] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
> 
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6