Subject: Re: SLAAC on non-/64 networks

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Fri, 23 Mar 2018 20:36:34 +0000

> Message: 4
> Date: Fri, 23 Mar 2018 09:14:47 +0900
> From: DY Kim <[email-masked]>
> To: Erik Kline <[email-masked]>
> Cc: Lorenzo Colitti <[email-masked]>, Fernando Gont
> 	<[email-masked]>, IETF IPv6 Mailing List <[email-masked]>
> Subject: Re: SLAAC on non-/64 networks
> Message-ID: <[email-masked]>
> Content-Type: text/plain;	charset=utf-8
> 
> It?s interesting that RA with other than /64 might not work. As I understand,
> IPv6 routers are meant to work for any prefix lengths...
> 
> ---
> DY
>
> Message: 4
> Date: Tue, 20 Mar 2018 22:42:58 +0000
> From: JORDI PALET MARTINEZ <[email-masked]>
> To: IETF IPv6 Mailing List <[email-masked]>
> Subject: Re: SLAAC on non-/64 networks
> Message-ID: <[email-masked]>
> Content-Type: text/plain;	charset="UTF-8"
> 
> I think the overall conversation is more about the broadband providers.
> 
> I agree that the cellular world (in the case of a smartphone) is a specific case,
> and we have mention it in RIPE690:
> 
> 4.2.4. Considerations for Cellular Operators
> There is a clear exception to the rule described above when assigning prefixes in
> a cellular network. In this case, a /64 will need to be provided for each PDP
> context for cellular phones, whereas for LTE modems/routers, i.e. in the case of
> broadband by means of cellular access, it will still be necessary to choose a /48
> or /56 in accordance with the aforementioned considerations.
> 
> Regards,
> Jordi

Linux 2.6.27 host creates SLAAC addresses only for /64 prefixes. ISP cannot issue anything longer than /64 because of this restriction. Devices using Linux, for example, will not work with prefixes '>' /64, so ISPs have no choice but to issue at least one /64 prefix. Many in the discussion believe that is good for the users because ISPs have no choice but to follow /64 recommendation. I agree with them. 

Talking about the hard /64 limit, Linux does not create SLAAC addresses for prefixes '<' /64, and this is unnecessary restriction. Client should be able to use any prefix '<' /64, like /48 or /56, for SLAAC.

Now, how about relaxing the SLAAC prefix length in another direction? Why not relaxing RFC2464 requirement to, 
  "An IPv6 address prefix used for stateless autoconfiguration [ACONF]
   of an Ethernet interface must have a length smaller or equal to 64 bits." ?

This will give SLAAC more flexibility. It will allow a user to have multiple '<=' /64 subnets, each using /64 or '<' 64/ prefix for SLAAC.

If there is MUST CE requirement in RFC 7084, and CE must get "a prefix large enough to assign one /64 for each of its interfaces", then SLAAC can use any '>' /64 prefix. This satisfies ISP requirement. However, this will affect address privacy. rfc7217 uses arbitrary IID length. So, upper prefix limit for the host SLAAC should be determined by IID length.

Overall, RFC2464 SLAAC prefix length should be revisited.

Regards,
Dusan