Subject: draft-bourbaki-6man-classless-ipv6-00

From: Job Snijders <[email-masked]>
Date: Fri, 2 Jun 2017 16:11:12 +0200

Hi Working Group,

Please review the below.

Kind regards,

Job

----- Forwarded message from [email-masked] -----

Date: Mon, 22 May 2017 04:25:28 -0700
From: [email-masked]
To: Job Snijders <[email-masked]>, Randy Bush <[email-masked]>, Christopher Morrow <[email-masked]>,
	Fernando Gont <[email-masked]>, Nick Hilliard <[email-masked]>, Geoff Huston
	<[email-masked]>, Brian Carpenter <[email-masked]>, Chris Morrow
	<[email-masked]>
Subject: New Version Notification for draft-bourbaki-6man-classless-ipv6-00.txt

A new version of I-D, draft-bourbaki-6man-classless-ipv6-00.txt
has been successfully submitted by Randy Bush and posted to the
IETF repository.

Name:		draft-bourbaki-6man-classless-ipv6
Revision:	00
Title:		IPv6 is Classless
Document date:	2017-05-22
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/internet-drafts/draft-bourbaki-6man-classless-ipv6-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bourbaki-6man-classless-ipv6/
Htmlized:       https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-bourbaki-6man-classless-ipv6-00

Abstract:
   Over the history of IPv6, various classful address models have been
   proposed, none of which has withstood the test of time.  The last
   remnant of IPv6 classful addressing is a rigid network interface
   identifier boundary at /64.  This document removes the fixed position
   of that boundary for interface addressing.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

----- End forwarded message -----

---

From: Peter Hessler <[email-masked]>
Date: Fri, 2 Jun 2017 16:12:59 +0200

Support

On 2017 Jun 02 (Fri) at 16:11:12 +0200 (+0200), Job Snijders wrote:
:Hi Working Group,
:
:Please review the below.
:
:Kind regards,
:
:Job
:
:----- Forwarded message from [email-masked] -----
:
:Date: Mon, 22 May 2017 04:25:28 -0700
:From: [email-masked]
:To: Job Snijders <[email-masked]>, Randy Bush <[email-masked]>, Christopher Morrow <[email-masked]>,
:	Fernando Gont <[email-masked]>, Nick Hilliard <[email-masked]>, Geoff Huston
:	<[email-masked]>, Brian Carpenter <[email-masked]>, Chris Morrow
:	<[email-masked]>
:Subject: New Version Notification for draft-bourbaki-6man-classless-ipv6-00.txt
:
:
:A new version of I-D, draft-bourbaki-6man-classless-ipv6-00.txt
:has been successfully submitted by Randy Bush and posted to the
:IETF repository.
:
:Name:		draft-bourbaki-6man-classless-ipv6
:Revision:	00
:Title:		IPv6 is Classless
:Document date:	2017-05-22
:Group:		Individual Submission
:Pages:		7
:URL:            https://www.ietf.org/internet-drafts/draft-bourbaki-6man-classless-ipv6-00.txt
:Status:         https://datatracker.ietf.org/doc/draft-bourbaki-6man-classless-ipv6/
:Htmlized:       https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-00
:Htmlized:       https://datatracker.ietf.org/doc/html/draft-bourbaki-6man-classless-ipv6-00
:
:
:Abstract:
:   Over the history of IPv6, various classful address models have been
:   proposed, none of which has withstood the test of time.  The last
:   remnant of IPv6 classful addressing is a rigid network interface
:   identifier boundary at /64.  This document removes the fixed position
:   of that boundary for interface addressing.
:
:                                                                                  
:
:
:Please note that it may take a couple of minutes from the time of submission
:until the htmlized version and diff are available at tools.ietf.org.
:
:The IETF Secretariat
:
:
:----- End forwarded message -----
:
:--------------------------------------------------------------------
:IETF IPv6 working group mailing list
:[email-masked]
:Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
:--------------------------------------------------------------------

-- 
If Reagan is the answer, it must have been a VERY silly question.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 2 Jun 2017 23:33:41 +0900

Do not support. A few reasons:

   - The /64 boundary is beneficial for many reasons. See RFC 7421 and RFC
   7934.
   - The document lists no compelling use cases of what you can do with
   less than 2^64 addresses per link than you can't do with a 2^64 addresses
   per link.
   - The only technical motivation in this draft seems to be "classful
   addressing was a bad idea in IPv4". That's not a valid argument in IPv6
   because the address space is completely different. A /64 is *four billion
   times* bigger than the IPv4 internet. That's 10,000 times more than the
   difference between a grain of sand and the whole planet we live on. Such a
   huge scaling difference pretty much invalidates any argument that solutions
   that worked well in IPv4 will work well in IPv6.
   - Routing on any prefix length is already required by the standards -
   see BCP 198.

Please stop trying to make IPv6 be the same as IPv4. That will take away
our ability to make the Internet better once IPv4 is gone.

On Fri, Jun 2, 2017 at 11:12 PM, Peter Hessler <[email-masked]> wrote:

> :Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-bourbaki-6man-classless-ipv6-00
> :
> :
> :Abstract:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 2 Jun 2017 16:36:25 +0200

I support it.

There is some additional matters I would like to suggest.

> Thus, a correct implementation of SLAAC must in fact allow for any
> prefix length, with the value being a parameter per interface.  For
> instance, the Interface Identifier length in the recommended (see
> [RFC8064]) algorithm for selecting stable interface identifiers
> [RFC7217] is a parameter, rather than a hardcoded value.

As another example, the linux kernel MUST NOT complain when it receives 
an RA containing a prefix with plen==65 (currently it does).

Alex

Le 02/06/2017 à 16:11, Job Snijders a écrit :
> Date: Mon, 22 May 2017 04:25:28 -0700 From: [email-masked]
> To: Job Snijders <[email-masked]>, Randy Bush <[email-masked]>,
> Christopher Morrow <[email-masked]>, Fernando Gont
> <[email-masked]>, Nick Hilliard <[email-masked]>, Geoff Huston
> <[email-masked]>, Brian Carpenter <[email-masked]>, Chris
> Morrow <[email-masked]> Subject: New Version Notification for
> draft-bourbaki-6man-classless-ipv6-00.txt
>
>
> A new version of I-D, draft-bourbaki-6man-classless-ipv6-00.txt has
> been successfully submitted by Randy Bush and posted to the IETF
> repository.
>
> Name:		draft-bourbaki-6man-classless-ipv6 Revision:	00 Title:		IPv6
> is Classless Document date:	2017-05-22 Group:		Individual Submission
> Pages:		7 URL:
> https://www.ietf.org/internet-drafts/draft-bourbaki-6man-classless-ipv6-00.txt
>
>
Status: 
https://datatracker.ietf.org/doc/draft-bourbaki-6man-classless-ipv6/
> Htmlized:
> https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-bourbaki-6man-classless-ipv6-00
>
>
>
> Abstract: Over the history of IPv6, various classful address models
> have been proposed, none of which has withstood the test of time.
> The last remnant of IPv6 classful addressing is a rigid network
> interface identifier boundary at /64.  This document removes the
> fixed position of that boundary for interface addressing.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
>
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Job Snijders <[email-masked]>
Date: Fri, 2 Jun 2017 16:56:55 +0200

Dear Lorenzo,

On Fri, Jun 02, 2017 at 11:33:41PM +0900, Lorenzo Colitti wrote:
>    - The /64 boundary is beneficial for many reasons. See RFC 7421 and RFC 7934.

>From our brief hallway conversation at IETF 98 I was under the
impression that you have a strong personal preference for the /64
boundary because you believe there to be '64 bits for the network' and
'64 bits for the end-user' - however I do not share your (simplistic?)
view of the world.

Depending on the context, there may be more then 2 parties: an end-user
might be a network provider themselves, and these functions can be
recursive. What if someone resells a service to someone else? Without
flexibility on the /64 boundary one can't cut up the assigned space in
smaller pieces. 

It's been mentioned a couple of times before: any fixed boundary
(including /64) is detrimental to permissionless expansion at the edge
of the network.

>    - The document lists no compelling use cases of what you can do
>    with less than 2^64 addresses per link than you can't do with a
>    2^64 addresses per link.

This is not true. The security section for instance shows: "In such
cases, the use of smaller subnets forces an operational limit on such
data structures, thus helping mitigate some pathological behaviors (such
as Neighbor Cache Exhaustion attacks)." 

>    that worked well in IPv4 will work well in IPv6.

Would be a shame to throw away lessons learned from IPv4.

>    - Routing on any prefix length is already required by the standards -

Yes, RFC7608 is referenced as suggested reading.

> Please stop trying to make IPv6 be the same as IPv4. That will take
> away our ability to make the Internet better once IPv4 is gone.

I believe there to be tangible merit in making IPv6 feel and look more
like IPv4. Perhaps this becomes more apparent when one shifts the
innovation focus from layer-3 to higher layers.

Making IPv6 look more like IPv4 (for instance through broader adoption
of DHCPv6 w/ routing options, and classlessness like in IPv4) will
positively impact IPv6 deployment.

Kind regards,

Job

---

From: Erik Kline <[email-masked]>
Date: Sat, 3 Jun 2017 00:07:42 +0900

On 2 June 2017 at 23:56, Job Snijders <[email-masked]> wrote:

> (including /64)

The pain one feels when you only get allocated single /64 is actually the
/64 boundary working *for* you.  If a provider /could/ give you less they
would, and we'd be having discussions about only having a single /120 or
even a single /128.

is detrimental to permissionless expansion at the edge
> of the network

Absolutely not.  IPv6 NAT is where is this ends, and that's so asinine in
such a large space it shouldn't bear mentioning.

Kind regards,

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 2 Jun 2017 17:27:27 +0200

> an RA containing a prefix with plen==65 (currently it does).

Sorry, I have been just shown that the kernel does not complain when it 
receives a plen==65.

Still, the radvd complains when indicating it should send a 65, or a 63.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 2 Jun 2017 16:00:11 +0000

I agree that the /64 boundary is beneficial for many reasons when delegating
an IPv6 prefix to a site. What the site does with the prefix internally (including
sub-delegating into longer prefixes) is entirely up to the site.

Thanks - Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Friday, June 02, 2017 7:34 AM
To: Peter Hessler <[email-masked]>
Cc: IETF IPv6 Mailing List <[email-masked]>
Subject: Re: draft-bourbaki-6man-classless-ipv6-00

  *   The /64 boundary is beneficial for many reasons. See RFC 7421 and RFC 7934.
  *   The document lists no compelling use cases of what you can do with less than 2^64 addresses per link than you can't do with a 2^64 addresses per link.
  *   The only technical motivation in this draft seems to be "classful addressing was a bad idea in IPv4". That's not a valid argument in IPv6 because the address space is completely different. A /64 is *four billion times* bigger than the IPv4 internet. That's 10,000 times more than the difference between a grain of sand and the whole planet we live on. Such a huge scaling difference pretty much invalidates any argument that solutions that worked well in IPv4 will work well in IPv6.
  *   Routing on any prefix length is already required by the standards - see BCP 198.
Please stop trying to make IPv6 be the same as IPv4. That will take away our ability to make the Internet better once IPv4 is gone.

On Fri, Jun 2, 2017 at 11:12 PM, Peter Hessler <[email-masked]<mailto:[email-masked]>> wrote:
Support

On 2017 Jun 02 (Fri) at 16:11:12 +0200 (+0200), Job Snijders wrote:
:Hi Working Group,
:
:Please review the below.
:
:Kind regards,
:
:Job
:
:----- Forwarded message from [email-masked]<mailto:[email-masked]> -----
:
:Date: Mon, 22 May 2017 04:25:28 -0700
:From: [email-masked]<mailto:[email-masked]>
:To: Job Snijders <[email-masked]<mailto:[email-masked]>>, Randy Bush <[email-masked]<mailto:[email-masked]>>, Christopher Morrow <[email-masked]<mailto:[email-masked]>>,
:       Fernando Gont <[email-masked]<mailto:[email-masked]>>, Nick Hilliard <[email-masked]<mailto:[email-masked]>>, Geoff Huston
:       <[email-masked]<mailto:[email-masked]>>, Brian Carpenter <[email-masked]<mailto:[email-masked]>>, Chris Morrow
:       <[email-masked]<mailto:[email-masked]>>
:Subject: New Version Notification for draft-bourbaki-6man-classless-ipv6-00.txt
:
:
:A new version of I-D, draft-bourbaki-6man-classless-ipv6-00.txt
:has been successfully submitted by Randy Bush and posted to the
:IETF repository.
:
:Name:          draft-bourbaki-6man-classless-ipv6
:Revision:      00
:Title:         IPv6 is Classless
:Document date: 2017-05-22
:Group:         Individual Submission
:Pages:         7
:URL:            https://www.ietf.org/internet-drafts/draft-bourbaki-6man-classless-ipv6-00.txt
:Status:         https://datatracker.ietf.org/doc/draft-bourbaki-6man-classless-ipv6/
:Htmlized:       https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-00
:Htmlized:       https://datatracker.ietf.org/doc/html/draft-bourbaki-6man-classless-ipv6-00
:
:
:Abstract:
:   Over the history of IPv6, various classful address models have been
:   proposed, none of which has withstood the test of time.  The last
:   remnant of IPv6 classful addressing is a rigid network interface
:   identifier boundary at /64.  This document removes the fixed position
:   of that boundary for interface addressing.
:
:
:
:
:Please note that it may take a couple of minutes from the time of submission
:until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
:
:The IETF Secretariat
:
:
:----- End forwarded message -----
:
:--------------------------------------------------------------------
:IETF IPv6 working group mailing list
:[email-masked]<mailto:[email-masked]>
:Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
:--------------------------------------------------------------------
--
If Reagan is the answer, it must have been a VERY silly question.

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 3 Jun 2017 01:08:12 +0900

> as Neighbor Cache Exhaustion attacks)."

I said "compelling". Those attacks have relatively simple operational
countermeasures. They were discovered several years ago, and we're coping
just fine.

> Would be a shame to throw away lessons learned from IPv4.

I think that's exactly the fallacy here. It is not useful to apply
something you learned about IPv4 addressing to IPv6, because the number of
addresses is incomparably bigger. Rule of thumb in software engineering is
that a solution usually scales by one or two orders of magnitude. Here we
have something like 34 orders of magnitude. Even a single /64 is 9 orders
of magnitude larger than the IPv4 Internet. It really doesn't make sense to
assign addresses the same way.

> positively impact IPv6 deployment.

But the deployment we get will be dumbed down to the level of functionality
that we can support (and suffer from) in IPv4. It's not worth it.

Example: I don't want us to have to deal with NAT any more, ever. If you
think we can use DHCPv6 without ending up with NAT, then please read
RFC7934 in a loop until you understand why we can't. :-)

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 2 Jun 2017 17:14:55 +0000

> I think that's exactly the fallacy here. It is not useful to apply something
> you learned about IPv4 addressing to IPv6, because the number of addresses
> is incomparably bigger. Rule of thumb in software engineering is that a
> solution usually scales by one or two orders of magnitude. Here we have
> something like 34 orders of magnitude. Even a single /64 is 9 orders of
> magnitude larger than the IPv4 Internet.

Yeah, this hype needs to end. A /64 hard boundary merely doubles the width of IPv4 addresses, and egregiously wastes the majority of the remaining 64 bits.  And with innovations such as IoT, suddenly all that vast extra space can be swallowed up. Back in 1980, IPv4 address space seemed pretty huge too. The deployment assumptions made are key, when people make assertions about the vastness of the address space.

> Example: I don't want us to have to deal with NAT any more, ever.

I've seen this comment made before, and yet the /64 hard boundary practically guarantees that NAT will get used with IPv6. It's exactly the same solution, for exactly the same problem. Inability to expand at the edges.

Bert

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 2 Jun 2017 17:39:56 +0000

Hi Bert,

When you say "IoT", I think about my cellphone and all of its associated devices.
Or, my home router and all of the addressable devices in my home. Giving each
of them a /64 then allowing them to portion their /64s internally as they see fit
(e.g., subnetting to longer prefixes) would not lead to NAT AFAICT. And, the
address space may be used internally for multi-addressing purposes (e.g.,
privacy addresses, random interface identifiers, etc.) which is one of the
advantages of IPv6.

Thanks - Fred

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Manfredi, Albert E
> Sent: Friday, June 02, 2017 10:15 AM
> To: Lorenzo Colitti <[email-masked]>
> Subject: RE: draft-bourbaki-6man-classless-ipv6-00
> 
> Yeah, this hype needs to end. A /64 hard boundary merely doubles the width of IPv4 addresses, and egregiously wastes the majority
> of the remaining 64 bits.  And with innovations such as IoT, suddenly all that vast extra space can be swallowed up. Back in 1980, IPv4
> address space seemed pretty huge too. The deployment assumptions made are key, when people make assertions about the
> vastness of the address space.
> 
> I've seen this comment made before, and yet the /64 hard boundary practically guarantees that NAT will get used with IPv6. It's
> exactly the same solution, for exactly the same problem. Inability to expand at the edges.
> 
> Bert
>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 2 Jun 2017 19:17:14 +0000

-----Original Message-----
From: Templin, Fred L 

> When you say "IoT", I think about my cellphone and all of its
> associated devices. Or, my home router and all of the addressable
> devices in my home. Giving each of them a /64 then allowing them
> to portion their /64s internally as they see fit (e.g., subnetting
> to longer prefixes) would not lead to NAT AFAICT.

True, Fred, but you have posited "giving each of them a /64," presumably by your ISP. I'm saying instead, you create a mobile hotspot with your smartphone, and your smartphone is only provided with a single /64. Now you need to provide routes to each device behind the smartphone, which can be aggregated from the smartphone's /64. Or similarly, any number of IoT devices, each provided with a /64, but each of them needing to create multiple subnets.

No matter what type of privacy or temporary addresses you use, a hard /64 boundary, without a NAT option, will prevent you from be able to aggregate routes. Any expansion at the edges would create a flat address space.

Ultimately, this increasing flat address space will become limiting, IPv6 or not.

Bert

---

From: james woodyatt <[email-masked]>
Date: Fri, 2 Jun 2017 12:17:45 -0700

On Jun 2, 2017, at 10:14, Manfredi, Albert E <[email-masked]> wrote:
> On Jun 2, 2017, at 09:08, Lorenzo Colitti <[email-masked]> wrote:
>> 

I have reluctantly come to believe that service providers MUST have the ability to force their economy class subscribers into artificially small allocations, so they can charge premium prices for larger ones drawn from the same functionally limitless supply at equivalent cost. We have to expect that only business and luxury class subscribers will have sufficiently large allocations that IPv6/NAT will add more costs than it saves them.

I once believed IPv4/NAT was about preserving scarce number resources. I now think that was wrong. It was always about optimizing rents across differing classes of subscribers even when the extracted resource on which the rents are derived is practically unlimited. In this one respect, IPv6 is no different than IPv4. As a purely technical matter, the rent MUST flow.

Accordingly, I say we should stop arguing that IPv6 does not require NAT. For certain classes of subscriber, NAT is essential for making IPv6 service available at an affordable price. Indeed, any internet layer that uses fixed size global scope addresses requires NAT at the provider/subscriber boundary.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 2 Jun 2017 19:30:43 +0000

From: ipv6 [mailto:[email-masked]] On Behalf Of james woodyatt

> I have reluctantly come to believe that service providers MUST have
> the ability to force their economy class subscribers into artificially
> small allocations, so they can charge premium prices for larger ones
> drawn from the same functionally limitless supply at equivalent cost.

Interesting way to put it, somewhat negative, but in essence I agree. Another less negative way to put it is that your cheap subscribers, those only requesting a single /64, can provide low cost service to many, many other devices.

This responds also to Fred's point, of being "given" many /64 addresses from the ISP. It would be far cheaper and far more convenient to *not* have to go to the trouble of requesting dozens or more other /64s, from your ISP.

> I once believed IPv4/NAT was about preserving scarce number resources.
> I now think that was wrong. It was always about optimizing rents across
> differing classes of subscribers even when the extracted resource on
> which the rents are derived is practically unlimited. In this one
> respect, IPv6 is no different than IPv4.

Complete agreement. It's democratization. Users can do their own thing. Just like they do with IPv4 NAT. This need doesn't go away with IPv6, unless we create a police force that guarantees everyone a /48, which would then further put to the lie the idea of this super vast IPv6 address space.

Bert

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 2 Jun 2017 19:35:45 +0000

HI Bert,

> From: Manfredi, Albert E
> Sent: Friday, June 02, 2017 12:17 PM
> To: Templin, Fred L <[email-masked]>
> True, Fred, but you have posited "giving each of them a /64,"

My meaning was for the ISP to give the cell phone or home gateway a /64,
then let the cell phone/ home gateway subnet the /64 to the IoT devices
within the subnetwork it provides as it sees fit. (Where I am using the
term "subnetwork" to refer to mobile hotspots, home networks, etc.)
One /64 goes in the ISP's routing system, but countless billions of
addresses/prefixes could be assigned within the subnetwork. There
is no NAT in that picture.

Thanks - Fred

> presumably by your ISP. I'm saying instead, you create a mobile hotspot
> with your smartphone, and your smartphone is only provided with a single /64. Now you need to provide routes to each device
> behind the smartphone, which can be aggregated from the smartphone's /64. Or similarly, any number of IoT devices, each provided
> with a /64, but each of them needing to create multiple subnets.
> 
> No matter what type of privacy or temporary addresses you use, a hard /64 boundary, without a NAT option, will prevent you from be
> able to aggregate routes. Any expansion at the edges would create a flat address space.
>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 2 Jun 2017 20:01:43 +0000

-----Original Message-----
From: Templin, Fred L 

> My meaning was for the ISP to give the cell phone or home gateway
> a /64, then let the cell phone/ home gateway subnet the /64 to
> the IoT devices within the subnetwork it provides as it sees fit.

Presumably, using some sort of internal address format, also /64, such as privacy addresses? Yes, true, but ...

I'd only make two observations. If the internal address scheme is globally routable, then you can't escape that fact that your ISP is going to have to list potentially many, many routes, reachable through that smartphone's (or home gateway, or internal IoT device gateway) /64. This state of affairs is not desirable.

If the internal address structure is not routable, the obvious example being ULAs, then we're back to requiring a NAT.

So a hard /64 boundary limits expansion at the edges, unless we use a NAT. Without resorting to a NAT, your ISP will have something to say about what you do, it seems to me. And of course, "ISP" is only to put the problem in terms a home user will understand. The same general issue arises with any network.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 2 Jun 2017 20:03:30 +0000

-----Original Message-----
From: Templin, Fred L 

> the IoT devices within the subnetwork it provides as it sees fit.

Sorry, I have to make an important correction:

If the internal address structure is not *globally* routable, the obvious example being ULAs, then we're back to requiring a NAT.

Bert

---

From: Brian Haberman <[email-masked]>
Date: Fri, 2 Jun 2017 16:13:31 -0400

Hi Bert,

> Presumably, using some sort of internal address format, also /64, such as privacy addresses? Yes, true, but ...

I interpreted Fred's proposal as:

1. ISP gives the phone a /64

2. The phone delegates longer prefixes to the devices behind it from the /64

3. The ISP router has a single /64 route that points to the phone

Regards,
Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 2 Jun 2017 20:14:11 +0000

Bert, I think you are either not reading or not understanding what I am writing.
It must be the former, because what I am writing is not complicated.

Another question that we would have to ask is what is the longest prefix that
we should expect an ISP (or a core Internet router, for that matter) to carry
in its routing tables? A /80? A /96?

Thanks - Fred

> Sent: Friday, June 02, 2017 1:04 PM
> I'd only make two observations. If the internal address scheme is globally routable, then you can't escape that fact that your ISP is
> going to have to list potentially many, many routes, reachable through that smartphone's (or home gateway, or internal IoT device
> gateway) /64. This state of affairs is not desirable.
> 
> So a hard /64 boundary limits expansion at the edges, unless we use a NAT. Without resorting to a NAT, your ISP will have something
> to say about what you do, it seems to me. And of course, "ISP" is only to put the problem in terms a home user will understand. The
> same general issue arises with any network.
> 
> Bert

---

From: Job Snijders <[email-masked]>
Date: Fri, 02 Jun 2017 20:19:39 +0000

> in its routing tables? A /80? A /96?

Generally speaking most ISPs accept up to /48 from EBGP peers. Some
exceptions apply, for instance if a valid route6: object exists or the two
parties agreed beforehand to accept longer prefixes.

Perhaps this number changes over time. We'll see.

Kind regards,

Job

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 2 Jun 2017 20:21:08 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian Haberman

> 3. The ISP router has a single /64 route that points to the phone

Ooopps, sorry guys, I reread. Yes, but then we have no argument, right? We're saying exactly the same thing. We are saying that a hard /64 boundary in IPv6 addresses has drawbacks, e.g. expansion at the edges, so it should not become a fixture.

And yes, now one might wonder how long prefixes can become. If ISPs start handing out /128s, we're back to requrirng NATs.

Bert

---

From: Ca By <[email-masked]>
Date: Fri, 2 Jun 2017 13:30:04 -0700

On Fri, Jun 2, 2017 at 12:17 PM, james woodyatt <[email-masked]> wrote:

> I've seen this comment made before, and yet the /64 hard boundary
> practically guarantees that NAT will get used with IPv6. It's exactly the
> same solution, for exactly the same problem. Inability to expand at the
> edges.
>
>
> I have reluctantly come to believe that service providers MUST have the
> ability to force their economy class subscribers into artificially small
> allocations, so they can charge premium prices for larger ones drawn from
> the same functionally limitless supply at equivalent cost. We have to
> expect that only business and luxury class subscribers will have
> sufficiently large allocations that IPv6/NAT will add more costs than it
> saves them.
>
> I once believed IPv4/NAT was about preserving scarce number resources. I
> now think that was wrong. It was always about optimizing rents across
> differing classes of subscribers even when the extracted resource on which
> the rents are derived is practically unlimited. In this one respect, IPv6
> is no different than IPv4. As a purely technical matter, the rent MUST flow.
>
> Accordingly, I say we should stop arguing that IPv6 does not require NAT.
> For certain classes of subscriber, NAT is essential for making IPv6 service
> available at an affordable price. Indeed, any internet layer that uses
> fixed size global scope addresses requires NAT at the provider/subscriber
> boundary.
>
>
James, have you seen this situation in IPv6?  I personally have not seen
scenarios where there is class of service that requires IPv6 NAT or less
than a /64 is given.

I have also not seen in the IPv6 marketplace a scenario where cost is tied
to address space size.

Please share where this scenario is real.

Regards,
CB

>
> --james woodyatt <[email-masked]>
>
>
>
>

---

From: David Farmer <[email-masked]>
Date: Fri, 2 Jun 2017 16:19:41 -0500

Can everyone tone it down a little bit PLEASE!

The actual distance between the positions here is rather small, I believe
we are basically standing nose to nose on different sides of the same line,
which is /64.

I think we all agree that /64 is the normal subnet size in most situations,
in other words the default, especially for subnets with general purpose
hosts, and most notably for subnet with hosts using SLACC. I would like to
see the Draft reinforce that /64 is the norm expected in many situations,
including references to RFC 7421 and RFC 7934. Also, I would like to see
this stated normatively in the draft using RFC 2119 "RECOMMENDED", that is
"/64 is the RECOMMENDED subnet size."

Furthermore, no one disputes that there are exceptions to /64. There are at
least two formal exceptions already, RFC 6164 and addresses that begin with
binary 000. Where we seem to diverge is the number and nature of the
exceptions that should be allowed to /64. One side seems to want only
formally recognized and approved exceptions, where as the draft is arguing
that there is much operational deployment of any number of subnet sizes
like 127, 126, 124, 120, ... beyond the current formally approved
exceptions.

The actual difference between MUST with stated exceptions and RECOMMENDED
is kind of nuanced anyway.

So here is an anecdote of the operational issues here;  In the last month I
established a Direct Internet Access (DIA) connection with the large Cable
Co. in our region to get their IP based video service for our on-campus
residential students and for various offices around the University, with
the added benefit of providing more direct access to campus resources for
commuter students, staff, and facility when at home.  The Cable Co provided
the addressing for the link to do BGP over; They provided a /30 for IPv4,
our internal practice these days is to use a /31, but there is really
nothing wrong with a /30. Since they provided a /30 for IPv4 they quite
logically provided a /126 for IPv6, and use the same last digits between
the IPv4 and IPv6 addresses, again our practice is to use a /127. However,
in totality this seems quite operationally reasonable and logical, but it
violates the IPv6 specifications, should I have told them we can't do
that?  No, in this case I believe its the specification that is wrong, not
the Cable Co's operational practice.

So, should we rewrite RFC6164 to also formally allow the use of a /126 as
well?  Or, should we simply recognize that /64 is a RECOMMENDATION (and
/127 for that matter is too), and let operators use other prefix lengths
that seem appropriate to the situation?

Thanks.

On Fri, Jun 2, 2017 at 9:33 AM, Lorenzo Colitti <[email-masked]> wrote:

>> :URL:            https://www.ietf.org/internet-
>> drafts/draft-bourbaki-6man-classless-ipv6-00.txt

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

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 2 Jun 2017 21:34:40 +0000

From: ipv6 [mailto:[email-masked]] On Behalf Of David Farmer

> The actual distance between the positions here is rather small, I
> believe we are basically standing nose to nose on different sides
> of the same line, which is /64.

Well .... sort of.

> I think we all agree that /64 is the normal subnet size in most
> situations, in other words the default, especially for subnets with
> general purpose hosts,

Except that the consequences of all that e-mail (my response to Lorenzo, echoed by Fred), would be that even a SLAAC, without a hard /64 boundary, would be very nice. A subject for another day.

Home gateways assigned a /64, smartphone-provided mobile hotspots, I'm not sure such examples can be forever relegated to the category of corner cases?

Bert

---

From: David Farmer <[email-masked]>
Date: Fri, 2 Jun 2017 17:10:35 -0500

On Fri, Jun 2, 2017 at 4:34 PM, Manfredi, Albert E <
[email-masked]> wrote:

> Except that the consequences of all that e-mail (my response to Lorenzo,
> echoed by Fred), would be that even a SLAAC, without a hard /64 boundary,
> would be very nice. A subject for another day.
>
> Home gateways assigned a /64, smartphone-provided mobile hotspots, I'm not
> sure such examples can be forever relegated to the category of corner cases?
>

Personally, I'd support doing that too.  But, that is a real change to a
bunch of code, and while I seed the need for doing it, it needs to be done
very carefully.  More importantly, I wouldn't want doing that to get in the
way of the more philosophical change(correction) proposed in this draft.

Thanks.

-- 
===============================================
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: Mark Smith <[email-masked]>
Date: Sat, 3 Jun 2017 09:39:15 +1000

> I think that's exactly the fallacy here. It is not useful to apply
something
> magnitude larger than the IPv4 Internet.

Yeah, this hype needs to end. A /64 hard boundary merely doubles the width
of IPv4 addresses, and egregiously wastes the majority of the remaining 64
bits.  And with innovations such as IoT, suddenly all that vast extra space
can be swallowed up. Back in 1980, IPv4 address space seemed pretty huge
too. The deployment assumptions made are key, when people make assertions
about the vastness of the address space.

I've seen this comment made before, and yet the /64 hard boundary
practically guarantees that NAT will get used with IPv6.

How does that guarantee it? Classless IPv4 didn't prevent NAT being
deployed.

In my experience, cost of public address space, the size of the private
address space and it being free, the perception that NAT didn't cause any
issues and the perceived level of security isolation private addressing
provided were the reasons NAT continued to be deployed after classless IPv4
commonly became available.

Regards,
Mark.

It's

exactly the same solution, for exactly the same problem. Inability to
expand at the edges.

Bert

---

From: Mark Andrews <[email-masked]>
Date: Sat, 03 Jun 2017 10:35:52 +1000

In message <[email-masked]>, Brian Hab
> 1. ISP gives the phone a /64

The ISP could give each phone a /48.  There is NOTHING stopping the
ISP giving a /48 today.  IPv6 is sized to allow this.  When you
stop trying to hand out the minimum and start handing out reasonable
quantities of subnets the so called problems go away.

> 2. The phone delegates longer prefixes to the devices behind it

The phone then hands out /64's to devices behind it on demand.

> 3. The ISP router has a single /64 route that points to the phone

The ISP's router has a single /48 that points to the phone.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Sat, 3 Jun 2017 04:40:27 +0300

Hi, Mark,

> The phone then hands out /64's to devices behind it on demand.

And such devices, if they feel like sharing, hand a...?

> The ISP's router has a single /48 that points to the phone.

At which point we probably should start thinking about ipng-bis :-).
That's 16-bits away from IPv4, which has (or used to) /32 pointing to hosts.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Mark Andrews <[email-masked]>
Date: Sat, 03 Jun 2017 13:03:14 +1000

In message <[email-masked]>, Fernando Gon
> And such devices, if they feel like sharing, hand a...?

/64's on demand using PD.  This isn't rocket science.  ISP's handout
/48's.  Internally you handout /64's on demand and route each of
them individually.  DHCP-PD is designed to allow you to do this.

A /48 allow you to hand out 65000 /64's.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 3 Jun 2017 13:21:37 +0900

This should read: "The phone enables bridging. All the devices behind it
share the /64."

This works today. Stop trying to solve a problem we don't have?

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 3 Jun 2017 13:29:36 +0900

On Jun 3, 2017 04:17, "james woodyatt" <[email-masked]> wrote:

That doesn't actually work. When all the applications have built NAT
traversal mechanisms, anything more than one IP address per location
becomes worth nothing. At that point the extra rent is gone, and everybody
loses because the system is less capable, less robust, and harder to
configure than it would have been without NAT.

And in fact, that's what happens in IPv4 today. Putting an entire corporate
campus with tens of thousands of users behind one public IPv4 address is
standard practice.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 3 Jun 2017 13:34:59 +0900

On Jun 3, 2017 04:31, "Manfredi, Albert E" <[email-masked]>
wrote:

Complete agreement. It's democratization. Users can do their own thing.

Actually they can't. NAT doesn't extend the network, it just provides a
crippled, stripped-down version of it.

guarantees everyone a /48, which would then further put to the lie the idea
of this super vast IPv6 address space.

You seem not to know that there is in fact plenty of space to do that. See
the calculations in RFC 3177.

---

From: Tom Herbert <[email-masked]>
Date: Fri, 2 Jun 2017 21:51:08 -0700

> This should read: "The phone enables bridging. All the devices behind it

Which allows the phone to bridge 2^64 devices! I don't understand why
my phone needs a /64. This is an impediment to being about to use
Identifier Locator Address (ILA) meaningfully in carrier networks.

Tom

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 3 Jun 2017 14:17:03 +0900

On Jun 3, 2017 13:51, "Tom Herbert" <[email-masked]> wrote:

my phone needs a /64.

The answers are in RFC 7934 and RFC7421.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 3 Jun 2017 14:51:22 +0900

ILA provides mobility by forcing mobile entities to be numbered within 64
bits instead of 128.

That makes sense in a datacenter where the numbers of locators is limited
and multiple identifiers often share a given locator, but it's extremely
inefficient in a network where everything is point-to-point like today's
subscriber and mobile networks.

When everything is point-to-point, identifiers can never share a locator
and ILA effectively reduces the size of the address space from 128 bits to
64, reducing the number of addressable devices by 2e19. That's a
spectacularly bad deal compared to the alternative, which is a few bytes of
encap overhead.

---

From: Matthew Petach <[email-masked]>
Date: Sat, 3 Jun 2017 02:40:04 -0700

I support this draft.

Matt

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 3 Jun 2017 12:15:35 +0200

Le 03/06/2017 à 02:35, Mark Andrews a écrit :
>
> In message <[email-masked]>,
> Brian Hab erman writes:
>> Hi Bert,
>>
>>> -----Original Message----- From: Templin, Fred L
>>>
>>>> My meaning was for the ISP to give the cell phone or home
>>>> gateway a /64, then let the cell phone/ home gateway subnet the
>>>> /64 to the IoT devices within the subnetwork it provides as it
>>>> sees fit.
>>>
>>> Presumably, using some sort of internal address format, also /64,
>>> such
>> as privacy addresses? Yes, true, but ...
>>
> The ISP could give each phone a /48.

Ask an operator, he'd say /56 instead of /48, if at all.  And it would 
be a non-operational specific purpose trial.

Ask another operator, he'd say '64share' everywhere, despite IETF saying 
it's INFORMATIONAL.

Ask an end-user, he'd say operators are difficult, better do NAT.

Alex

> There is NOTHING stopping the ISP giving a /48 today.  IPv6 is sized
> to allow this.  When you stop trying to hand out the minimum and
> start handing out reasonable quantities of subnets the so called
> problems go away.
>
>> Regards, Brian

---

From: Simon Hobson <[email-masked]>
Date: Sat, 3 Jun 2017 11:15:45 +0100

Lorenzo Colitti <[email-masked]> wrote:

> When all the applications have built NAT traversal mechanisms, anything more than one IP address per location becomes worth nothing. At that point the extra rent is gone, and everybody loses because the system is less capable, less robust, and harder to configure than it would have been without NAT.
> 
> And in fact, that's what happens in IPv4 today.

Agreed - but that is typically out of necessity as there just aren't the IP addresses to go round.

Having had the luxury of managing a network with a whole /24 to play with, and looked at the underlying problems making SIP phones work through NAT, I fully agree that NAT is to be avoided due to the amount of brokenness* it creates. Trying to persuade those who see things "just work" (because of all the wasted effort put in to make things work - would have been much better spent getting IPv6 adopted sooner) is a different matter.

BUT, I cannot see the logic behind your earlier comment that DHCP makes NAT inevitable for IPv6.

* PS - I have a special place in hell for the ******** ******** at Zyxel who think that randomising port translations on every connection, and "no you can't turn that off, we don't care if it breaks things, it adds security" (yes, that's the response I got from them !) is a good idea.

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 3 Jun 2017 12:17:20 +0200

> And such devices, if they feel like sharing, hand a...?

'64share' is INFORMATIONAL, should not be used on a large scale.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 3 Jun 2017 12:21:51 +0200

Le 03/06/2017 à 06:21, Lorenzo Colitti a écrit :
> On Jun 3, 2017 10:42, "Fernando Gont" <[email-masked]
> <mailto:[email-masked]>> wrote:
>

'64share' does not scale, and is INFORMATIONAL.

Solutions?

Alex

---

From: Tom Herbert <[email-masked]>
Date: Sat, 3 Jun 2017 07:39:16 -0700

> ILA provides mobility by forcing mobile entities to be numbered within 64
I would point out that RFC7421 includes ILNP as a motivation for a
/64, but this argument is not a valid rationale for assigning /64 to
mobile devices. Mobile devices need to be assigned identifiers not
locators.

> subscriber and mobile networks.
I disagree. In a datacenter we have VMs that are mobile entities and
locators that are physical hosts. In a mobile network its the devices
themselves that are the mobile entities and the point of attachment,
e.g. base stations, that are the locators. The two cases are
isomorphic. So in order for identifier/locator split to work it should
be the base stations that have a /64 and the mobile devices that would
be an identifier. The impediment here is giving each low end device a
/64. If they were given a /96 or a /104 we could do a productive
identifier/locator split for mobility.

> When everything is point-to-point, identifiers can never share a locator and
> ILA effectively reduces the size of the address space from 128 bits to 64,
> reducing the number of addressable devices by 2e19. That's a spectacularly
> bad deal compared to the alternative, which is a few bytes of encap
> overhead.

How much of the /64 space that is being assigned to end devices is
being used? Unless it's more than some 0.00000...% that seems like the
spectacularly bad deal to me and the thing that is reducing that
Internet address space down to sixty-four bits. Forcing this
assignment precludes us from taking advantage of the incredibly large
address space with techniques like identifier/locator split. The only
recourse that we have is to use encapsulation which means another
forty bytes of header, another header to process, and makes this
solution no
different than what we can do in IPv4. The irony of the last point is
not lost, /64 is forcing us to implement mobility just like we'd do in
IPV4.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Sat, 3 Jun 2017 08:04:22 -0700

> Job
Job,

Thanks for the draft. I think the case will be bolstered with some
real examples as to how fixed /64 interface addressing has proven to
be problematic. Using identifier/locator split in addresses as I
mentioned is one example. I suspect there are more that could be
documented.

Tom

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 03 Jun 2017 16:47:34 +0100

> mentioned is one example. I suspect there are more that could be

Tom,

let's say your device is assigned a /64, e.g. either on a mobile network
or via PD.  Your device sits between upstream and downstream devices and
passes traffic between upstream and downstream.

Forcing /64 means that your device is limited to bridging mode, because
downstream devices would not be permitted to assign a netmask of longer
than /64.  This could seriously adversely impact on network connectivity
options for downstream devices.  E.g. multiple networks sitting on some
homenet.

Would this fall into the category of examples that you're talking about
here?

Nick

---

From: Tom Herbert <[email-masked]>
Date: Sat, 3 Jun 2017 08:49:58 -0700

> The answers are in RFC 7934 and RFC7421.

Lorenzo,

RFC7934 presents the arguments why hosts need multiple addresses, not
why hosts need 2^64 addresses. For RFC7421 the arguments seem to be
around operational simplicity. These don't answer my specific
question: Why does a low end device, like a phone, _need_ the
equivalent of four billion IPv4 address spaces assigned to it? What is
a specific application that a phone runs that justifies giving the
device such an enormous space? I don't believe it can be ILA, ILNP,
NAT, or renumbering-- these are justifications for given datacenter
servers /64s.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Sat, 3 Jun 2017 09:03:30 -0700

> Would this fall into the category of examples that you're talking about
I think this is too much a generalization trying to make it a "one
size fits all" problem. I'm not going to use my phone as a router into
my enterprise network, I don't see any reason to have it delegate some
complex network hierarchy. We need the ability to tether a small
number of devices, anything more than we are talking about a different
type of device.

Tom

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 03 Jun 2017 18:04:04 +0100

Tom Herbert wrote:
> complex network hierarchy. 

we're talking about any network structure of any form rather than a
complex network hierarchy.  The problem as it stands is that there are
situations where the fixed /64 rules out entire categories of options.
One of these, as you point out, would be complex hierarchies.  Another
would be the entire category of small networks that are being discussed
in the homenet wg.

> We need the ability to tether a small

The number of devices isn't the issue here; it's whether the protocol
can facilitate a single downstream network or more than one.  Right now,
we're limited to one in the usual case where the device is assigned a /64.

Nick

---

From: Tom Herbert <[email-masked]>
Date: Sat, 3 Jun 2017 10:14:23 -0700

On Jun 3, 2017 1:04 PM, "Nick Hilliard" <[email-masked]> wrote:

I would agree with that. I think that these categories of options that are
being disallowed should be described to support the draft.

Tom

Nick

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 3 Jun 2017 19:32:47 +0200

On Fri, Jun 2, 2017 at 4:11 PM, Job Snijders <[email-masked]> wrote:
<snip>
>    of that boundary for interface addressing.

what I find odd is that we over and over again are morphing IPv6 into IPv4
with just more IP adresses... can't we just rename it to IPv4+ and be
done with it?

Things like this ONLY hurt IPv6, yet again IETF can't agree on IPv6 so why
should we bother using it? But I guess the none technical side are a lost
case for most IETF'ers. Not to mention that we remove one of the thing
so many I've spoken to over the years think is great - the standard LAN
size. No more discussion on that.

either way, not support from me but doesn't really matter when all the
rest think it's a great idea. Think I'll use my time outside to fix the garden
rather than fighting this losing IPv6 cause.

-- 

Roger Jorgensen
[email-masked] / [email-masked]

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 3 Jun 2017 19:34:13 +0200

On Fri, Jun 2, 2017 at 4:33 PM, Lorenzo Colitti <[email-masked]> wrote:
<snip>

> Please stop trying to make IPv6 be the same as IPv4. That will take away our
> ability to make the Internet better once IPv4 is gone.

oh totaly agree, but it's already lost, the "operators" don't want to
move/change.

-- 

Roger Jorgensen

---

From: [email-masked]
Date: Sat, 03 Jun 2017 19:34:28 +0200 (CEST)

> Please review the below.

Support.

Steinar Haug, AS2116

---

From: Simon Hobson <[email-masked]>
Date: Sat, 3 Jun 2017 19:13:34 +0100

Tom Herbert <[email-masked]> wrote:

> I'm not going to use my phone as a router into

OK, what about a situation where something that looks like a phone to the network, but happens to not have much by way of telephony bits built into it, is being used ? It really doesn't change the discussion that the box is black, has no display, and is called a router - it's still doing exactly the same thing as a phone doing tethering for downstream devices.
And at work, we have customers doing just that - connecting an entire network (OK, not complex network) to the internet either as a temporary measure until their proper connection gets installed, or in some cases as a permanent measure as it's not worth getting a fibre circuit installed for a temporary site (where temporary is typically in the order of 2-4 years for a civil engineering project).

Roger Jørgensen <[email-masked]> wrote:

> But I guess the none technical side are a lost case for most IETF'ers.

In reality the world is run by non-technical people - often derogatorily referred to as bean counters. While not applicable here, I firmly believe that one of the reasons for the slow adoption of IPv6 is it's perceived complexity (and hence cost) on the part of the bean counters who ultimately must sign off on any project in a business.

> Not to mention that we remove one of the thing so many I've spoken to over the years think is great - the standard LAN size.

I'm inclined to agree there.
At first I had to admit that I just couldn't bring myself to think positively about what seems to be profligate wastage of address space - having "cut my teeth" with IPv4 addressing. Now I'm getting my head around it though it's taking some effort to adjust in many ways.
As a thought, will there be discussions at some point in the future when it turns out that some vendors have decided that nothing other than a /64 exists and so their kit doesn't support (say) a /56 ?

---

From: Tom Herbert <[email-masked]>
Date: Sat, 3 Jun 2017 11:41:15 -0700

On Jun 3, 2017 2:16 PM, "Simon Hobson" <[email-masked]> wrote:

> number of devices, anything more than we are talking about a different

OK, what about a situation where something that looks like a phone to the
network, but happens to not have much by way of telephony bits built into
it, is being used ? It really doesn't change the discussion that the box is
black, has no display, and is called a router - it's still doing exactly
the same thing as a phone doing tethering for downstream devices.

But that does change the discussion significantly. Those are different
devices, not smart phone I'm using to type this message. This does not need
a /64 assignment, I will never use it for any more than tethering a few
devices. What I do need is seamless mobility for my applications which is a
problem IPv6 should be able to help solve.

And at work, we have customers doing just that - connecting an entire
network (OK, not complex network) to the internet either as a temporary
measure until their proper connection gets installed, or in some cases as a
permanent measure as it's not worth getting a fibre circuit installed for a
temporary site (where temporary is typically in the order of 2-4 years for
a civil engineering project).

That's anecdotal. For every case like that, how many user devices are out
there that don't even turn tethering ever and are only using one address,
much less need 2**64 of them?

Thanks,
Tom

> But I guess the none technical side are a lost case for most IETF'ers.

In reality the world is run by non-technical people - often derogatorily
referred to as bean counters. While not applicable here, I firmly believe
that one of the reasons for the slow adoption of IPv6 is it's perceived
complexity (and hence cost) on the part of the bean counters who ultimately
must sign off on any project in a business.

> Not to mention that we remove one of the thing so many I've spoken to
over the years think is great - the standard LAN size.

I'm inclined to agree there.
At first I had to admit that I just couldn't bring myself to think
positively about what seems to be profligate wastage of address space -
having "cut my teeth" with IPv4 addressing. Now I'm getting my head around
it though it's taking some effort to adjust in many ways.
As a thought, will there be discussions at some point in the future when it
turns out that some vendors have decided that nothing other than a /64
exists and so their kit doesn't support (say) a /56 ?

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 4 Jun 2017 08:50:52 +1200

On 04/06/2017 06:41, Tom Herbert wrote:
...
> much less need 2**64 of them?

So that's an argument about delegating prefixes vs assigning addresses.
I don't see how it affects the question of whether the routing architecture
includes a magic barrier at /64. What the draft says is that there is no magic
barrier in the routing system. It isn't even news.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 4 Jun 2017 09:12:54 +1200

On 04/06/2017 05:32, Roger Jørgensen wrote:
> with just more IP adresses... 

That simply isn't true. The draft doesn't abolish the concept of 'interface
identifier', which doesn't exist in IPv4. It doesn't attack SLAAC. It
doesn't attack ILNP or draft-herbert-nvo3-ila. It doesn't attack the choice
of /64 for all IPv6-over-foos to date.

It does say two things.

1. BCP198
2. n in the addressing architecture is a parameter.

     Brian

---

From: David Farmer <[email-masked]>
Date: Sat, 3 Jun 2017 16:55:19 -0500

> size. No more discussion on that.

Personally, I'm fine with a standard LAN subnet size, but that's not what
RFC4291 says, it says /64 is magic and all subnets are /64 regardless.
However, not every network in the world is a LAN. Just because we use
ethernet framing everywhere doesn't make every network a LAN either. We
have added /127 with RFC6164 for point-to-point, but if you use a /30 for
IPv4 point-to-points, then a /126 makes more sense for your IPv6
point-to-points.

Anyway, changing to "/64 is the RECOMMENDED subnet size" is still provides
a standardized LAN size. It just recognizes that not everything is a LAN.

More generally, I understand the desire to break with the old conventions
from IPv4, and eventually we have to. However, right now we are in a
transition state where we have to support both IPv4 and IPv6, and to much
divergence in the operational models between IPv4 and IPv6 just creates
issues.  Yes this costs money and the bean counters don't like that, but
even more importantly it reduces reliability and lowers the quality of the
user experience.  This is what you call a lose-lose situation.

And talk about hurting IPv6, if deploying it reduces reliability and and
lowers the quality of the user experience for a network, that's what will
hurt IPv6.

Finally, saying all LANs are /64 only works if providers had out prefixes
to customers that are larger than /64. In my experience that's not
happening, if you know how to fix that please speak up!  Otherwise, we
better figure out have to split a /64 across multiple local subnets,
because its very difficult for lay people to understand why 18
quintillion addresses isn't enough for their house, no matter how many
networks they have in their house.

Thanks.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 4 Jun 2017 00:04:59 +0000

From: ipv6 [mailto:[email-masked]] On Behalf Of Fernando Gont

> That's 16-bits away from IPv4, which has (or used to) /32 pointing

Exactly.

Assuming the IETF can even cause ISPs to hand out /48s, which it cannot, the other side of that coin is that now the address space increase becomes rather ho-hum. An extra 16 bits, effectively, is only an increase of 4 1/2 orders of magnitude. Which, considering how far we have already gotten beyond un-NATed IPv4, and considering the number of addition gizmos are to connect to the Internet in the not so distant future, is just nothing to write home about.

Bert

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 4 Jun 2017 10:21:00 +0900

> BUT, I cannot see the logic behind your earlier comment that DHCP makes

The answers are in RFC 7934,

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 4 Jun 2017 10:28:37 +0900

On Sun, Jun 4, 2017 at 12:49 AM, Tom Herbert <[email-masked]> wrote:

> equivalent of four billion IPv4 address spaces assigned to it?

Read the document again? The goal is not /64. The goal is that no general
purpose host should ever be constrained in the number of IPv6 addresses
that it gets. That means it should be able to form new addresses without
asking the network, or it should get enough from the network that it never
needs to asks again. Currently the only ways to do that are SLAAC, which
operates on 64-bit prefix lengths, or DHCPv6 PD of a /64 or shorter, which
allows other devices behind the host to run SLAAC.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 4 Jun 2017 10:33:55 +0900

On Sun, Jun 4, 2017 at 2:34 AM, Roger Jørgensen <[email-masked]> wrote:

> our

But they *are* changing. For example: almost 20% of Google users these days
come in over IPv6. Pretty much all of them are connected to networks that
support SLAAC and use /64 prefixes. That's a huge number now matter how you
look at it, and it's showing no signs of slowing down.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 4 Jun 2017 10:35:24 +0900

> passes traffic between upstream and downstream.

No, Tom wants to assign a device a /96 or a /104. He wants the network to
use the middle bits for mobility.

---

From: Mark Smith <[email-masked]>
Date: Sun, 4 Jun 2017 14:00:03 +1000

> look at it, and it's showing no signs of slowing down.

I think the mistake people are making is that they're viewing lack of
enterprise IPv6 adoption to indicate a lack of any IPv6 adoption. It's
an easy mistake to make, I often do it myself.

IPv6 isn't solving business problems that most enterprises have, which
that is why it isn't being adopted by them. That's ok, technologies
aren't adopted by businesses for technologies sake.

It is solving the business problem that residential service providers
have, which is why they're adopting it so quickly. Specifically, the
problem it is solving for them is it is minimising the amount of
Carrier Grade NAT capacity they'd have to buy.

Some other enterprises are using it, I know it is being used in
Advanced Metering Infrastructure (i.e. electricity smart meter
networks).

Even when an enterprise encounters an IPv6 only website that they need
to access, their solution will be to put in an IPv4/IPv6 proxy on the
edge of their network, as that is consistent with their private
internal addressing / middlebox/security box on the edge of the
network model.

Regards,
Mark.

---

From: Tom Herbert <[email-masked]>
Date: Sat, 3 Jun 2017 21:51:41 -0700

Lorenzo,

That's correct. Consider use case for mobility would be a for a device
that is a front end to a network, for example a bus driving down the
road has offers WIFI to passengers. To use identifier/locator split
addressing (ILA or ILNP) for mobility in this case we need

M bits for locator of physical device in mobile network
N bits for identifier of physical device
128 - M - N bits for delegated addresses by the physical device

I don't see a workable solution if device is assigned a /64. Am I
missing something?

Tom

---

From: Simon Hobson <[email-masked]>
Date: Sat, 3 Jun 2017 19:13:34 +0100

---

From: Simon Hobson <[email-masked]>
Date: Sun, 4 Jun 2017 09:27:48 +0100

> The answers are in RFC 7934, 

I think you'll need to point them out then

Lorenzo Colitti <[email-masked]> wrote:

> That means it should be able to form new addresses without asking the network, or it should get enough from the network that it never needs to asks again.

Ah, now I see where you are coming from - and I don't agree with you.

I don't want to come across as being adversarial here, but one thing I have noticed from your various posts is that you appear to have a quite entrenched "SLAAC solves the problems I work with, there shouldn't be any other solutions even if others have different problems/priorities" approach to things.

So for example, here you are adamant that a device should not have to "ask the network" for more addresses. What about networks where there are other priorities, what if the operator of a network requires to track addresses/address usage for whatever reasons ?

The answer to that cannot be "then the network operator is wrong". I can assure you that there are networks around where devices just turning up and assigning their own addresses is not allowed, and never will be allowed (all I'll say is that the military have a different view of the privacy/security tradeoff). In some cases, there is a LEGAL REQUIREMENT to track devices in this manner - such as public WiFi operators. I assume you'll consider that bad and not to be supported, but in the real world that is the case whether we like it or not.
There may be other ways around it involving routers tracking the MAC-address mappings and so on, but this seems quite a lot more work than having a centralised management system that deals with admitting new devices onto the network, assigning addresses to them, and monitoring their activity.

---

From: Roger Jørgensen <[email-masked]>
Date: Sun, 4 Jun 2017 10:55:59 +0200

> look at it, and it's showing no signs of slowing down.

look into the numbers, I assume there are one huge group missing there,
the enterprises and that's where the money, and damage will be done.

If/when this draft goes through I am pretty sure I in 10-15years time will come
across something like this :

My device provided by the enterprise will have a /122 and when asking why
the security department will say something along the line because there are X
devices allowed on that segment and we provide them all. And since X match
with /122 we just configure them static on each device.
If I am lucky enough that it's global address space, but most likely it will
be ULA with NAT, because NAT provide security......

No real security, just shortsighted missguided assumptions on howto
provide "security."

this draft don't consider the none-technical side where the real damage
is coming. None will bother to look into why they should use a /64,
they will just hear "oh, IPv6 is classless so we can use whatever we
want", and they will go down that road.

-- 

Roger Jorgensen

---

From: Job Snijders <[email-masked]>
Date: Sun, 4 Jun 2017 11:31:19 +0200

On Sun, Jun 04, 2017 at 10:55:59AM +0200, Roger Jørgensen wrote:
> >> > Please stop trying to make IPv6 be the same as IPv4. That will
> >> > take away our ability to make the Internet better once IPv4 is
> >> > gone.
> >>
> > But they *are* changing. For example: almost 20% of Google users
> > these days come in over IPv6. Pretty much all of them are connected
> > to networks that support SLAAC and use /64 prefixes. That's a huge
> > number now matter how you look at it, and it's showing no signs of
> > slowing down.
> 
> look into the numbers, I assume there are one huge group missing
> there, the enterprises and that's where the money, and damage will be
> done.

You talk about "damage", I think what you meant to say is "finally, the
enterprise will deploy IPv6 too".

> If/when this draft goes through I am pretty sure I in 10-15years time
> will come across something like this :

Would you be so kind to also point out which stock options we should
invest in and what horses to bet on?

Kind regards,

Job

---

From: Roger Jørgensen <[email-masked]>
Date: Sun, 4 Jun 2017 11:37:53 +0200

> enterprise will deploy IPv6 too".

no, the questions is, is it really worth it?

> invest in and what horses to bet on?

that's low

-- 

Roger Jorgensen

---

From: Job Snijders <[email-masked]>
Date: Sun, 4 Jun 2017 11:38:19 +0200

On Sun, Jun 04, 2017 at 09:27:48AM +0100, Simon Hobson wrote:
> > On Sat, Jun 3, 2017 at 7:15 PM, Simon Hobson
> > <[email-masked]> wrote: BUT, I cannot see the logic behind
> > your earlier comment that DHCP makes NAT inevitable for IPv6.
> > 
> > That means it should be able to form new addresses without asking
> > the network, or it should get enough from the network that it never
> > needs to asks again.
> 
> I don't want to come across as being adversarial here, but one thing I
> have noticed from your various posts is that you appear to have a
> quite entrenched "SLAAC solves the problems I work with, there
> shouldn't be any other solutions even if others have different
> problems/priorities" approach to things.
> 
> So for example, here you are adamant that a device should not have to
> "ask the network" for more addresses. What about networks where there
> are other priorities, what if the operator of a network requires to
> track addresses/address usage for whatever reasons ?
> 
> The answer to that cannot be "then the network operator is wrong". I
> can assure you that there are networks around where devices just
> turning up and assigning their own addresses is not allowed, and never
> will be allowed (all I'll say is that the military have a different
> view of the privacy/security tradeoff). In some cases, there is a
> LEGAL REQUIREMENT to track devices in this manner - such as public
> WiFi operators. I assume you'll consider that bad and not to be
> supported, but in the real world that is the case whether we like it
> or not.  There may be other ways around it involving routers tracking
> the MAC-address mappings and so on, but this seems quite a lot more
> work than having a centralised management system that deals with
> admitting new devices onto the network, assigning addresses to them,
> and monitoring their activity.

This is a really good summary.

Even in my home environment I sometimes need absolute control on what
source address is used by what device to connect to the outside world.

Many online services perform poorly thought out geo-fencing, and through
steering of source addresses (by using NAT, or by handing out specific
addresses to specific devices) I can increase the chances that the
legitimate user can access their legitimate content.

Of course, some zeolots will say "well, those online services are doing
it wrong and must fix their service offering". sure.... i'll ask them to
get right on that! ;-)

Kind regards,

Job

---

From: Philip Homburg <[email-masked]>
Date: Sun, 04 Jun 2017 13:05:48 +0200

>enterprise will deploy IPv6 too".

The way I see it, at a fundamental technical level, this draft is wrong.

Now if this draft were to say that in the case of address assignment using
DHCPv6 IA_NA or when using static addresses, hosts should support any
prefix length, then I would be perfectly okay with that.

In general we can assume that operators know how to run a network and it
is perfectly possible to run a network on just DHCP or static.

With this in mind, if enterprises want to make their lives easier, they
should tell vendors that refuse to support DHCPv6, that in a couple of
your their devices will not work anymore on enterprise networks. Support
DHCPv6 or be gone.

However, that is not what the draft actually says. The draft tries play games
with SLAAC, and that is a bad idea.

Traditionally, SLAAC used modified EUI-64 interface identifiers, which are
of course exactly 64 bits. So that implies a hard 64-bit boundary.

In recent years there has been a change to pseudo random interface identifiers.
Because the boundary was effectively at 64 bits, none of those RFCs
contains a specification of what the minimum amount of randomness has to
be to avoid problems.

Leaving that to the network operator without any kind of constraint or
guidance is just a recipe for disaster. So without an RFC that properly
sets a lower limit for pseudo random IIDs, this draft is a bad idea.

Moving on to a network architecture point of view, when using pseudo random
IIDs there will be a longest prefix that can be supported. Lets say for the
sake of argument we can support of /96.

Then the effect will be that if in the future hosts support SLAAC upto /96
then we are back at the same hard limit. We have just moved be boundary by
32 bits.

At the moment we don't have an address shortage. Any kind of address shortage
at the moment is due to a combination of political and commercial issues
(with a hint of political issues masking as technical issues thrown in).

There is no reason to expect this to change if we make longer prefixes possible.
It is just that end users will then end up with a /96 and find that they
can't subdivide it any further.

So, to make a full circle, if you want to deploy long prefixes, limit yourself
to DHCPv6 and static. If you find that hosts routinely have problems with
long prefixes in combination with DHCPv6 or static then write a draft about
that.

Do not try to move the boundary for SLAAC. That may give a short term gain,
in the long run that just locks ourselves in a small corner.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 4 Jun 2017 20:55:30 +0900

> I don't see a workable solution if device is assigned a /64. Am I

There is no workable solution if you want to assign 64 bits to the bus, 64
bits to the routing system, and M bits for mobility, unless M = 0.

---

From: Peter Hessler <[email-masked]>
Date: Sun, 4 Jun 2017 14:48:29 +0200

On 2017 Jun 04 (Sun) at 20:55:30 +0900 (+0900), Lorenzo Colitti wrote:
:On Sun, Jun 4, 2017 at 1:51 PM, Tom Herbert <[email-masked]> wrote:
:
:> M bits for locator of physical device in mobile network
:> N bits for identifier of physical device
:> 128 - M - N bits for delegated addresses by the physical device
:>
:> I don't see a workable solution if device is assigned a /64. Am I
:> missing something?
:>
:
:There is no workable solution if you want to assign 64 bits to the bus, 64
:bits to the routing system, and M bits for mobility, unless M = 0.

That's *exactly* why bus and routing MUST NOT require a specific size.

-- 
What is a magician but a practising theorist?
		-- Obi-Wan Kenobi

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 4 Jun 2017 22:02:20 +0900

On Sun, Jun 4, 2017 at 5:27 PM, Simon Hobson <[email-masked]> wrote:

> So for example, here you are adamant that a device should not have to "ask
> the network" for more addresses. What about networks where there are other
> priorities, what if the operator of a network requires to track
> addresses/address usage for whatever reasons ?
>

Again, the answers are in RFC 7934. See section 9.1 which goes into some
detail on address tracking. But basically: tracking via DHCP is insecure
unless you have L2 security, and if you have L2 security, you may as well
use that to track addresses.

---

From: Ca By <[email-masked]>
Date: Sun, 04 Jun 2017 13:07:56 +0000

> That's *exactly* why bus and routing MUST NOT require a specific size.

I would say this level of mobility or "nomadacity" has proven through the
years to NOT work at the network level in the INTERNET.

Just like ipsec has has failed where TLS has succeed, same for Mobile IP,
PMIP, and so on. The narror waist of the internet does not include
mobility, especially at a level that is transparent to the user.

Just like always on dynamic ipsec for security, fine grain mobility was not
destine to be included in the routing system.  Best to let go of this
usecase rather than tilting more at the windmill.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 4 Jun 2017 22:10:09 +0900

> then we are back at the same hard limit. We have just moved be boundary by

That's *exactly* right.

> can't subdivide it any further.

Right. So then someone will say, "we need to extend the network at the
edges!". And we move the boundary again, to /112. And then to 120, and then
to /124, until we get to one /128 per device. But long before that, a)
SLAAC is dead because there's not enough space in the prefix to form a
random IID, b) the hosts start doing NAT because they don't want to waste
their time. We now have 128-bit IPv4. Except that at least in IPv4, address
shortage was real. In IPv6 it isn't.

Or, if we remove the boundaries altogether, we end up with /128 straight
away, because operational consistency. We now have 128-but IPv4 again.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 4 Jun 2017 22:11:59 +0900

> That's *exactly* why bus and routing MUST NOT require a specific size.

If you don't require a specific size "operational consistency with IPv4"
will inevitably lead to one /128 per device and NAT. As a host developer I
don't want to implement NAT, because it's bad for my users.

---

From: Peter Hessler <[email-masked]>
Date: Sun, 4 Jun 2017 15:16:19 +0200

On 2017 Jun 02 (Fri) at 20:14:11 +0000 (+0000), Templin, Fred L wrote:
:Another question that we would have to ask is what is the longest prefix that
:we should expect an ISP (or a core Internet router, for that matter) to carry
:in its routing tables? A /80? A /96?

OpenBGPD is intended for use on the default-free-zone, and has a default
configuration that allows /16 - /48 for IPv6 prefixes.  In looking at RIR
policies, and recommendations from vendors and operational documents, /48
looks to be the longest prefix length that you can consider reliably
routable beyond your own AS.

*Inside* an AS however, I see no reason to artificially limit the prefix
size.  Operators should aggregrate where it makes sense
(region/metro/building/cage/row/rack/etc), but that is good design
regardless of the size or even IP version.

-- 
First Law of Socio-Genetics:
	Celibacy is not hereditary.

---

From: Peter Hessler <[email-masked]>
Date: Sun, 4 Jun 2017 15:22:00 +0200

On 2017 Jun 04 (Sun) at 22:11:59 +0900 (+0900), Lorenzo Colitti wrote:
:On Sun, Jun 4, 2017 at 9:48 PM, Peter Hessler <[email-masked]> wrote:
:
:> :There is no workable solution if you want to assign 64 bits to the bus, 64
:> :bits to the routing system, and M bits for mobility, unless M = 0.
:>
:> That's *exactly* why bus and routing MUST NOT require a specific size.
:>
:
:If you don't require a specific size "operational consistency with IPv4"
:will inevitably lead to one /128 per device and NAT. As a host developer I
:don't want to implement NAT, because it's bad for my users.

One address per device *is a good thing*.  From the OS perspective,
having to select which ******** address to use as the source IP is
horrible.

NAT means two things:

1) You can't depend on directly accessing the device.  This is true with
Firewalls, so you have to consider that anyways.

2) You can't embed the IP address inside the packet data.  That's a
stupid idea, and shouldn't be done.

Besides, *Lots of people are already deplyoing IPv6 NAT in the wild*.

-- 
You will feel hungry again in another hour.

---

From: Tom Herbert <[email-masked]>
Date: Sun, 4 Jun 2017 06:56:33 -0700

> having to select which ******** address to use as the source IP is
It wouldn't be particularly difficult to implement random address
selection in an OS, but I imagine that might confuse some applications
that assume there is only one address in the system. However, for the
purposes of address obfuscation I don't see why a host would need 2^64
addresses, a few billion addresses should suffice.

> Besides, *Lots of people are already deplyoing IPv6 NAT in the wild*.
NAT is bad because it requires networks nodes to maintain and track
connection state (like stateful firewalls which also need to go
away!). It only supports certain protocols and extension headers, it
has motivated the use of NAT keepalives in UDP which are nothing but
junk packets, and for connections all packets must go through the same
network device which becomes a bottleneck and prevents multi-homing.

Tom

---

From: Ca By <[email-masked]>
Date: Sun, 04 Jun 2017 14:00:55 +0000

> away, because operational consistency. We now have 128-but IPv4 again.

Assuming the above path is true ....

A 64 bit random iid is a very real security advantage.  i will point out
that things like the recent "wannacry" worm (like many worms before it)
relied on dense guessable host ip addressing scheme that make address
scanning effective.

Making small guessable prefixes increases discoverability and decreases
security. Please update the security section to include this massive
regression in security  posture for ipv6 that favors known and commonly
used network scanning malware techniques of ipv4 will now be used in ipv6.

---

From: Tom Herbert <[email-masked]>
Date: Sun, 4 Jun 2017 07:13:21 -0700

> years to NOT work at the network level in the INTERNET.
That is not what we are proposing (in ILA at least). This is not
intended to work over the Internet. Mobility would be implemented
within a carrier network, external to that network it is transparent.
Logically, this provides the same functionality as encapsulation does
with the benefit of not incurring the overhead of encapsulation.

Tom

> PMIP, and so on. The narror waist of the internet does not include mobility,
> especially at a level that is transparent to the user.
>

---

From: [email-masked]
Date: Sun, 04 Jun 2017 16:20:14 +0200 (CEST)

> use that to track addresses.

Tracking via DHCP is good enough in many cases, and already implemented
in lots of support systems. L2 tracking has an extra cost. Guess which
will be used?

Steinar Haug, AS2116

---

From: Philip Homburg <[email-masked]>
Date: Sun, 04 Jun 2017 16:26:24 +0200

>with the benefit of not incurring the overhead of encapsulation.

The current IPv6 address architecture is basically a relatively densely
allocated /64 prefix plus an extremely sparse 64-bit IID.

With DHCPv6 you can today have dense IIDs that allow space for experiments.

However, without a clear consensus that embedding identifiers in IPv6
addresses is good idea, it strikes me as bad to use that as an argument
to change how SLAAC works.

At least for me, messing up the IPv6 address architecure just to save the
overhead of encapsulation is not worth it.

---

From: Tom Herbert <[email-masked]>
Date: Sun, 4 Jun 2017 07:44:14 -0700

> overhead of encapsulation is not worth it.
Maybe it will be proven to be be worth it, maybe not. And this
probably true of other interesting things we could do with the large
IPv6 address space. But, I think imposing an artificial architectural
constraint that prevents us from even *trying* an alternative like
this is unfortunate. For all the talk that this draft forces IPv6 to
be like IPv4 I think it's the exact opposite at least in the this
case: /64 is preventing us from doing something different and
potentially innovative in IPv6 compared to IPv4.

Tom

---

From: David Farmer <[email-masked]>
Date: Sun, 4 Jun 2017 14:49:55 -0500

On Sun, Jun 4, 2017 at 9:20 AM, <[email-masked]> wrote:

> "ask

On this point I have to agree with Lorenzo, tracking MAC addresses with
DHCP without the addition of L2 security to enforce it is pointless. What
about static assignment of addresses, without L2 security there would be no
way to prevent it.

We scrape Neighbor Discovery tables out of routers just like we do for ARP
tables in IPv4. It is independent of how the addresses are assigned, it
works with static assignment, DHCP, SLACC, and what ever else comes along.
The whole point of address tracking is accountability, having
accountability only for the people that follow a rule, what ever it is, is
kind of pointless, you need to track the rule breakers too.  Therefore you
need a tracking solution that is independent of address assignment.

Since we can track any address used, in most parts of our network we allow
SLACC for IPv6 address assignment, because it's the easiest to use in most
cases. That said I still think DHCP is a perfectly valid mechanism for
address assignment as well.

Thanks.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 5 Jun 2017 11:05:54 +1200

On 05/06/2017 02:00, Ca By wrote:
> used network scanning malware techniques of ipv4 will now be used in ipv6
Yes. Any IPv6-over-foo that proposes a boundary at, say, /96 would have to
explain why 32 bits of pseudorandomness is enough. And we could perfectly
well have a guaranteed security DISCUSS on boundaries beyond some
magic number. Maybe that number would even be /64, but I think /80 is
more likely. None of that is the point. The point is to establish
that routing is classless and /64 is a parameter of specific
addressing schemes.

Probably the draft is too long, which obscures that simple message.

     Brian

---

From: Mark Smith <[email-masked]>
Date: Mon, 5 Jun 2017 10:45:04 +1000

Adding new features to try to encourage adoption or making it resemble
IPv4 as much as possible still won't make a difference to adoption by
businesses if it isn't the best way to solve a business problem.

<snip>

> enterprise will deploy IPv6 too".

In enterprises, the only "marketing" IPv6 needs is that it solves a
business problem, either better than IPv4 does or that cannot be
solved by IPv4. It doesn't need new features purely to try to
encourage adoption or to better resemble IPv4 to encourage adoption.

There are enterprises where IPv6 is the better way to solve a business
problem than IPv4 - service providers and utilities using smart
meters.

A great way to remember this view on technology - when you go to the
hardware store to buy a drill, what you're really buying is a hole.

<snip>

Regards,
Mark.

---

From: Erik Kline <[email-masked]>
Date: Mon, 5 Jun 2017 16:17:51 +0900

> Besides, *Lots of people are already deplyoing IPv6 NAT in the wild*.

Citations?

Of course you can deploy a network that does whatever you want.  That alone
does not imply standards action is required.

---

From: Peter Hessler <[email-masked]>
Date: Mon, 5 Jun 2017 09:23:43 +0200

On 2017 Jun 05 (Mon) at 16:17:51 +0900 (+0900), Erik Kline wrote:
:Of course you can deploy a network that does whatever you want.  That alone
:does not imply standards action is required.

This draft is requesting that the standards reflect reality, and
acknolwedge that non-/64 subnets are legal.  This group has tried to
force the standards to require only /64 subnets and that is, quite
frankly, offensive.

-- 
Grabel's Law:
	2 is not equal to 3 -- not even for large values of 2.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 5 Jun 2017 16:45:48 +0900

On Mon, Jun 5, 2017 at 8:05 AM, Brian E Carpenter <
[email-masked]> wrote:

> None of that is the point. The point is to establish
> that routing is classless

Routing is already classless because BCP 198.

> and /64 is a parameter of specific addressing schemes.
>

It *is* a parameter. The parameter's value is 64 for all unicast addresses
except those starting with 000.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 5 Jun 2017 16:54:01 +0900

On Mon, Jun 5, 2017 at 4:23 PM, Peter Hessler <[email-masked]> wrote:

> This draft is requesting that the standards reflect reality,

I don't think longer-than-64 IIDs are an appreciable portion of reality.
The number of IPv6 prefixes in use every day is well into the hundreds of
millions. The number of non-/64 IIDs is likely a rounding error in
comparison.

> and acknolwedge that non-/64 subnets are legal.

What is legal is what is written in the standards, and it's /64. What is
implemented may vary. Lots of devices allow configuration of longer prefix
lengths. Lots of devices don't.

> This group has tried to force the standards to require only /64 subnets
> and that is, quite frankly, offensive.
>

I think that's incorrect. "Has tried" is incorrect because /64 has been the
current state of the standards for about 20 years. "This group" is
incorrect because a lot of the people who made those decisions are no
longer in this group. They have just been replaced by other people who
happen to agree that that decision was a good one.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 5 Jun 2017 11:53:51 +0200

Le 04/06/2017 à 13:05, Philip Homburg a écrit :
[...]
> Moving on to a network architecture point of view, when using pseudo
>  random IIDs there will be a longest prefix that can be supported.
> Lets say for the sake of argument we can support of /96.
>
> Then the effect will be that if in the future hosts support SLAAC
> upto /96 then we are back at the same hard limit. We have just moved
>  be boundary by 32 bits.

Similar worries were expressed.

However, as I read this draft it does not propose to substitute new hard 
limit for old hard limit.  The proposal is leave it at 'n', i.e. a variable.

The optimistic evolution of this could be that in some IP-over-foo this 
variable could be exceptionally /96 and largely over-ridden by a 
backward compatible /64.

Maybe something could be written down that clarifies this is not a
proposal to substitute new hard limit for old hard limit.

Alex

---

From: Tim Chown <[email-masked]>
Date: Mon, 5 Jun 2017 15:33:57 +0000

Hi,

> On 3 Jun 2017, at 22:12, Brian E Carpenter <[email-masked]> wrote:
> 

And it that sense, it’s fine, i.e. /64 is RECOMMENDED, and used for the various IPv6-over-foos that Brian mentioned, but also it sends a message to not hardcode /64.

The draft could cite RFC7421 and (for the point about address availability) RFC7934. 

Like David, at the university where we deployed IPv6, we didn’t try to lock down addresses to hosts; rather we used SNMP-based polling of network devices for accountability. We also had 802.1X (through eduroam) on WiFi, and I know of some universities deploying 802.1X for wired networks as well. There’s also the Cisco ND syslogging capability if you use their platform. 

Tim

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 5 Jun 2017 18:07:20 +0200

Le 05/06/2017 à 09:45, Lorenzo Colitti a écrit :
> On Mon, Jun 5, 2017 at 8:05 AM, Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> It *is* a parameter. The parameter's value is 64 for all unicast
> addresses except those starting with 000.

But 001-prefixed addresses are forbidded.

Alex

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 5 Jun 2017 19:42:48 +0200

sorry for the language in this email, and it's not direct at you
Brian, it's toward us all.

On Mon, Jun 5, 2017 at 1:05 AM, Brian E Carpenter
<[email-masked]> wrote:
<snip>
> ......... The point is to establish
<snip>

If we here in this group forget that most people that will use IPv6
don't care at all
about anything in any RFC, they actual don't really care that there are a RFC
system - what they care about is that their daily life is easy. This
_I_ think is very
true for the enterprise world. They go for quick and dirty, and
cheapest solution.

So, for most of them they will only hear and see "IPv6 is classless",
and with their
IPv4 background they _will_ start todo all kind of crazy stuff, all
the things WE
seems to think we can handle by putting in extra words in a RFC.
Really - if we are stupid, yes that's the word, that we think any
words we put into
an RFC will prevent NAT66, /128 and /120 and all the crazy things people do in
IPv4 and now will be doing in IPv6, then well ... let's just rename
IPv6 into IPv4+
and be done with it.

So sure we will get more IPv6 deployment, but NOT the kind that actual
will solve
application layer problem created by NAT & alike, and we are not any
better of at
all. Not to forget that we very likely are to trigger a routing/policy
change because
there are no hard /64 anymore......

This one universal /64 is what almost every none-technical, and most technical
I've ever meet understand about IPv6. Some think it's a waste of space but it's
accepted and they work with it.

With that said - sure I agree with Brian on that one sentence.

I actual also agree with the intent of the draft, no hardcoded /64's anywhere
(from my lenghty discussion with Job online over the last few days), it should
be DEFAULT /64, but changable.
I just can't accept the followups that "classless & IPv6" will create since most
people would never read the finer details of what that actual mean and
we will have IPv4+, not IPv6.
But if most people are fine with the draft and don't belive it will cause the
havoc I think it will, then count me in the rough, I'm fine with that.

Also, I think I remember that most hardware are optimized around that
/64 boundary, how will this affect newer chipset and hardware? Should they
optimize their hardware to route anything from /8 to /128? Sounds very
expensive and not something that will make IPv6 more popular.

-- 

Roger Jorgensen

---

From: David Farmer <[email-masked]>
Date: Mon, 5 Jun 2017 15:05:27 -0500

> expensive and not something that will make IPv6 more popular.

I'm fine with systems being optimized for /64, they just can't ignore or
assume there will never be anything longer than /64. If they assume there
will never be any prefixes longer than /64, that's not optimizing for /64,
that's building a broken system. Optimizing for /64 is assuming something
like approximately 60-75% of prefixes will be /64 or shorter, maybe even
80-90% for that matter, but the latter is probably a little over optimized
in my opinion.

To one extent that's already covered in BCP198/RFC7608, this draft is more
about the IID length, but they are really just opposite sides of the same
coin.

Thanks.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 6 Jun 2017 10:25:20 +1200

> except those starting with 000.

The parameter's *current* value, yes. But should we really be fixing
the value of the parameter once and for all in the addressing architecture?
Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design
assumes?

   Brian

    Brian

---

From: 神明達哉 <[email-masked]>
Date: Mon, 5 Jun 2017 15:48:53 -0700

At Tue, 6 Jun 2017 10:25:20 +1200,

> Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design

Is this what this draft tries to propose?  Then the number will be
still 64 in most links used today anyway according to RFC2464.  My
initial impression of the draft is that it even tries to remove that
number for IPv6-over-Ethernet, or even make it independent from
IPv6-over-foo but subject to operator's choice.

If the proposal is really to make the length of the interface
identifier only dependent on IPv6-over-foo (but not on the addressing
architecture spec anymore), I think the draft should explicitly state
so.  I'd still expect a lot of discussion on that proposal, but it
will at least help avoid having some of the controversy we're seeing
in this very long thread.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 6 Jun 2017 13:22:58 +1200

> proposal to substitute new hard limit for old hard limit.

Alexandre,

I think that is what the draft says. Most of the discussion here has not
been about what the draft says, but about what operators who don't read
RFCs anyway might or might not do because they don't understand that IPv6
isn't IPv4+. That's an interesting discussion, but I wish people would
give it a relevant subject like "IPv6 isn't IPv4+".

  Brian

---

From: Erik Kline <[email-masked]>
Date: Tue, 6 Jun 2017 13:26:14 +0900

> Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design

Because I doubt there is any good argument about things specific to the Foo
layer for having something shorter than a 64 when 64 gets you many so nice
guarantees for randomness, security and non-collision.

This document does not include a problem statement -- it doesn't say what
problem exists that need solving.

If all this is about being able to execute the OS-specific equivalent of
"ifconfig eth0 add 2001:db8::1/123" then I think that should absolutely
work fine.  We should file bugs to get OS tools to understand what this
actually means.

That, however, is completely orthogonal to 64bit IIDs.  The 64bit boundary
pretty much only has meaning in a SLAAC context.  Not doing SLAAC?  64bit
IIDs don't really affect to you then.  If OS's make assumptions that there
must be some 2001:db8::/64 route when in fact 2001:db8::1/123 was specified
then that's an obvious error.  IMHO, if /n isn't specified: use n=64 and if
/n is specified then use /n.  Seems simple enough.  You can put a /123 PIO
in an RA so why not on a command line.

This document however burns down the whole house for the sake of lighting a
candle that was in fact already lit.

The only thing meaningfully affected by removing 64bit IIDs is removal of
the last backstop that ensures network operators and users alike share --
however unequally -- the benefits of IPv6 and it permanently demotes IPv6
to little more than 128bit IPv4 with quaint, warty rules about fragments
and extension headers.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Jun 2017 16:48:00 +0900

> Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design

If that is the authors' goal, then what the draft should say is that the
IID length is 64 unless otherwise specified by an IPv6-over-foo layer.

That is not what the draft says today.

I also suspect it's not the authors' goal. At least Randy and Job have
clearly stated that what they want to do is run non-/64 prefixes on today's
links (Ethernet, maybe wifi), not on some future link layer.

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 6 Jun 2017 09:53:47 +0200

On Tue, Jun 6, 2017 at 9:48 AM, Lorenzo Colitti <[email-masked]> wrote:
<snip>

> links (Ethernet, maybe wifi), not on some future link layer.

why shouldn't they? If it's manual configured it should work, ref the
last few emails, default 64 unless manual configured.
.... but yes the draft is horrible written/title if this is what the goal is.

And is it really needed in a new draft if we could get it into one of
the -bis documents...... ?

-- 

Roger Jorgensen

---

From: 神明達哉 <[email-masked]>
Date: Tue, 6 Jun 2017 12:06:07 -0700

At Fri, 2 Jun 2017 16:11:12 +0200,

> Please review the below.

I've read draft-bourbaki-6man-classless-ipv6-00.

First, I have some high level comments:

- it's not clear to me exactly what this draft tries to propose.
  Brian (a coauthor) seems to indicate it just makes the length of
  interface identifiers dependent only on IPv6-over-foo specifications
  (and not on the addressing architecture spec).  But, as I commented
  earlier the draft text reads to me as if it proposes more: the
  length of IID is now completely variable and subject to operator's
  choice (whether we have a "default length" or whether such a default
  is 64 is a different topic).  When the intent of the draft is so
  unclear, and perhaps the intent even among coauthors is not
  consistent, it's nearly impossible to even understand the draft
  accurately, let alone say support or non-support.

- somewhat related to the first bullet, this draft seems to be
  confused about the point I tried to clarify in my own individual
  draft, draft-jinmei-6man-prefix-clarify-00, even if it's referenced
  from this draft: The draft (perhaps unintentionally) conflates
  "on-link prefixes" and "(SLAAC) subnet prefixes".  Depending on
  which kind of prefix it talks about, the draft could actually update
  an existing standard or be a mere clarification.  For example, in
  Section 1 it states:

   [...]  While link prefixes
   of varied lengths, e.g.  /127, /126, /124, /120, ...  /64 have been
   successfully deployed for many years, glaring mismatches between a
   formal specification and long-standing field deployment practices are
   never wise, [...]

  This "link prefixes" is more likely to refer to on-link prefixes.
  But in that sense there's no "mismatch" between the specification
  and the deployment: on-link prefix length has already, and always
  been variable (but I know it's confusing, and that's one main reason
  why I wrote my own draft).  (As a minor note, I realize the concept
  of on-link prefixes used in my draft exclusively focuses on prefixes
  in RA PIOs.  But it's straightforward to extend the concept to
  manual configuration, and I believe even those who prefer keeping
  the /64 magic number for certain SLAAC subnet prefixes agree that
  on-link prefix length is already variable and it also applies to
  manual configuration).

  On the other hand, the 2nd and 3rd paragraphs of Section 4 clearly
  mean SLAAC subnet prefixes (by talking about interface identifiers).
  As I tried to explain in my draft, these two are independent.  It's
  very confusing to see an introduction to topics about on-link
  prefixes and then recommendations about SLAAC subnet prefixes.

So, I'd first like to request this draft be much more clearer on what
it proposes.  And, if it helps in doing so, be clearer on the
difference between on-link and SLAAC subnet prefixes.  If the proposal
is only about one of them, just don't talk about the other, since
discussing both would just increase confusion and introduce
unnecessary controversy; if the proposal covers both types of
prefixes, make sure which type of prefixes is intended in each
specific context.

And so it may be premature to talk about specific content of the
draft, but I'll provide some comments on the current version of text
anyway.

- Section 1: the discussion in this section is confusing, misleading,
  and/or irrelevant.  See the high-level comment above.

- Section 2

   [...]  Therefore their length, previously fixed
   at 64 bits [RFC7136], [...]

  I don't think RFC7136 fixes "their (= interface IDs') length".  At
  the very least fixing it doesn't seem to be the main goal of the
  RFC.  If it intends to refer to a particular part of the RFC that
  I'm missing, it's better to include a specific section number.

- Section 2

   [...]  Therefore their length, [...],
   is in fact a variably-sized parameter as
   explicitly acknowledged in Section 5.5.3(d) of [RFC4862]

  This sentence itself is true, but I suspect it's misleading in the
  context (i.e., stating this after referring to RFC7217/8064).  What
  RFC4862 acknowledges is that the length of IID is a parameter of the
  link, but RFC7217 is actually a technique quite independent from
  specific link type.  If this paragraph tries to say that now that we
  have the technique of RFC7217 and recommendation of RFC8064, IID
  length won't have to be a parameter of link type (and therefore not
  necessarily be 64 for Ethernet, for example), then I see it's worth
  discussing.  But that's a new update to existing standards, not what
  RFC4862 is currently acknowledging.

- Section 3

   IPv6 unicast interfaces may use any subnet length up to 128 except
   for situations where an Internet Standard document may impose a
   particular length, for example Stateless Address Autoconfiguration
   (SLAAC) [RFC4862], [...].

  RFC4862 does not (directly) impose a particular IID length.  It just
  says the length is a parameter of the link type.  If anything, what
  imposes a particular length is specific IPv6-over-foo specs, such as
  RFC2464.

- Section 4

   For historical reasons, when a prefix is needed on a link, barring
   other considerations, a /64 is recommended [RFC7136].

  This "prefix" is ambiguous.  Please clarify whether it's an on-link
  prefix or SLAAC subnet prefix.

  Also, I don't think RFC7136 makes such a recommendation.  At least
  such a recommendation is not the main topic of the RFC (see another
  bullet on Section 2 above).

  And, perhaps related to the second point, it's not clear to me
  whether this sentence tries to introduce a new recommendation or
  just intends to refer to an existing recommendation in other RFC(s).

- Section 4

   Nonetheless, there is no reason in theory why an IPv6 node should not
   operate with different interface identfier lengths on different
   physical interfaces.  Thus, a correct implementation of SLAAC must in
   fact allow for any prefix length, with the value being a parameter
   per interface.

  This reads to me like an update to RFC4862.  In RFC4862, the length
  of IID (which derives SLAAC subnet prefix length) is a parameter of
  link type, not of an individual interface.  If this text intends to
  make an update to RFC4862, that's find as a proposal, but it should
  more explicitly say so.  Also it should add RFC4862 to the "Update:"
  field of the draft header.

- Section 5

  This section is another place where this draft conflates on-link and
  SLAAC subnet prefixes: The first paragraph is mainly related to SLAAC
  subnet prefixes, while the second paragraph is about on-link
  prefixes.  It's misleading to discuss these this way using the same
  "subnet" term, or one of them can be totally irrelevant depending on
  the actual intent of this draft's proposal (see the high level
  comment above).  I actually see there's a subtle relationship
  between these two topics, however, since both prefixes are often the
  same in practice.  But, if the draft really needs to talk about the
  subtlety it should do so more carefully (if one of the issues is
  irrelevant it's much simpler and less confusing to just omit it).

--
JINMEI, Tatuya

---

From: james woodyatt <[email-masked]>
Date: Tue, 6 Jun 2017 12:22:05 -0700

On Jun 6, 2017, at 12:06, 神明達哉 <[email-masked]> wrote:
> 
> ...be clearer on the difference between on-link and SLAAC subnet prefixes. ...

I’m with Mr. Jinmei on this point. I really can’t make any sense of this draft because of how badly it conflates these two different concepts. I may find what the draft really proposes to do completely harmless. I may not. I can’t tell at this point.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jun 2017 08:27:45 +1200

Jinmei-san,

Thanks for those careful comments. Can I just ask one question to be
sure I understand:

> The draft (perhaps unintentionally) conflates
>   "on-link prefixes" and "(SLAAC) subnet prefixes".

Am I correct in thinking that this distinction *only*
applies when SLAAC is in use? If the nodes on a link
(including a point-to-point) are configured without use
of SLAAC, surely there is only a "prefix", without
distinction.

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jun 2017 08:38:40 +1200

Erik,

> The only thing meaningfully affected by removing 64bit IIDs...

But that is exactly what the draft does *not* do. Nobody would
change a single instruction in existing code as a result of this
draft. (I agree with you that some O/S stacks may need fixing, but
they already need fixing.)

Regards
   Brian

---

From: [email-masked]
Date: Tue, 6 Jun 2017 23:03:33 +0200

> they already need fixing.)

is this draft exactly:

   IPv6 unicast routing is based on prefixes of any valid length up to
   128 [BCP198].  Interface Identifiers should be 64 bit long except
   when the addresses are manually configured, or by exceptions defined
   in standards track documents.  For example, [RFC6164] standardises
   127 bit prefixes on inter-router point-to-point links.  The rationale
   for using 64 bit Interface Identifiers can be found in [RFC7421]

?

Ole

---

From: 神明達哉 <[email-masked]>
Date: Tue, 6 Jun 2017 14:49:46 -0700

At Wed, 7 Jun 2017 08:27:45 +1200,
Brian E Carpenter <[email-masked]> wrote:

> applies when SLAAC is in use?

This is indeed a subtle point and I intentionally didn't go into it in
my comments to avoid introducing further confusion (so I'm glad you
asked it separately).  As it's subtle I'm not sure if I can explain it
well, but let me try...(and therefore it can't be a simple answer like
"yes, you're right" or "no, it's not correct").

First, an "on-link prefix" is only about on-link determination in the
Neighbor Discovery protocol.  It's independent from SLAAC or any other
way to configure addresses.  In that sense, the separation between
on-link prefix and (SLAAC) subnet prefix always applies, whether or
not SLAAC is in use.  So the answer to the above question would be
"no, you're not correct".

Secondly, "SLAAC subnet prefix" is by definition only meaningful when
SLAAC is in use.  In that sense, "this distinction only applies when
SLAAC is in use" obviously.  But in this context we should actually
extend it and only consider "subnet prefix".  Purely from the
addressing architecture point of view, a subnet prefix could be
defined as the leading bits of an IPv6 address immediately followed by
the interface identifier.  This definition has no conflict with the
definition of "SLAAC subnet prefix" as introduced in
draft-jinmei-6man-prefix-clarify-00 (where it's defined as a prefix
advertised in an RA PIO with A flag on, and its only use is for SLAAC,
and in SLAAC this prefix is immediately followed by the interface
identifier).

With this extended definition, the question is whether "on-link
prefix" is distinct from "subnet prefix" only when SLAAC is in use.
Admittedly I don't think an existing standard document answers this
question.  But IMO the answer is still "no".  That's simply because
the concept of "on-link" prefix is independent from how an address is
configured at all, as explained two paragraphs above.

And then:

> If the nodes on a link

(again in my understanding/opinion), no, an on-link prefix is still
different from a subnet prefix in this case (they can happen to be the
same, but don't have to be so).

Now, another related subtle point is that if we accept this
separation, the "subnet prefix" for an address configured without
SLAAC is almost meaningless except in the formal definition of the
addressing architecture: a host uses an on-link prefix for on-link
determination, and uses the full 128 bits to identify L3 end points.
It doesn't matter for the host which part of the address is the subnet
prefix and which part is the interface identifier.  To this end, your
original question:

> applies when SLAAC is in use?

could also be answered with "yes" since in this case only the "on-link
prefix" matters in practice.

Does this answer your question?

--
JINMEI, Tatuya

---

From: David Farmer <[email-masked]>
Date: Tue, 6 Jun 2017 17:18:20 -0500

>    for using 64 bit Interface Identifiers can be found in [RFC7421]
I'd be cool with that! +1

---

From: james woodyatt <[email-masked]>
Date: Tue, 6 Jun 2017 16:06:40 -0700

On Jun 6, 2017, at 14:49, 神明達哉 <[email-masked]> wrote:
> question. […]

I would say that IPv6 Subnet Model [RFC5942] <https://tools.ietf.org/html/rfc5942> clearly answers this question.

The answer is no: they are always distinct. See §1 Introduction, where it says, "The behavior of IPv6 as specified in Neighbor Discovery (ND) [RFC4861] is quite different. The on-link determination is separate from the address assignment," and further refinement in §4 Host Rules, p1. where it says this: "The assignment of an IPv6 address -- whether through IPv6 stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315], or manual configuration -- MUST NOT implicitly cause a prefix derived from that address to be treated as on-link and added to the Prefix List."

> […] But IMO the answer is still "no".  That's simply because the concept of "on-link" prefix is independent from how an address is configured at all, as explained two paragraphs above.

I think it’s not just a matter of opinion. I think the standards track documents are clear on this point.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jun 2017 11:24:14 +1200

> IID length is 64 unless otherwise specified by an IPv6-over-foo layer.

As Ole quoted, it says:

"Interface Identifiers should be 64 bit long except
when the addresses are manually configured, or by exceptions defined
in standards track documents."

Maybe there are too many other words?

> That is not what the draft says today.

The difference is the "manually configured" option. I don't see
how we can forbid that.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jun 2017 11:27:54 +1200

>    for using 64 bit Interface Identifiers can be found in [RFC7421]

Yes. Put those words in 4291bis and I will be very happy. Oh ;-).

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jun 2017 11:30:23 +1200

Just to be clear...
>> IID length is 64 unless otherwise specified by an IPv6-over-foo layer.

I meant that it says this in a too complicated way,
not in those exact words.

---

From: Job Snijders <[email-masked]>
Date: Tue, 06 Jun 2017 23:30:30 +0000

> Yes. Put those words in 4291bis and I will be very happy. Oh ;-).

I recall a small but vocal group arguing fiercely against that text
adjustment, so here we are.

Kind regards,

Job

---

From: 神明達哉 <[email-masked]>
Date: Tue, 6 Jun 2017 18:14:21 -0700

At Tue, 06 Jun 2017 23:30:30 +0000,

> adjustment, so here we are.

As several people including myself have already pointed out, it's very
hard for ordinary readers to understand that's really what
draft-bourbaki-6man-classless-ipv6-00 tries to propose.  It will have
to be heavily revised to convey that message.

As for the above text, my recollection is that some people (I don't
know if that was a small group, btw - to me both groups looked equally
vocal and equally small/large) were against one specific point in
text like the above one:

- "should be 64" instead of "must be 64" (but in my understanding they
  were/are okay with "except when the addresses are manually
  configured")

It's also not clear to me whether the real intent of
draft-bourbaki-6man-classless-ipv6-00 includes the subtle (but
seemingly very important for those who were "fiercely against" it)
change from "must" to "should".  I guess if the authors of
6man-classless-ipv6 are actually also happy/okay with this one:

    128 [BCP198].  Interface Identifiers must be 64 bit long except

then there will be no dispute or further time wasting (we'll still
need to decide what to do with the magic leading bits of 000 in terms
of the interface identifier length, but if we can agree at this level
this will be a relatively minor point to address).

--
JINMEI, Tatuya

---

From: "t.petch" <[email-masked]>
Date: Wed, 7 Jun 2017 13:02:20 +0100

----- Original Message -----
From: <[email-masked]>
To: "Job Snijders" <[email-masked]>
Cc: "Erik Kline" <[email-masked]>; "6man WG" <[email-masked]>
Sent: Wednesday, June 07, 2017 2:14 AM
> to be heavily revised to convey that message.

I agree.

I think that the message is much obscured, perhaps as a counter to the
recent history of vigorous discussion.

And it all starts with the title which ... well, I would say is rubbish
IMHO.

Tom Petch

---

From: David Farmer <[email-masked]>
Date: Wed, 7 Jun 2017 10:13:51 -0500

> this will be a relatively minor point to address).

I think "should be 64" is the correct language, primarily because "must be
64" has been misinterpreted several times to justify hard coding 64 in IPv6
implementations, but also it seems like a false imperative.  Now that an
explicit manual configuration exception is included, I could live with
"must be 64", only if the language is further clarified as an operational
directive and not an implementation directive to hard code 64 along with
the list of exceptions.

So I'd prefer; "Interface Identifiers should be 64 bits long except..."
However, I could live with; "Operationally, Interface Identifiers must be
64 bits long except..."

I think either of these makes it clear 64 bit is the norm, but this should
not enforced by an IPv6 implementations or hard coded in some way.

Unless someone has language to clarify the purpose for the magic leading
bits of 000, I'd prefer to just level that execution out, in my experience
it only confuses the discussion.

Thanks

---

From: Philip Homburg <[email-masked]>
Date: Wed, 07 Jun 2017 17:26:39 +0200

>64 bits long except..."

I don't know if we have to rewrite too many RFC to do the following...

The concept of an IID is only relevant to SLAAC. That's the only place where
a locally generated or configured IID is combined with either a well known
prefix (link local) or a prefix received in an RA.

In the case of SLAAC, IPv6-over-foo documents specify the number of bits of
the IID for that particular link type.

For anything else, manual configuration, DHCPv6 IA_NA we need to get rid of
any implied prefix length when dealing with addresses. An address is just that,
a single address, a /128 if you have to use prefix notation.

Everything is else is in the domain of routing and is irrelevant to assigning
addresses to interfaces.

Ideally, we should try to get software vendors to stop combining addresses
with on-link prefixes in user interfaces, but that may be an uphill battle.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 7 Jun 2017 10:35:14 -0700

At Wed, 7 Jun 2017 10:13:51 -0500,

> However, I could live with; "Operationally, Interface Identifiers must be

Personally I don't care about should vs must here.  I just thought
this "must" was critical for the so-called "small but vocal" group,
and, if others can accept it with "except..." then it might be a way
forward.  In that sense, I don't see the point of tweaking it further
by such as adding "operationally".  As you said, with the "except"
it's already pretty clear that we cannot simply hardcode the magic
number.  If we are still worried about the blind hardcoding we can
just say implementations must not unconditionally hardcode a particular
value for all cases.

Anyway, my humble suggestion to the wg at this point is to hold off
until the next version of the draft is submitted.  Several people have
already pointed out the current version is so confusing, and, as a
result everyone seems to interpret it in their favorite way (or
overreact to it due to the confusion).  Most of the discussions since
the submission of 00 seem to be largely irrelevant and just time
wasting.  It looks like the authors also acknowledge the need for a
substantial revise, so it's more productive to wait for it and have a
more focused discussion on it.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 8 Jun 2017 13:57:15 +1200

>     for using 64 bit Interface Identifiers can be found in [RFC7421]

Speaking for myself only, yes, happy.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 8 Jun 2017 20:56:15 +0900

On Wed, Jun 7, 2017 at 8:24 AM, Brian E Carpenter <
[email-masked]> wrote:

> when the addresses are manually configured,
>

In order to publish that text we need to agree on what it means. Can you
explain the semantics of the the interface identifier of a manually
configured IPv6 address? What are they used for?

Note: the semantics are *not* the same as the prefix length of an IPv4
address. The prefix length of an IPv4 address implies that that subnet is
reachable on, but the IID implies nothing about reachability.

---

From: [email-masked]
Date: Thu, 8 Jun 2017 14:10:47 +0200

> In order to publish that text we need to agree on what it means. Can you explain the semantics of the the interface identifier of a manually configured IPv6 address? What are they used for?
> 
> Note: the semantics are *not* the same as the prefix length of an IPv4 address. The prefix length of an IPv4 address implies that that subnet is reachable on, but the IID implies nothing about reachability.

I'm not sure I understand your point.

RFC4291:

   IPv6 nodes may have considerable or little knowledge of the internal
   structure of the IPv6 address, depending on the role the node plays
   (for instance, host versus router).  At a minimum, a node may
   consider that unicast addresses (including its own) have no internal
   structure:

   |                           128 bits                              |
   +-----------------------------------------------------------------+
   |                          node address                           |
   +-----------------------------------------------------------------+

   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          |
   +-------------------------------+---------------------------------+

Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 8 Jun 2017 21:42:00 +0900

On Thu, Jun 8, 2017 at 12:13 AM, David Farmer <[email-masked]> wrote:

> implementations, but also it seems like a false imperative.
>

Currently the standard says "are 64 bits long". Do we need to change that?
Can we just say "are 64 bits long except when manually configured"?

> not enforced by an IPv6 implementations or hard coded in some way.

I have no issue with manual configuration.

However, I think IPv6 implementations that don't support manual
configuration must be able to reject non-64 bit IIDs, since that is the
standard. Saying "SHOULD be 64 bits long" means they "MAY be /81, /99 or
/123", and those are against BCP 204 (RFC 7934).

It's not clear to me whether the signatories of this document care about
future IPv6-over-foo documents. They seem to be mostly focused on manual
configuration. However, if we want to say that future IPv6-over-foo
documents can specify non-64-bit IIDs, then that should require formally
updating this document and providing rationale of why the link layer does
not allow the network to follow the addressing best practices in BCP 204.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 08 Jun 2017 08:59:18 -0700

At Thu, 8 Jun 2017 20:56:15 +0900,

> configured IPv6 address? What are they used for?

Right, this text is actually a bit awkward in that sense.  I think
this message is a good answer to this question:
https://www.ietf.org/mail-archive/web/ipv6/current/msg27573.html

"only relevant to SLAAC" may be too strong from an architectural point
of view, but at least that's today's reality.  So "except when the
addresses are manually configured" actually doesn't make much sense.
I was aware of that oddity too, but I didn't go into this point so we
could focus on whether we can at least agree on a more higher level
point, i.e., if we can agree that manual configuration is
(effectively) an exception of the IID length woe while 64 is
acceptable for SLAAC (unless other standard protocol overturns it).
Now that we are on this detail, this is what I would envision as
something that this draft might actually have wanted to say and that
most of us can hopefully agree on:

    Interface Identifiers must be 64 bit except for addresses that
    start with the binary value 000 and unless a different value is
    defined in standards track documents.  The rationale for using 64
    bit Interface Identifiers can be found in [RFC7421].  Note that
    the separation between the interface identifier and the subnet
    prefix is not important unless the address is configured using
    stateless address autoconfiguration [RFC4862].  So, for example,
    this constraint on the length of interface identifiers is
    irrelevant to manually configured addresses in practice.

    IPv6 unicast routing is based on prefixes of any valid length up
    to 128 [BCP198], and so is on-link determination ([RFC5942],
    [I-D.jinmei-6man-prefix-clarify]).  In particular, the fact that
    the "subnet prefix" length of certain addresses is 64 in terms of
    the addressing architecture is independent from whether addresses
    that match this prefix are considered to be on-link.  For example,
    [RFC6164] standardises 127 bit prefixes for on-link determination
    on inter-router point-to-point links.  This is not contradictory
    to that an address used in this link may have a 64-bit interface
    identifier (and a 64-bit subnet prefix as a result).

Notes:
- I've replaced "should" with "must" in the first sentence as
  discussed before, as I thought this is critical for some group and
  is still acceptable for other group with the additional conditions
  ("except" and "unless").
- Brian might want to be more explicit about the relationship between
  this and ipv6-over-foo specs, but I didn't do that for now.  If we
  can agree on the sense of the text it will be a relatively
  straightforward update.
- we may also want to emphasize that an implementation must not
  blindly hardcode 64 either as the length of interface identifiers or
  as on-link prefix length.  again, as long as we can agree on the
  general sense it will be a trivial update.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Jun 2017 07:19:06 +0300

On 06/08/2017 02:56 PM, Lorenzo Colitti wrote:
> On Wed, Jun 7, 2017 at 8:24 AM, Brian E Carpenter
> address. The prefix length of an IPv4 address implies that that subnet
> is reachable on, but the IID implies nothing about reachability.

The semantics are exactly the same. An address is an address.

The IID only comes into play when you specify prefixes: when you know
that a given subnet employs a given prefix, the 128-prefix bits are what
differentiate among nodes within such subnet (although such distinction
is not even necessary).

The only reason why we care abut IIDs is because with SLAAC, that's the
part each host has to generate. -- e.g., in a DHCPv6 world you only care
about whole addresses, and prefixes in your routing table.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Jun 2017 07:24:03 +0300

On 06/08/2017 03:42 PM, Lorenzo Colitti wrote:
> On Thu, Jun 8, 2017 at 12:13 AM, David Farmer <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     I think "should be 64" is the correct language, primarily because
>     "must be 64" has been misinterpreted several times to justify hard
>     coding 64 in IPv6 implementations, but also it seems like a false
>     imperative.
> 
> 
> Currently the standard says "are 64 bits long".

This is certainly a historical artifact arising from SLAAC.

> Do we need to change
> that? Can we just say "are 64 bits long except when manually configured"?
> 
>     I think either of these makes it clear 64 bit is the norm, but this
>     should not enforced by an IPv6 implementations or hard coded in some
>     way. 
> 
> 

BCP204 talks about multiple addresses. As long as whatever prefix is
employed allows for multiple addresses, I don't see how that goes
against BCP204.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 9 Jun 2017 15:36:08 +0900

> employed allows for multiple addresses, I don't see how that goes

That's not true at all. As an example: see if you can build a network that
uses a /99 and satisfies the recommendations in section 8 or BCP 204.

---

From: [email-masked]
Date: Fri, 9 Jun 2017 09:46:56 +0200

> On 6 Jun 2017, at 00:25, Brian E Carpenter <[email-masked]> wrote:
> 

do we have a rationale for fixing the value in the IPv6-over-foo documents (anymore)?

Cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Jun 2017 14:06:08 +0300

On 06/09/2017 09:36 AM, Lorenzo Colitti wrote:
> On Fri, Jun 9, 2017 at 1:24 PM, Fernando Gont <[email-masked]
> That's not true at all. As an example: see if you can build a network
> that uses a /99 and satisfies the recommendations in section 8 or BCP 204.

Could you explain why a 799 wouldn't satisfy bcp204?

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Jun 2017 15:24:57 +0300

> do we have a rationale for fixing the value in the IPv6-over-foo documents (anymore)?

At the time of this writing, we should probably be in the camp of "If
you do slaac, better stick to 64, since it's know to work with legacy
implementations, and besides, allows for sparse allocation (reduced
collisions of IIDs when you pick a random one, resistance to address
scans, etc.).

There's no compelling technical argument for mandating /64 (i.e., such
specific value) if you do manual configuration or, for instance,
stateful DHCPv6. And the recommendation for /64 for slaac mostly has to
do with backwards compatibility than with anything else.

Thanks,

---

From: Tim Chown <[email-masked]>
Date: Fri, 9 Jun 2017 12:45:39 +0000

> On 9 Jun 2017, at 13:24, Fernando Gont <[email-masked]> wrote:
> 

I think the term “manual configuration” for non-SLAAC cases is a little misleading. Many deployments, be they server deployments, or point-to-point link configurations, are likely to be increasingly automatically provisioned in some way; then there is no “manual” configuration per se. 

Tim

---

From: Philip Homburg <[email-masked]>
Date: Fri, 09 Jun 2017 14:55:13 +0200

> I think the term manual configuration for non-SLAAC cases is a
> little misleading. Many deployments, be they server deployments,
> or point-to-point link configurations, are likely to be increasingly
> automatically provisioned in some way; then there is no manual
> configuration per se.

Historically, in a networking context, this is called manual or static
configuration.

I'm not aware of a any term that is in wide spread use that specifically
refers to the case where host addresses are set by provisioning software.

---

From: David Farmer <[email-masked]>
Date: Fri, 9 Jun 2017 09:31:55 -0500

> uses a /99 and satisfies the recommendations in section 8 or BCP 204.

Yes, to meet the specific RECOMMENDATIONS in BCP204 /64 is necessary.
However, the fundamental intent of BCP 204 is that general-purpose hosts
should get as many addresses as they reasonably want, in some
situation hundreds
or thousands of addresses could be consider unreasonable.  I'll note it
doesn't directly speak to security or privacy consideration such as
randomized assignment or even suggest sparse assignment, it does reference
RFC7217 in the Common IPv6 Deployment Model section, but that's it. So, in
short BCP204 is fundamentally about making sure hosts have many addresses
available to them.

It seems to me that extremely long prefixes like /120 or longer are likely
unable to achieve the intent of BCP204 for any significant number of hosts.
However, anything in the range /112 or shorter should have plenty of
address to achieve the intent of BCP204 for a quite reasonable numbers of
hosts, at least many hundreds of hosts.

So, of the examples you provided, /123 is unlikely to achieve the intent of
BCP204, but /81 or /99, while they don't meet the specific RECOMMENDATIONS
of BCP204 there doesn't seem to be any reason they couldn't achieve the
fundamental intent of BCP204, granted with without much sparseness or
entropy in the assignments, but that's not specifically part of BCP204.

Thanks.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Jun 2017 16:14:37 +0300

> I think the term “manual configuration” for non-SLAAC cases is a little misleading. Many deployments, be they server deployments, or point-to-point link configurations, are likely to be increasingl…

Say "non-automatic"? Something else?  (but..well... for the pov of IPv6,
if it's not slaac or stateful dhcpv6, it's manual).

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Jun 2017 17:50:24 +0300

On 06/09/2017 05:31 PM, David Farmer wrote:
> 
> 
> On Fri, Jun 9, 2017 at 1:36 AM, Lorenzo Colitti <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     That's not true at all. As an example: see if you can build a
>     network that uses a /99 and satisfies the recommendations in section
>     8 or BCP 204.
> 
> 

I don't see anything in BCP204 where /64 is a MUST or even RECOMMENDED.

> It seems to me that extremely long prefixes like /120 or longer are
> likely unable to achieve the intent of BCP204 for any significant number
> of hosts. However, anything in the range /112 or shorter should have
> plenty of address to achieve the intent of BCP204 for a quite reasonable
> numbers of hosts, at least many hundreds of hosts.
> 
> So, of the examples you provided, /123 is unlikely to achieve the intent
> of BCP204, but /81 or /99, while they don't meet the specific
> RECOMMENDATIONS of BCP204 there doesn't seem to be any reason they
> couldn't achieve the fundamental intent of BCP204, granted with without
> much sparseness or entropy in the assignments, but that's not
> specifically part of BCP204.

Could you copy&paste the "specific recommendations" you're referring to?

I haven't found any. And I see no reason for which the authors of bcp204
should have cared about a specific prefix length.

Thanks,

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Fri, 09 Jun 2017 13:42:50 -0300

Hello all,

This has NOT been what we have been seeing in our measurements. In fact, 
for some of us it came as a bit of a surprise. We were looking into 
detecting IPv6 NAT in the wild.

Obviously all experiments are limited and can be skewed in various ways, 
but the data we got so far seems to indicate a prevalence of over 95% 
for IPv4 NAT but hardly over 0.6% for IPv6 NAT.

I am **very** interested in whatever concrete, specific evidence of IPv6 
NAT you may have since I´d like to contrast it against our experiment 
and see what we could be doing wrong.

Thank you!

/Carlos

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Fri, 09 Jun 2017 13:46:40 -0300

I support this draft. Prefix length should have always been a parameter. 
Since when hardcoding things became a good idea ?

On 2 Jun 2017, at 11:11, Job Snijders wrote:

> Hi Working Group,
>
> Please review the below.
>
> Kind regards,
>
> Job
> en ----- Forwarded message from [email-masked] -----
>
> Christopher Morrow <[email-masked]>,
> Morrow
> Subject: New Version Notification for 
> URL:            
> submission

---

From: David Farmer <[email-masked]>
Date: Fri, 9 Jun 2017 12:51:49 -0500

> I don't see anything in BCP204 where /64 is a MUST or even RECOMMENDED.

It's not in the normative language, but it is part of the RFCs
recommendations section, see below.

> Could you copy&paste the "specific recommendations" you're referring to?

Second paragraph, second and third sentences of section 8;

   This can be achieved either by allowing the host
   to form new addresses autonomously (e.g., via SLAAC) or by providing
   the host with a dedicated /64 prefix.  The prefix MAY be provided
   using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.

Furthermore, I would concur that those are the only current standards track
ways to achieve the desired result and they require /64 either per host or
per subnet.

> should have cared about a specific prefix length.

Hope that helps!

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Jun 2017 21:04:30 +0300

> recommendations section, see below.

That comment, in non-RFC2119, is like "one possible way to do it".

That is, we don't need to comply with non-normative language in a
document that does employ normative language.

> Furthermore, I would concur that those are the only current standards
> track ways to achieve the desired result and they require /64 either per
> host or per subnet.

Exactly: the document from the subject line is exactly about forcing the
hardcoded /64 everywhere.

>     should have cared about a specific prefix length.

If the specific length was important, they should have cared. However,
the aforementioned bcp talks about being able to get multiple addresses.
The pool size is, for the most part, irrelevant.

You can get such multiple addresses with /64, /60, /56/ or /48, or even /32.

Pushing for the specific /64 value is not about a technical agument, but
rather about trying to convert an historical actifact into a technical one.

---

From: [email-masked]
Date: Fri, 9 Jun 2017 20:25:29 +0200

> On 9 Jun 2017, at 14:24, Fernando Gont <[email-masked]> wrote:
> 

your goal is to remove the 64 bit boundary from RFC2464 et al and update RFC4862?
I intended the question for Brian, as he seemed to be of a different view.

Ole

PS: you might want to look up "legacy" in a dictionary

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Jun 2017 21:52:48 +0300

> your goal is to remove the 64 bit boundary from RFC2464 et al and update RFC4862?

No. I'm just saying that such specific value is an historical artifact,
not a technical one.

It's fine for the /64 to stay for slaac -- although the more clear we
make it that its a parameter, rather some value that came from an
oracle, the better.

> PS: you might want to look up "legacy" in a dictionary

Agreed. I meant "implementations that expect /64", which are likely to
be a lot (if not all) nowadays. (not sure why I used the term "legacy")

Thanks,

---

From: [email-masked]
Date: Fri, 9 Jun 2017 21:20:55 +0200

> On 9 Jun 2017, at 20:52, Fernando Gont <[email-masked]> wrote:
> 

There are many reasons why there is a fixed split between what the network gets and what the hosts gets. It's part of a tussle.
As well as to allow for 8+8. I don't see that the particular tussle has changed much over the last 20 years, nor the reasons for 8+8.

Any credible opponent of the fixed 64 bit boundary must answer the issues laid out in RFC7421.

Also the players on network side of the tussle must give credible reasons for why 64 bits isn't enough for them.

Brian assured us the draft isn't about this. Hard to say from the draft and it seems you are of a different opinon.

Ole

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 9 Jun 2017 19:30:49 +0000

I keep reading less into this supposedly mandatory 64-bit boundary than some others seem to, especially for the future.

RFC 2464 (IPv6 over Ethernet) is short, sweet, and due for a -bis version. The rationale for 64-bit IIDs is simply obsolete. Use of EUI-64 has been deprecated.

   The Interface Identifier [AARCH] for an Ethernet interface is based
   on the EUI-64 identifier [EUI64] derived from the interface's built-
   in 48-bit IEEE 802 address.

I see a lot of "64-bit IIDs mandatory" hinging on this one sentence, and its premise no longer holds. At the very least, 48-bit IIDs should be feasible over Ethernet, and you'd lose no randomness, compared with EUI-64. If not many other possibilities.

And RFC 4862 (SLAAC) is quite agnostic on this matter, requiring use of a link local address IID and RA-supplied prefix, and the total number of bits must <= 128.

   3.  If the length of the interface identifier is N bits, the right-
       most N bits of the address are replaced by the interface
       identifier.

   If the sum of the link-local prefix length and N is larger than 128,
   autoconfiguration fails and manual configuration is required.

So what's left? How LLAs are formed. LLAs are formed using a well-known prefix and EUI-64. Same old story, LLAs also hinge on an obsolescent RFC 2464. This can all change, with RFC 2464-bis. RFC 4862 wouldn't even need to change, if an RFC 2464-bis were to redefine how IPv6-over-Ethernet IIDs are formed.

Every inflexible supposed "rule" about 64-bit IIDs seems to hinge on an obsolete notion, which can, should, and probably will be revised in due course. In my view, we should be allowing for an easy transition after RFC 2464-bis, with this new draft, instead of cementing this 64-bit boundary.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 9 Jun 2017 19:48:03 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of [email-masked]

> Any credible opponent of the fixed 64 bit boundary must answer the issues

I agree with this comment. It would take some time to go through each example cited, but I don't think it's impossible to do. It would be more difficult to support IID longer than 64 bits, but shorter should be doable.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jun 2017 13:47:40 +1200

> I intended the question for Brian, as he seemed to be of a different view.

It's hard to track this conversation, but anyway IMHO 2464bis should specify
/64 as if the addressing architecture didn't even mention it. It has
to specify something for SLAAC to work, and we have 20 years of deployed
code based on /64. So we don't have the luxury of changing it, even
if we want to.

I'm not aware of any technical changes needed in 4862. Jinmei-san has
convinced me off line that 4862 does logically require the IID length
for link-local addresses and global-scope SLAAC addresses to be the same.
I wish the text stated this explicitly, but that's an editorial issue.
Apart from that, it leaves the IID length as a parameter and that's
as it should be.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jun 2017 13:58:10 +1200

> do we have a rationale for fixing the value in the IPv6-over-foo documents (anymore)?

My rationale is that

a) RFC4862 describes it very carefully as a parameter.
b) The addressing architecture describes it as a parameter ("n"),
and then suddenly defines n=64 for no reason.
c) It gives no reason because the true reason was the obsoleted EUI-64 mechanism.
d) There is no physical reason for n to have the same value on different link media.
e) Future link media might more appropriately use a different value.
f) Therefore the addressing architecture should only define n=64 as a default
recommendation for IPv6-over-foo documents.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jun 2017 14:06:15 +1200

> I think the term “manual configuration” for non-SLAAC cases is a little misleading. Many deployments, be they server deployments, or point-to-point link configurations, are likely to be increasingl…

Yes. I think "static configuration" is closer to what is intended.
Even that isn't quite correct. Maybe it just has to be "non-SLAAC";
the fact that schemes like ILNP also split at the /64 boundary seems
to be mainly a coincidence.

    Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sat, 10 Jun 2017 02:23:39 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter

> It's hard to track this conversation, but anyway IMHO 2464bis
> should specify /64 as if the addressing architecture didn't
> even mention it. It has to specify something for SLAAC to work,
> and we have 20 years of deployed code based on /64. So we don't
> have the luxury of changing it, even if we want to.

But it can be changed, in a graceful manner. As you said in another post, the reason/excuse for the 64-bit IID length in RFC 2464 no longer applies. So here's what RFC 2464-bis could say:

Each (updated) host must be capable of creating IIDs of variable lengths, from 64 bits to 1 bit. The 64-bit IID is formed as it is now. To shorten the IID, e.g. as required for SLAAC or other protocols, the host can use a number of techniques. One such might be, truncate the upper bits first, until 16 bits have been truncated, then truncate the upper bit and the lower bit, alternating between one and the other, until the needed IID length is reached.

That's pretty much it for RFC 2464-bis.

Then for RFC 4862, which would need essentially no change. Routers should continue to advertise 64-bit prefix lengths, for legacy hosts that can only support 64-bit IIDs. Routers may also advertise prefixes longer than 64 bits, for use by updated hosts.

A host creates its 128-bit interface address using the prefix length specified in the RA, then appending the appropriate length IID, where the length of the IID is 128-prefix length.

I don't think we should need to state flat out that SLAAC can only work with 64-bit IIDs, nor that Ethernet interfaces can only be identified by 64-bit IIDs. This need not be the case, with RFC 2464-bis (which I think is needed regardless).

Bert

---

From: [email-masked]
Date: Sat, 10 Jun 2017 15:14:40 +0200

Brian,

> code based on /64. So we don't have the luxury of changing it, even

This is confusing.
On one hand you argue we have 20 years of deployed code base and that we cannot change it, on the other hand you want to remove the 64 bit boundary from the addressing architecture, presumably with the goal of changing it?

The argument that SLAAC needs an standard-set per data-link type fixed IID length is a tenuous argument. The only technical requirement for SLAAC to work is that the the IID length is the same across all nodes on a given link.

If we remove the 64 bit boundary from 4291, then an update of 2464 will likely result in the removal of any bit boundary there as well.

> Apart from that, it leaves the IID length as a parameter and that's

RFC4862 says:
Note that the address architecture [RFC4291 also defines the length of the interface identifiers for
some set of addresses, but the two sets of definitions must be
consistent.  In many cases, the identifier will be derived from
the interface's link-layer address.

The IID length in the IPv6 architecture is fixed. And it has to be consistent across 4291, 4862 and IPv6 over foo documents.
Feel free to look at it as a parameter, and you can pick any value you like from the 0-128 range as long as you pick 64.
That's the current state. And that is what every implementation does. If you want to _change_ that. Then you need to consider that in the light of 7421 and of the wider consequences for the Internet.

I am still confused what this draft proposes to change.

Ole

---

From: [email-masked]
Date: Sat, 10 Jun 2017 15:24:34 +0200

Brian,

> a) RFC4862 describes it very carefully as a parameter.

And explicitly says it must be consistent with the value defined in 4291 and IPV6 over foo documents.

> and then suddenly defines n=64 for no reason.

No reason? Please.
Read RFC7421.

> c) It gives no reason because the true reason was the obsoleted EUI-64 mechanism.

No, that's too simple a view of history.
There were at least 3 driving reasons.

1) The compromise of choosing 128 bit addresses instead of 64 bit or variable length.
    It was quite clear that 64 bits was plenty, so it made sense to tilt the playing field to ensure that we wouldn't repeat the IPv4 mistakes   of not giving end-hosts enough addresses. This was done for only 1/8th of the address space (later changed).
2) SLAAC
3) 8+8

> d) There is no physical reason for n to have the same value on different link media.

There is no technical reason why IID length is tied to the datalink type.
There was at some point when we thought it was a good idea to embed L2 addresses in the network layer address.
Even so, it would be trivial to make implementations deal with arbitrary IID lengths.

> e) Future link media might more appropriately use a different value.

See above. <n> has very little to do with data-linkt type.

> recommendation for IPv6-over-foo documents.

I don't think that follows from the arguments laid out above.
We can (if we want to), make SLAAC work with any IID length. Including 0.

I still don't understand what the goal is here. What problem are you solving? What is the proposal?

Ole

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sat, 10 Jun 2017 08:42:55 -0700

> And explicitly says it must be consistent with the value defined in 4291 and IPV6 over foo documents.

It's actually subtle how RFC4862 ended up with the current text.  It
might help if we recall the discussion at that time:
https://www.ietf.org/mail-archive/web/ipv6/current/msg01797.html

Different people may interpret it in different ways, but my
recollection is that

- we actually thought it was quite unlikely to see a change to the IID
  length, not least because the addressing architecture spec (RFC3513
  at that time) is "100% unambiguous" about it, i.e., 64 bits.
- but, the addr-arch and link-type specific documents defined the
  length (seemingly) independently.  RFC2462 referred to addr-arch in
  one place and referred to link-type specific docs in other place.
  RFC2462 also mentioned the magic number of 64.  Since the
  relationship between the addr-arch and link-type is not explicit
  this could potentially lead to inconsistency between them (we only
  relied on the IETF human review process for consistency).
- ideally we should have resolved this fragility at that point, but it
  was considered out of scope of rfc2462bis (and probably rightly so).
- as a result, in rfc2462bis we decided to remove the reference to the
  magic number to avoid further possible conflict and specify
  link-type specific docs as the primary source of the IID length,
  while noting the addr-arch defines the length so it will be less
  likely to cause inconsistency if and when either of them is updated.
  And, as long as we use link-type specific documents as the primary
  source, it's natural to expect it might be different for different
  link types (no matter how unlikely it was deemed due to the
  constraint of addr-arch).  So we also added notes to implementations
  not to assume a particular constant.

In a nutshell, RFC4862 is not an appropriate source as a supporting
material for either position on this matter, whether to keep fixing 64
or make it more variable even in practice.  RFC4862 tried to keep
itself as independent as possible from that discussion, while being
sufficiently flexible in case the current practice (i.e. fixed 64)
ever changes.

I'd also note once again that this discussion has nothing to do with
the fact that we can perform 'ifconfig en0 2001:db8::1/120'.  This
operation configures a 128-bit IPv6 address with 120-bit on-link
prefix.  On-link prefixes have always been variable, and they have
nothing to do with IID length or SLAAC.  We don't have to update
addr-arch or RFC4862 because of this.  (draft-bourbaki-6man-classless-ipv6-00
seems to be confused on this point, and I suspect it increases the
confusion and controversy in this whole thread).

--
JINMEI, Tatuya

---

From: David Farmer <[email-masked]>
Date: Sat, 10 Jun 2017 15:34:30 -0500

>    consider that unicast addresses (including its own) have no internal

To be truly honest I've never found that description helpful, in fact I
think it is part of the problem. It confuses classic IPv4 subnet
prefix(mask) terminology with IIDs and on-link prefixes for IPv6, which are
subtly different.  In my opinion, the IPv4 subnet prefix is not used in the
generation of the IPv4 address per se, it is really only used to determine
locality, in this way it is similar to an IPv6 on-link prefix, and has
little to do with the IID length.
However, the above quote by using subnet prefix terminology, ties the
subnet prefix length and IID length directly together, also seeming to
indicate that IIDs and on-link prefixes have to be congruent, but the IID
and on-link prefix can be incongruent and therefore again using subnet
prefix terminology really confuses the situation and I think this is the
root of this conflict. Therefore when we say the IID is 64, the above seems
says the subnet prefix is /64 and therefore the on-link prefix is also /64,
but this is not suppose to be the case.

I've been thinking about this for a while and I think the only way to
resolve this conflict is to stop using "subnet prefix" in reference to IPv6
and only use it in reference to IPv4.  I would propose substituting
"addressing prefix" for "subnet prefix" in the above quotation from RFC4291
and add a separate discussion of on-link prefixes and then note the classic
IPv4 subnet prefix length is equivalent to the on-link prefix length in
IPv6.  If this is done then the statement that the IID length MUST be 64
says nothing about the on-link prefix length.

The IID is only used to generate an address, once the address has been
generated the IID and its length are actually irrelevant, the address
itself is 128 bits long, and only the on-link prefix and length is relevant
in determining locality.

So, I think if we stop using subnet prefix vocabulary with IPv6, we might
find consensus and resolve this conflict.

Thanks

---

From: Fred Baker <[email-masked]>
Date: Sat, 10 Jun 2017 13:44:34 -0700

> On Jun 10, 2017, at 1:34 PM, David Farmer <[email-masked]> wrote:
> 
> I've been thinking about this for a while and I think the only way to resolve this conflict is to stop using "subnet prefix" in reference to IPv6 and only use it in reference to IPv4. 

Very much agree. That's the reason RFC 7608 calls it a "prefix length". Prefixes, of course, are a routing concept, and where you are in the network affects your perception of the prefix length immensely. RIRs are allocated prefixes by the IANA and in turn sub-allocate them to ISPs and PI prefix holders. ISPs in turn allocate prefixes to customers, and those customers and PI prefix holders end up at some point with LAN subnet prefixes or prefixes on p2p links, and hosts think in terms of /128. There may be other prefix lengths along the way.

The only place it makes sense to me to talk about a specific length for an IID is with SLAAC; if a network is allocating addresses manually or using DHCP, they are in control and can do whatever they like - I dare you to stop them. But the IID is the part that is never a prefix - the last N bits of a /128, and by convention 64 bits.

---

From: [email-masked]
Date: Sat, 10 Jun 2017 23:15:24 +0200 (CEST)

I agree with the general comments about confusing classic IPv4 subnet
prefix(mask) terminology with IIDs and on-link prefixes for IPv6.

> itself is 128 bits long, and only the on-link prefix and length is relevant

An explicit statement that IID is only relevant for SLAAC would be
very welcome.

> find consensus and resolve this conflict.

That may well work for the people on this list. Unfortunately, I'm not
optimistic about ACME Company's Joe network manager understanding it.

Steinar Haug, AS2116

---

From: David Farmer <[email-masked]>
Date: Sat, 10 Jun 2017 18:23:36 -0500

> On Jun 10, 2017, at 16:15, [email-masked] wrote:

That is why I suggest noting that the classic IPv4 subnet prefix is most similar to the IPv6 on-link prefix, which both can be of any length, and both are directly related to routing, by determining what is locally reachable.

Where as the IID length is a parameter defined as 64 bits and is related to (automatic) addressing and is actually only tangentially related to routing. 

So, I think we have been arguing about whether the equivalent of the IPv4 subnet prefix for IPv6 is fixed at /64 or not, and by tying the term subnet prefix to the definition of IID in RFC4291 and its predecessors we created an unnecessary conflict. Because the purpose of the IPv4 subnet prefix is more closely related to the IPv6 on-link prefix not the IID.

Thanks

David Farmer

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Jun 2017 11:37:44 +1200

> On one hand you argue we have 20 years of deployed code base and that we cannot change it, on the other hand you want to remove the 64 bit boundary from the addressing architecture, presumably with…

This has two aspects for me:
1) It's simply out of place to define an arbitrary constant
in something called "architecture".

2) By defining it globally we forbid using some other value
on a future link-layer where a different value might be better.
A 'should' could cover that, of course, which is why I accept
the current 4291bis text.
 
> The argument that SLAAC needs an standard-set per data-link type fixed IID length is a tenuous argument. The only technical requirement for SLAAC to work is that the the IID length is the same acro…

Yes, but for products to work out of the box without setting
a value, you need a fixed value per link type. I can't see any
practical alternative.

> If we remove the 64 bit boundary from 4291, then an update of 2464 will likely result in the removal of any bit boundary there as well.

No, for the out-of-the-box reason. I can't see any practical alternative
to a fixed length per link type.

> The IID length in the IPv6 architecture is fixed.

That is what the current standards say, yes.

> And it has to be consistent across 4291, 4862 and IPv6 over foo documents.

No, it only has to be consistent within a given link type (and that applies
whether the link type is physical or virtual). It's an unnecessary restriction
to say that it must be equal for all link types.

> I am still confused what this draft proposes to change.

Nothing in any current implementation.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Jun 2017 11:51:12 +1200

> And explicitly says it must be consistent with the value defined in 4291 and IPV6 over foo documents.

Correct. The second (consistent with IPv6/foo) is necessary. The first is
an artificial constraint IMHO.

>> and then suddenly defines n=64 for no reason.

I was thinking of rfc4291bis at that point. Of course, RFC4291 provides
a historical reason: compatibility with modified EUI-64. That's gone
from rfc4291bis.
 
>     It was quite clear that 64 bits was plenty, so it made sense to tilt the playing field to ensure that we wouldn't repeat the IPv4 mistakes   of not giving end-hosts enough addresses. This was d…

I'd say stub networks, not end hosts, but yes. And the privacy argument now strengthens
that. There are a lot of reasons why we need much more than 8 bits. Whether we need
more than about 40 is an open question, however.

> 2) SLAAC

Of course. Again, enough bits are needed.

Which is really 6+2+8. But again, what's important is having enough bits,
not any specific number.

> There is no technical reason why IID length is tied to the datalink type.

I believe there is: so that SLAAC can work with devices out of the box, without
having to set the IID length.

> See above. <n> has very little to do with data-linkt type.

That's correct. By dropping modified EUI-64 we have removed a
noticeable dependency. But who's to say there won't be a future
link type whose deployment scenario is better suited by, say,
80 bit prefixes and 48 bit IIDs? I have no idea about that.

> I still don't understand what the goal is here. What problem are you solving? What is the proposal?

Removing some unnecessary inflexibility. Exactly what the words in rfc4291bis do.

Regards
    Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 11 Jun 2017 00:00:17 +0000

-----Original Message-----

>> If we remove the 64 bit boundary from 4291, then an update of 2464
>> will likely result in the removal of any bit boundary there as well.
>
> No, for the out-of-the-box reason. I can't see any practical
> alternative to a fixed length per link type.

I think there are practical alternatives, so I too would suggest not to state flatly that SLAAC requires fixed length IIDs. Anything that requires RAs to work can make adjustments to its IID, in real time.

ULAs and link local would need to create IIDs with no knowledge of the outside world. But not SLAAC.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 11 Jun 2017 00:18:58 +0000

-----Original Message-----

> That is why I suggest noting that the classic IPv4 subnet prefix
> is most similar to the IPv6 on-link prefix, which both can be of
> any length, and both are directly related to routing, by
> determining what is locally reachable.

I see many taking this view, but the subtlety gets lost to me. In IPv4, I'm given, say, five class C blocks to use on a platform. The service which assigned me those five class C blocks assumes the prefix is 24 bits wide, when they route packets to these platforms. Then I create 60 subnets out of these five class C blocks, and what I consider "prefix" becomes 26, 28, or other width. How is this different from the way "subnet prefix" is applied to IPv6?

> So, I think we have been arguing about whether the equivalent of the
> IPv4 subnet prefix for IPv6 is fixed at /64 or not, and by tying the
> term subnet prefix to the definition of IID in RFC4291 and its
> predecessors we created an unnecessary conflict. Because the purpose
> of the IPv4 subnet prefix is more closely related to the IPv6 on-link
> prefix not the IID.

Even assuming the fixed length IID, I'm not terribly taken with this argument. If the IPv6 ISP assigns me a /56, that ISP's definition of "prefix" will be 56 bits. When I use that /56 block, my definition of "prefix" will become /64. Not all that different from IPv4, as described above?

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Jun 2017 13:46:50 +1200

> I think there are practical alternatives, so I too would suggest not to state flatly that SLAAC requires fixed length IIDs. Anything that requires RAs to work can make adjustments to its IID, in re…

It cannot adjust its IID length when assigning itself a link-local address *before*
receiving any RA/PIO messages. But whatever length N of IID it uses to generate its
LL address must match the the prefix length 128-N in a later RA/PIO with A=1.
Otherwise, SLAAC fails.

(see Section 5.5.3 bullet d of RFC4862, as Jinmei-san kindly explained to me.)

So in fact the only thing that works is if the equipment assumes the same IID length
as the router announces (as 128-N). Therefore, N must be predefined.
 
> ULAs and link local would need to create IIDs with no knowledge of the outside world. But not SLAAC.

ULAs have nothing to do with it; SLAAC doesn't care whether a prefix is ULA or
globally reachable. And LL is *not* independent of SLAAC.

Regards
    Brian

---

From: [email-masked]
Date: Sun, 11 Jun 2017 20:29:55 +0200

Brian,

> as the router announces (as 128-N). Therefore, N must be predefined.

As I said the argument is tenuous.
This is a trivial change, if we were to go down this route. The fixed constant is a fundamental part of the IPv6 architecture. If we remove it from there, then it is a natural consequence to remove it from the IPv6 over foo documents and tweak SLAAC.

The changes to SLAAC could be in two paragraphs:
 - LL generation. Fix IID length to 118 _or_ make IID length implementation specific.
   The on-link prefix for LL is regardless fe80::/10.
 - IID length = 128 - length of advertised prefix. Host is required to generate IID of suitable length per advertised prefix.
   (or just generate a 128 bit IID, and chop of the bits needed.

To summarize:
 - There is no technical reason why SLAAC cannot be made ot work with arbitrary prefix lengths.
   (including very long prefixes, although it might take a while to find a non-duplicate if the addressing model
   moves from sparse to dense).
 - There is no technical reason to have a fixed IID length defined by data-link type.
 - Removing the constant from the addressing architecture will likely set these changes into motion.
   (i.e. I don't think a position where one wants to remove the 64 bit constant from 4291 and expect the 64 bit boundary
    to stay in IPv6 over foo is tenable.)

If that's what we want. I believe we have to think quite hard about it and we need to consider the consequences quite hard.

Ole

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 11 Jun 2017 22:14:54 +0000

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 

>> I think there are practical alternatives, so I too would suggest
>> not to state flatly that SLAAC requires fixed length IIDs.
>> Anything that requires RAs to work can make adjustments to its
>> IID, in real time.
>
> It cannot adjust its IID length when assigning itself a
> link-local address *before* receiving any RA/PIO messages.

True. Clearly.

> But whatever length N of IID it uses to generate its LL
> address must match the the prefix length 128-N in a later
> RA/PIO with A=1. Otherwise, SLAAC fails. (see Section 5.5.3
> bullet d of RFC4862, as Jinmei-san kindly explained to me.)

Section 5.5.3 states that the prefix length of a valid prefix must be 128-N bits wide, where N is the number of bits of the IID. Then it states that it's the responsibility of the system admin to ensure that prefix lengths are consistent with the IIDs for that link type.

Now, what prevents a link type from having multiple available IID lengths, ready to go, to match varying prefix lengths that might be available? The basic rules are the same. The only difference is that we are no longer held to just one length of IID (for the link type). So it becomes also the host's responsibility, to use an IID length consistent with the length of prefix offered. 

> So in fact the only thing that works is if the equipment
> assumes the same IID length as the router announces (as 128-N).
> Therefore, N must be predefined.

That's the way it works now, but it's hardly the only way it can be made to work. Similarly, IPv4 did not have to remain classful, because that's the way it had been. IP stacks were upgraded, and CIDR became the rule.

>> ULAs and link local would need to create IIDs with no
>> knowledge of the outside world. But not SLAAC.
>
> ULAs have nothing to do with it; SLAAC doesn't care whether a
> prefix is ULA or globally reachable.

I think you missed my point. When the host forms either a ULA or a LLA, the host must do so with no knowledge of anything external to itself. So sure, the IID in those two examples has to be predictable. Instead, there is no valid reason for the IID used in SLAAC to have to be formed independently that way, other than "that's how it's done now."

Once we are freed from the IPX-legacy notion of the IID being formed from the hardware address of the interface, all these preconceived restrictions, derived from that deprecated notion, can be eliminated. Variable length IIDs are ideal for a system with variable length prefixes. Why should we deprecate IPv6 to something less flexible that it can be?

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Jun 2017 11:17:01 +1200

On 12/06/2017 10:14, Manfredi, Albert E wrote:
> I think you missed my point. When the host forms either a ULA or a LLA, the host must do so with no knowledge of anything external to itself. 

Absolutely not, for a ULA. A ULA is simply a global scope address which
happens to lie under a ULA prefix, which is today just another /64 that
comes from a completely standard PIO. A host could form a ULA using SLAAC,
in which case the prefix comes from a completely standard PIO with A=1.
(A host could also receive a ULA via DHCPv6, or it could even be manually
configured, but in those cases it's just like any other global scope
/128.)

    Brian

> So sure, the IID in those two examples has to be predictable. Instead, there is no valid reason for the IID used in SLAAC to have to be formed independently that way, other than "that's how it's done now."
>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 11 Jun 2017 23:23:07 +0000

-----Original Message-----

>> I think you missed my point. When the host forms either a ULA or a
>> LLA, the host must do so with no knowledge of anything external to
>> itself.
>
> Absolutely not, for a ULA. A ULA is simply a global scope address
> which happens to lie under a ULA prefix, which is today just another
> /64 that comes from a completely standard PIO.

You're right. I thought of that too late. Should not have used ULAs as examples of addresses that have to be formed independently by a host.

Bert

---

From: Fernando Gont <[email-masked]>
Date: Mon, 12 Jun 2017 03:40:33 +0300

On 06/10/2017 11:44 PM, Fred Baker wrote:
[....]
> 
> The only place it makes sense to me to talk about a specific length
> for an IID is with SLAAC;

+1

However, we seem to be enforcing /64 for everything, including non-slaac.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 12 Jun 2017 04:02:21 +0300

On 06/12/2017 01:14 AM, Manfredi, Albert E wrote:
[...]
> itself. So sure, the IID in those two examples has to be predictable.
> Instead, there is no valid reason for the IID used in SLAAC to have
> to be formed independently that way, other than "that's how it's done
> now."

Agreed for LLAs. But... what's special about ULAs?

---

From: Fernando Gont <[email-masked]>
Date: Mon, 12 Jun 2017 03:47:41 +0300

On 06/11/2017 02:51 AM, Brian E Carpenter wrote:
[...]
> having to set the IID length.

Not sure I follow.

Router advertised Prefix/N (where N is nowadays hardcoded to be "64",
but need not). Host eploys RFC7217, and grabs 128-N random bits from F()
to generate the IID/address.

Why does N need to be set on a per-link-type basis?

> 80 bit prefixes and 48 bit IIDs? I have no idea about that.

Well, on such links the local router would advertise a /80 rather than a
/64. Why should the clients need to worry about this?

+1

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 12 Jun 2017 03:55:27 +0300

On 06/11/2017 04:46 AM, Brian E Carpenter wrote:
>> -----Original Message----- From: ipv6
>> [mailto:[email-masked]] On Behalf Of Brian E Carpenter
>> 
>>>> If we remove the 64 bit boundary from 4291, then an update of
>>>> 2464 will likely result in the removal of any bit boundary
>>>> there as well.
>>> 
>> not to state flatly that SLAAC requires fixed length IIDs. Anything
>> that requires RAs to work can make adjustments to its IID, in real
>> time.
> 
> It cannot adjust its IID length when assigning itself a link-local
> address *before* receiving any RA/PIO messages. 

link-local could be considered a special case...

---

From: Fernando Gont <[email-masked]>
Date: Mon, 12 Jun 2017 04:00:31 +0300

>    The on-link prefix for LL is regardless fe80::/10.

In practice, it's /64. BSDs assume fe80::/64, and use some of the
assummed-to-be-zero words in that prefix to store e.g. interface index.

+1

+1

>     to stay in IPv6 over foo is tenable.)

Me, I don't think there's a reason to keep the 64 bit constant in
ipv6-over-foo documents. Actually, with RFC8064 in place, there's no
reason why the IID should be link-type dependent.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 12 Jun 2017 10:43:12 -0700

At Sat, 10 Jun 2017 15:34:30 -0500,

> but this is not suppose to be the case.

Agreed.

> says nothing about the on-link prefix length.

Also agreed.  The term "subnet prefix" in RFC4291 and rfc4291bis is so
confusing that we've been having unnecessary controversy.  Although
I'm still not 100% sure about the real goal of
draft-bourbaki-6man-classless-ipv6-00, one thing we could do for
rfc4291bis is to resolve this terminology confusion either by changing
the term and/or by adding more explanation.  IMO this can be done without
changing the addressing architecture itself (so it's within the scope
of rfc4291bis), and I believe it can be accepted by most of us,
whether they prefer "operational needs" or "conceptual purity".

Whether we should keep fixing the IID length for 7/8-ish of unicast
addresses at 64 bits or keep letting link-layer docs specify that
value is an interesting discussion.  But that can and actually should
be done separately and probably be better deferred until we complete
rfc4291bis, since there will be real controversy in that discussion.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Mon, 12 Jun 2017 10:53:42 -0700

At Sat, 10 Jun 2017 13:44:34 -0700,
Fred Baker <[email-masked]> wrote:

> for an IID is with SLAAC; if a network is allocating addresses
> manually or using DHCP, they are in control and can do whatever they
> like - I dare you to stop them. But the IID is the part that is
> never a prefix - the last N bits of a /128, and by convention 64
> bits.

I'm afraid this is not really a correct description of the current
specification (if you're actually proposing to change the current
specifications on this, it would be more helpful if you could clarify
it's a proposal, not an explanation of the current spec).  It's
subtle, but I suspect this subtlety is part of the controversy we've
seen that should actually be unnecessary to have.

If the address is manually configured or configured using DHCPv6 with
some "prefix", that prefix is actually an on-link prefix and has
nothing to do with IID.  The IID length would still be defined by the
link-type specification, and since that should be consistent with the
addressing architecture, it *must* be 64 bits in practice.  But that
doesn't matter for actual operation - when the address is configured
manually or using DHCPv6, only on-link prefix matters in the actual
host behavior, and it can have an arbitrary length.

--
JINMEI, Tatuya

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 12 Jun 2017 18:41:21 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of [Tatuya Jinmei]

> If the address is manually configured or configured using
> DHCPv6 with some "prefix", that prefix is actually an on-link
> prefix and has nothing to do with IID.  The IID length would
> still be defined by the link-type specification, and since that
> should be consistent with the addressing architecture, it *must*
> be 64 bits in practice.

Some of us are saying that the above need not be the case. It is simple enough to create RFC 2464-bis, where this old notion is discarded, and where hosts with Ethernet (or other interfaces too, for that matter) can generate IID lengths that can vary from 64 bits (or actually even 128 bits) to 1 or to 0 bits, if need be. They can do so in real time, in response to the prefix length received in a RA. (We can argue about what algorithm makes sense to create these other IID lengths. Doesn't seem very difficult.) And because the rationale used for 64-bit IIDs, in RFC 2464, is no longer believed to be good, that says a -bis version is warranted.

Said another way, the premise upon which RFC 2464 is written is no longer valid. Therefore, what derived from this premise needs to be re-evaluated. SLAAC should not be used as a reason for fixed length IIDs, much less a 64-bit boundary, in this draft.

So, even before an RFC 2464-bis is written, the language that states that 64-bit IIDs are "mandatory" can be softened. It just does not sound credible or defensible these days.

Bert

---

From: 神明達哉 <[email-masked]>
Date: Mon, 12 Jun 2017 12:04:22 -0700

At Mon, 12 Jun 2017 18:41:21 +0000,

> Some of us are saying that the above need not be the case.

I know.  I just pointed out that it would be an update to the current
spec, and that when someone sas something like that, that person
should be clearer whether it's a proposal of an update or explanation
of the current spec:

>> specifications on this, it would be more helpful if you could
>> clarify it's a proposal, not an explanation of the current spec).
>> It's subtle, but I suspect this subtlety is part of the controversy
>> we've seen that should actually be unnecessary to have.

I have no problem with having a discussion on update proposals like
below.  Of course, however, I may or may not agree on specific
proposals, depending their details.  I'm also not so optimistic about
how "simple" it is.  I'd expect a lot of controversy and long
discussions.

> It is simple enough to create RFC 2464-bis, where this old notion is discarded, and where hosts with Ethernet (or other interfaces too, for that matter) can generate IID lengths that can vary from 64 bits (or actually even 128 bits) to 1 or to 0 bits, if need be. They can do so in real time, in response to the prefix length received in a RA. (We can argue about what algorithm makes sense to create these other IID lengths. Doesn't seem very difficult.) And because the rationale used for 64-bit IIDs, in RFC 2464, is no longer believed to be good, that says a -bis version is warranted.
>

And, ...

> So, even before an RFC 2464-bis is written, the language that states that 64-bit IIDs are "mandatory" can be softened. It just does not sound credible or defensible these days.

... perhaps, but it's still an update to the current specification.
Unless and until we have an update RFC I doubt we can say the softened
behavior is part of the formal protocol specification.  That is,
developers will still refer to RFC2464, RFC4862, RFC4291 (or its bis
if published), and I don't think we can blame if they use a fixed
64-bit IID length for an ethernet interface, even if they use it for
RFC7217.

--
JINMEI, Tatuya

---

From: Fred Baker <[email-masked]>
Date: Mon, 12 Jun 2017 13:17:42 -0700

> On Jun 12, 2017, at 10:53 AM, 神明達哉 <[email-masked]> wrote:
> 
> The IID length would still be defined by the
> addressing architecture, it *must* be 64 bits in practice.

There I disagree, and if I were making a proposal, and if the link layer address were to be relevant to it, my proposal would be that the IID be the link layer address. In an 802.3 or 802.11 network, that is a 48 bit value, in an 802.15.4 network it is 64 bits, and I imagine there are other networks with still other link layer address formats. The only reason to specify a universal IID length is for a universal algorithm that has a specific requirement. The only one I know of is SLAAC.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 12 Jun 2017 13:53:58 -0700

At Mon, 12 Jun 2017 13:17:42 -0700,
Fred Baker <[email-masked]> wrote:

> There I disagree, and if I were making a proposal, and if the link
> layer address were to be relevant to it, my proposal would be that
> the IID be the link layer address. In an 802.3 or 802.11 network,
> that is a 48 bit value, in an 802.15.4 network it is 64 bits, and I
> imagine there are other networks with still other link layer address
> formats. The only reason to specify a universal IID length is for a
> universal algorithm that has a specific requirement. The only one I
> know of is SLAAC.

I'm not sure on which point you disagree with me, but what I tried to
say is that it's a logical consequence of the current specification
(not my opinion on how we should design it).

- For SLAAC, RFC4862 assumes that the IID length is defined in a
  link-type doc and it's consistent with the addressing architecture
- The current addressing architecture spec (indirectly) says that IID
  length is 64-bit for all unicast addresses except those starting
  with binary 000 (i.e., for all global unicast addresses used in
  production in practice).

There is no possibility than a 64-bit IID that meet these conditions.
I understand some people think that it has never made sense or at
least it doesn't make sense today anymore.  I have no problem with
having a discussion on updating the current specifications from that
view.  But it's still an update to the current specification.  We can
disagree on what current specs say and update it if we reach consensus
as such, but we cannot change the fact that the current specs have
said it.

Or perhaps you meant when we consider addresses configured manually or
using DHCPv6, the first point is not applicable and the IID
length doesn't have to be defined by the link-type spec?  If so, I see
the point, but in that case we should more emphasize that IID or its
length doesn't matter, IMO.  Only on-link prefixes and the full
128-bit IPv6 addresses matter for actual host behavior, and they are
irrelevant to the concept of IID.  We could still say the IID in this
case is the right-most bits of the address following the on-link
prefix (whose length can be different from 64 bits), but I don't see a
point in that artificial definition.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Jun 2017 13:26:59 +1200

Fernando,

> Why does N need to be set on a per-link-type basis?

It doesn't *need* to be. But SLAAC by design assumes that it is
set per link-type; that is architectural flexibility which is 
removed by RFC4291, which IMHO is a bad message to send to the future.

I think this is the main reason the IESG sent draft-ietf-6man-rfc4291bis
back to us, and the main reason I signed on to draft-bourbaki-6man-classless-ipv6
> /64. Why should the clients need to worry about this?

Because SLAAC wouldn't work, because the addressing architecture
forbids SLAAC from working in this case.

>> Removing some unnecessary inflexibility. Exactly what the words in rfc4291bis do.

Well actually, my statement was wrong. rfc4291bis needs a s/required/recommended/
to remove the inflexibility.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Jun 2017 13:28:04 +1200

> link-local could be considered a special case...

Maybe, but that isn't how RFC4862 is written today.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Jun 2017 13:35:18 +1200

> reason why the IID should be link-type dependent.

I believe that is simply false unless you want to go back to the era
of DIP switches with instructions to users to
a) choose an IID length for their new subnet
b) set the DIP switches on every device to select that length
c) then plug and play.

Otherwise LL addresses cannot be formed consistently on the
whole link.

OK, that is caricature, but without a substantial reworking of
RFC4862 I believe that is essentially what we would need, in
an automated version, before SLAAC can start.

Anway, all this is empty talk as long as the addressing architecture
*requires* 64 bits rather than *recommending* 64 bits.

   Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 13 Jun 2017 02:22:04 +0000

-----Original Message-----

>> there's no reason why the IID should be link-type dependent.
>
> I believe that is simply false unless you want to go back to the
> era of DIP switches with instructions to users to

Why so, Brian? I've already described one easy technique: the host can create IIDs of any length, based on an algorithm that we might just be debating for a long time, but fundamentally can be quite straightforward. And then the host chooses the correct IID to use for SLAAC, based on the RA it just received.

> an automated version, before SLAAC can start.

1. Host can create, in real time, IIDs of length 128 to 0 bits. To do this, for SLAAC, it SHOULD not be difficult IMO. One possibility: create random 128-bit value, then use a simple truncation algorithm to reduce the number of bits to the required value, at the appropriate time.

2. Host waits for RA.

3. Host determines prefix length after receiving RA, using the equation:

IID length = 128 - prefix length

4. Host generates 128-bit SLAAC address. If we started with the 128-bit random number, just truncate as needed.

5. Perform DAD, as already prescribed.

> Anway, all this is empty talk as long as the addressing
> architecture *requires* 64 bits rather than *recommending* 64
> bits.

True, but anything that *requires* something, based on a premise that has all but been discarded, doesn't hold much credibility anymore. The fallout from having deprecated that premise needs to be considered. A better future can result, as in this case (IMO). I think there's something in philosophy that addresses just this sort of situation. Where the general consensus of an argument can change 180 degrees, if more information on the underlying premises is presented.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 13 Jun 2017 02:30:37 +0000

I should add,

The IID length used by all SLAAC hosts on a link would be the same, because presumably, they all receive the same RAs. With the same RAs, their IIDs would have to come out to be the same length.

And, most of this change doesn't even apply to RFC 4862. For the most part, it applies to RFC 2464-bis. The main points of RFC 4862 remain the same.

Bert

---

From: "weigengyu" <[email-masked]>
Date: Tue, 13 Jun 2017 11:38:34 +0800

Hi,

The flexibility of IID length will bring some benefits.
But, is there any compatible issues to concern?

For example, if two networks are assigned with two length IID in office and 
at home,
the host, such as mobile phone, pad or note PC must adapt to the different 
IID lengths.

Is it practical or available nowadays to have such adaptabilities.
Is it a required to have a default IID length, eg. /64 for the local link?
Should the default length be supported?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Manfredi, Albert E
Sent: Tuesday, June 13, 2017 10:30 AM
To: Brian E Carpenter
Cc: 6man WG
Subject: RE: draft-bourbaki-6man-classless-ipv6-00

I should add,

The IID length used by all SLAAC hosts on a link would be the same, because 
presumably, they all receive the same RAs. With the same RAs, their IIDs 
would have to come out to be the same length.

And, most of this change doesn't even apply to RFC 4862. For the most part, 
it applies to RFC 2464-bis. The main points of RFC 4862 remain the same.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Jun 2017 17:09:03 +1200

On 13/06/2017 14:30, Manfredi, Albert E wrote:
> And, most of this change doesn't even apply to RFC 4862. 

It applies to the fact that the IID length must be known before forming
a LL address, and that it must be the same length as implied by a
*later* RA/PIO with A=1. So actually I think there is quite some
work to be done on RFC4862, and it isn't clear to me that it could
be backwards-compatible.

Also see Gengyu Wei's message: when devices roam, what happens if
the LL IID length for a given interface is supposed to change?
DIP switches again?

I don't think we're going to see a different IID length for any
link type that's already using 64 today; too many things would
have to change.

> For the most part, it applies to RFC 2464-bis. The main points of RFC 4862 remain the same.

It doesn't matter. If it isn't backwards compatible with deployed
code, IMHO it isn't going to happen on Ethernet or Wi-Fi.

   Brian

---

From: [email-masked]
Date: Tue, 13 Jun 2017 08:56:21 +0200

Brian,

> b) set the DIP switches on every device to select that length

That's a gross misrepresentation of what would happen.
For the LL we would agree on a fixed IID length of 64 (could be 118).
For addresses generated from PIO, the host will dynamically generate an IID of length 128 - prefix length.

> Otherwise LL addresses cannot be formed consistently on the

Trivial to solve.

> *requires* 64 bits rather than *recommending* 64 bits.

This is what _will_ happen as soon as we start chipping away at the boundary by changing the addressing architecture from requires to recommended.

The last stand for the 64 bit boundary will then be interoperability.

Ole

---

From: Ola Thoresen <[email-masked]>
Date: Tue, 13 Jun 2017 09:51:04 +0200

On 13. juni 2017 04:22, Manfredi, Albert E wrote:

> Why so, Brian? I've already described one easy technique: the host can 
> create IIDs of any length, based on an algorithm that we might just be 
> debating for a long time, but fundamentally can be quite 
> straightforward. And then the host chooses the correct IID to use for 
> SLAAC, based on the RA it just received.

Some people argue in the DNS "tussle" that it might be a problem if the 
host receives different DNS-info from eg. RAs and DHCP.
And now we are discussing if the host should create its LL prefix length 
based on a variable in the RAs?

What if multiple routers in a network announces different prefix 
lengths? This would cause MUCH greater problems than just getting an 
invalid DNS-server and would require much more work for the operators to 
keep consistent throughout a complex network.

I can foresee scenarios here, where one router is deployed and 
announcing prefix-lengths of /80 for its public prefix.  Then another 
router is added do the mix, that does not have the flexibility to change 
the prefix-length, so it will always use /64. Then the operator would 
either have to renumber the first prefix to /64 as well, or you would be 
stuck with two different prefixes announced in the RAs, and the host 
constantly regenerating its LL.
Or you would be forever forced to always use the longest prefix for all 
subnets, so as soon as I have deployed 2001:db8:1234:5678:9abc::/80 from 
one ISP, I can never use anything but a /80 on that link no matter what 
prefix size another ISP might give me.

Rgds.

Ola (T)

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 13 Jun 2017 17:05:49 +0900

> Could you explain why a 799 wouldn't satisfy bcp204?

You can't meet this recommendation with a /99:

   it is RECOMMENDED that the network
   give the host the ability to use new addresses without requiring
   explicit requests.  This can be achieved either by allowing the host
   to form new addresses autonomously (e.g., via SLAAC) or by providing
   the host with a dedicated /64 prefix.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 13 Jun 2017 17:18:20 +0900

> in something called "architecture".

Er, what? It's perfectly fine to say that the address is 128 bits long, and
that half of it is assigned to the network and half to the link.

> the current 4291bis text.

I don't see why we need new text for that. Any document that wants to use a
different value can simply update 4291.

> Nothing in any current implementation.

We have a popular implementation that only accepts 64-bit IID lengths in
certain cases. Are you proposing that our implementation change or not?

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 13 Jun 2017 17:29:45 +0900

On Tue, Jun 13, 2017 at 10:26 AM, Brian E Carpenter <
[email-masked]> wrote:

> back to us

You're not serious, are you?

The IESG sent back draft-ietf-6man-rfc4291bis because there was clear lack
of consensus, not for any architectural reason.

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 13 Jun 2017 11:03:18 +0200

On Sun, Jun 11, 2017 at 8:29 PM,  <[email-masked]> wrote:
<snip>
> If that's what we want. I believe we have to think quite hard about it and we need to consider the consequences quite hard.

what none so far (I might have missed it), have said anything about is
the policy side of IPv6 down the line if we start messing with the
64bit constant. Can anyone summarize what else is based on the
argument that 64bit is the LAN side of things?

whatever we do here will have wide scale effects. You can disagree or
disagree but why should let's say RIPE continue using /32 or /29's?
That argument is based on the amount of /48's and /56... which again
lead down to /64.

next thing we know is the routing table. Sure call me crazy, but why
should there be a /48 constant there when we've removed the constants
everywhere else?

-- 

Roger Jorgensen

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 13 Jun 2017 11:13:45 +0200

Fully agree, I know is not, up to a certain point, an IETF matter, but changes on this will impact in making wrong the text in many RIR documents, policies, etc. Do we really want to create that mess?

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Roger Jørgensen <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 13 de junio de 2017, 11:03
Para: Ole Troan <[email-masked]>, 6man WG <[email-masked]>
Asunto: Re: draft-bourbaki-6man-classless-ipv6-00

    

    
    -- 
    
    Roger Jorgensen

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 13 Jun 2017 13:33:48 +0200

Le 13/06/2017 à 04:22, Manfredi, Albert E a écrit :
> -----Original Message----- From: ipv6 [mailto:[email-masked]]
> On Behalf Of Brian E Carpenter
> 
>> era of DIP switches with instructions to users to a) choose an IID
>> length for their new subnet b) set the DIP switches on every device
>> to select that length c) then plug and play.
>> 
>> Otherwise LL addresses cannot be formed consistently on the whole
>> link.
> 
> Why so, Brian? I've already described one easy technique: the host
> can create IIDs of any length, based on an algorithm that we might
> just be debating for a long time, but fundamentally can be quite
>> RFC4862 I believe that is essentially what we would need, in an
>> automated version, before SLAAC can start.
> 
> 1. Host can create, in real time, IIDs of length 128 to 0 bits. To do
> this, for SLAAC, it SHOULD not be difficult IMO. One possibility:
> create random 128-bit value, then use a simple truncation algorithm
> to reduce the number of bits to the required value, at the
> appropriate time.
> 
> 2. Host waits for RA.
> 
> 4. Host generates 128-bit SLAAC address. If we started with the
> 128-bit random number, just truncate as needed.
> 

This method seems feasible to me.

It would allow WiFi terminals to connect to a smartphone that was
advertised a /64 on its LTE link and made a /65 for the WiFi interface.
  The RA would contain that /65 and the WiFi terminal would make an IID
of length 63.

This same WiFi terminal is backwards compatible: it could also connect
to other WiFi networks where the RA has a prefix /64.

Alex

> True, but anything that *requires* something, based on a premise that
> has all but been discarded, doesn't hold much credibility anymore.
> The fallout from having deprecated that premise needs to be
> considered. A better future can result, as in this case (IMO). I
> think there's something in philosophy that addresses just this sort
> of situation. Where the general consensus of an argument can change
> 180 degrees, if more information on the underlying premises is
> presented.
> 
> Bert
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 13 Jun 2017 13:34:38 +0200

Le 13/06/2017 à 05:38, weigengyu a écrit :
> 
> Hi,
> 
> The flexibility of IID length will bring some benefits. But, is there
> any compatible issues to concern?
> 
> For example, if two networks are assigned with two length IID in
> office and at home, the host, such as mobile phone, pad or note PC
> must adapt to the different IID lengths.

It should work.

Alex

> 
> Is it practical or available nowadays to have such adaptabilities. Is
> it a required to have a default IID length, eg. /64 for the local
> link? Should the default length be supported?
> 
> 
> Regards,
> 
> Gengyu WEI Network Technology Center School of Computer Beijing
> University of Posts and Telecommunications -----原始邮件----- From:
> Manfredi, Albert E Sent: Tuesday, June 13, 2017 10:30 AM To: Brian E
> Carpenter Cc: 6man WG Subject: RE:
> draft-bourbaki-6man-classless-ipv6-00
> 
> 
> I should add,
> 
> The IID length used by all SLAAC hosts on a link would be the same, 
> because presumably, they all receive the same RAs. With the same RAs,
>  their IIDs would have to come out to be the same length.
> 
> And, most of this change doesn't even apply to RFC 4862. For the most
>  part, it applies to RFC 2464-bis. The main points of RFC 4862 remain
> the same.
> 
> Bert
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 13 Jun 2017 13:40:35 +0200

Le 13/06/2017 à 09:51, Ola Thoresen a écrit :
>> straightforward. And then the host chooses the correct IID to use 
>> for SLAAC, based on the RA it just received.
> 
> 
> Some people argue in the DNS "tussle" that it might be a problem if 
> the host receives different DNS-info from eg. RAs and DHCP. And now 
> we are discussing if the host should create its LL prefix length 
> lengths? This would cause MUCH greater problems

Please identify such a problem.

In my setting, I could put a /64 and a /65 PIOs in a same RA.

The kernel of the existing Host would self-configure an address out of
that /64 and ignore the /65.  The software-to-be-written in userspace
would consider only  the /65 and form a second address.

What do you think breaks in this casE?

> than just getting an invalid DNS-server and would require much more 
> work for the operators to keep consistent throughout a complex 
> network.
> 
> announcing prefix-lengths of /80 for its public prefix.  Then
> another router is added do the mix, that does not have the
> flexibility to change the prefix-length, so it will always use /64.

What breaks in this case?  Who complains?  I think the existing Host
simply ignores the /65.

> Then the operator would either have to renumber the first prefix to 
> /64 as well, or you would be stuck with two different prefixes 
> announced in the RAs, and the host constantly regenerating its LL.

But the LLs have a prefix and plen that is distinct from the PIOs.  It
is fe80::/10.

> Or you would be forever forced to always use the longest prefix for 
> all subnets,

No.  Let's make that into a requirement: the longet-prefix applies for
forwarding but MUST NOT apply for address auto-configuration.

> so as soon as I have deployed 2001:db8:1234:5678:9abc::/80 from one
> ISP, I can never use anything but a /80 on that link no matter what

Right above.

Alex

---

From: Ola Thoresen <[email-masked]>
Date: Tue, 13 Jun 2017 15:57:50 +0200

> What do you think breaks in this casE?

I am not talking about that. I am talking about the idea of deducing the 
prefix length for _Link_Local_ addresses from the RAs.
If the link local address is randomly generated, which is the case in 
major OSes today, there is no way to ensure that the LL you created for 
one > /64 prefix matches the LL of a second router which also announces 
a prefix > /64 on the same link.
Link local needs to be /64 to ensure that you can reach all possible 
routers on the link - unless you are going to add multiple LL addresses 
to an interface as well.
But then we are suddenly facing other potential issues, so I a not sure 
that is a path we want to go...

>> work for the operators to keep consistent throughout a complex network.
>>

What /65?

The user complains, because the LL-address generated after receiving a 
RA from router B might make router A unavailable.

1) Router A announces a /80
2) Host generates an LL: fe80::AAAA:1234:abcd:4321/80
3) Router B announces a /64
4) Host generates an LL: fe80::B000:1234:abcd:4321/64 to match the 
prefix length of the new RA

Since that /64 does not match the /80 from router A, router A is no 
longer able to talk to the Link Local address of the Host.

But just for arguments sake.  Let the Host keep the address, but just 
change the prefix length...

4) Host changes its LL-prefix length to: fe80::AAAA:1234:abcd:4321/64 to 
match the prefix length of the new RA

Then router C comes along and also wants to play, but using the prefix 
fe80::CCCC:0:0:0/80 for its link local network.
Now, router A and C can not talk to each other, and the host can not 
talk to router C

Or even worse

Router D is added, with a /60 prefix length: fe80:0:0:D0::/60 - Now, the 
Host MUST change its prefix to talk to the new router, but that will 
make all the other routers unavailable.

In a dynamic network, with more than one router, you simply must have 
the same prefix length for all link local addresses, and just keeping it 
a /64 is much easier than trying to create a new algorithm to solve all 
potential pitfalls of using different prefix lengths for Link Local.

Rgds.

Ola Thoresen

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 13 Jun 2017 16:03:05 +0200

> That argument is based on the amount of /48's and /56... which again

Is RIPE agreeing that a cellular operator allocates a _single_ /64 per 
end-user?  Does RIPE understand the wide scale negative effects of such 
an agreement?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 13 Jun 2017 16:29:34 +0200

> prefix length for _Link_Local_ addresses from the RAs.

I see, that's why.

I was talking about PIOs for GUAs or ULAs, not for LLs.

> longer able to talk to the Link Local address of the Host.

I am not sure what you meant by "router A not able to talk to Host"?

I think you meant rather that Host is not able to send packets to Router 
A? (because Router A does not see the /64 of Router B).

If so (Host not able to send packets to Router A) then I think this 
might be a typical problem of source address selection.  This is 
independent of the address being of LL kind.

> make all the other routers unavailable.

Well, if the plen is made variable in an RFC it does not mean that 
people will add buttons to their computers and play them daily like 
tuning an FM radio.  But if they do, it's at their risk :-)

> potential pitfalls of using different prefix lengths for Link Local.

Err... I tend to agree.  But I think too that in a dynamic network 
computers may agree somehow dynamically on a plen to use.
An example of it is a seed in the SLAAC RFC which says that a router may 
interpret a prefix of another router, but left unsepcified.  Another 
seed is the agreement Home Agents establish when exchanging router 
advertisements, or BGP routers, or VRRP, or others.

I also tend to think that it may be easier to leave fe80::/10 (not 
fe80::/64) as a constant and not put it in RA.  But maybe we can look at 
it closer.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Tue, 13 Jun 2017 09:39:57 -0700

At Tue, 13 Jun 2017 13:26:59 +1200,

> removed by RFC4291, which IMHO is a bad message to send to the future.

I don't get the "which is removed by RFC4291" part.  Are you saying
that the "architectural flexibility" existed with RFC3513 but was
removed with RFC4291?  RFC3513 already had this text:

   For all unicast addresses, except those that start with binary value
   000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

Even RFC2373 had this:

      (2) The format prefixes 001 through 111, except for Multicast
          Addresses (1111 1111), are all required to have to have 64-bit
          interface identifiers in EUI-64 format.  See section 2.5.1 for
          definitions.

If I understand the "architectural flexibility" correctly, that
flexibility was already removed by RFC2373.  We were aware that the
constraint in the addressing architecture can cause nasty issues in
terms of the assumption of SLAAC (IID length is defined by link-type
doc) at the time of rfc2462bis discussions but intentionally left it
that way.  Of course, we can still revisit the decision at that time,
but I don't think it wise to do so in the context of rfc4291bis (see
also below).

In any case,

> back to us, and the main reason I signed on to draft-bourbaki-6man-classless-ipv6

I don't think it's the reason why rfc4291bis was sent back.  As far as
I can see it was largely due to disagreement based on
misunderstanding:

- some people conflated on-link prefixes and subnet prefixes (where
  the latter is the prefix that is followed by IID in the addressing
  architecture) and objected to keeping the length of the latter to be
  64 bits for most unicast addresses, while what they really wanted is
  variable-length on-link prefixes and they already have them.
- some other people wanted to keep the length of subnet prefixes to be
  64 bits.  but perhaps those people interpreted the objection from
  the first group as an objection to keeping the subnet prefix length,
  and fired back at it.

If the main goal for draft-bourbaki-6man-classless-ipv6 is to resolve
this gridlock so we can move forward with rfc4291bis, the resolution
is IMO quite simple: just to clarify the main misunderstanding.  No
architectural or protocol change is necessary:
https://www.ietf.org/mail-archive/web/ipv6/current/msg27679.html

Now, we are seeing a third group:

- yet some other people do not think keeping the subnet prefix length
  to be 64 bits (for most unicast addresses) does not make sense at
  all and argue for loosening it.

There are some variations of this group.  Reintroducing the
"architectural flexibility" (by making the subnet prefix/IID length
only dependent on link-type specs) could be considered one of them.
Some other people even suggest making it independent from the
link-type and leaving it to host/operator's choice.

We can discuss this proposal, but IMO this should be deferred as
post-rfc4291bis fodder.  I expect this will be a very controversial
discussion that will take quite long time (at least the second group
of people will fiercely fight against it), and there are currently
very few (if not no) implementations of the most flexible behavior
(i.e., making IID length fully variable) so it won't be compatible
with the scope of rfc4291bis.

--
JINMEI, Tatuya

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 13 Jun 2017 18:31:55 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ola Thoresen

> I am talking about the idea of deducing the prefix length for
> _Link_Local_ addresses from the RAs. If the link local address is
> randomly generated, which is the case in major OSes today, there is
> no way to ensure that the LL you created for one > /64 prefix
> matches the LL of a second router which also announces a prefix >
> /64 on the same link.

If two routers on a link offer prefixes of the same length to a given host, then the simple truncation algorithm I alluded to would generate the same IID to be used in both cases. For instance, "truncate the upper N bits of that random 128-bit value," where N is the prefix length.

If those two routers offered different prefix lengths, then clearly the IIDs used would have to be of different lengths. Is there a problem? I don’t see a problem. You should be able to have multiple addresses assigned to an interface with different lengths of prefix and IID, with no problem.

> routers on the link - unless you are going to add multiple LL
> addresses to an interface as well.

I don’t get that. If you start with the premise that all IIDs are to be 64 bits wide, THEN you can create a simple rule that the LLA IID and any SLAAC IID will end up being identical. But there's no other reason to assume that this is a requirement. It just follows as a consequence of that initial premise, which was based on the idea of EUI-64.

Leaving aside SLAAC itself, IPv4 is perfectly capable of dealing with multiple IP addresses assigned to an interface, with a different address mask per address. This creates no problems, in my experience.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 13 Jun 2017 18:46:58 +0000

-----Original Message-----

> Also see Gengyu Wei's message: when devices roam, what happens
> if the LL IID length for a given interface is supposed to change?
> DIP switches again?

Yes, the IID length would change, but this can easily be without use of DIP switches. It changes dynamically, with a new prefix length offered in the RA.

> It doesn't matter. If it isn't backwards compatible with
> deployed code, IMHO it isn't going to happen on Ethernet or
> Wi-Fi.

I remember first setting up my workstation, at work, for DHCP, as a guinea pig for the rest of the office. No problem. All the other hosts continued to work just fine. This would be backward compatible, in the sense that existing hosts would only be able to use 64-bit prefix lengths in RAs, to configure SLAAC. No problem. You can either continue to offer a 64-bit prefix length, for legacy hosts to use SLAAC, or you can stop offering 64-bit IIDs, and legacy hosts would be unable to configure SLAAC addresses.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 13 Jun 2017 19:35:41 +0000

In case I wasn't clear in this reply:

-----Original Message-----

> if the LL IID length for a given interface is supposed to change?

Yes, the IID length would change *for generating a SLAAC address*, but this can easily be without use of DIP switches. It changes dynamically, with a new prefix length offered in the RA.

The link local address of that interface does not need to change, of course. The link local address can continue to have its 64-bit IID. It would just no longer be the case that the IID of the LLA, and the IID of the SLAAC address, would necessarily be identical. Although depending how IIDs are generated, you might end up with the lower bits of the IID being identical.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Jun 2017 08:28:49 +1200

I'm replying selectively in this thread to avoid repetition. So:

> that half of it is assigned to the network and half to the link.

But it doesn't. It first states that the boundary between prefix
and IID is floating, and then states that it isn't.

> different value can simply update 4291.

Agreed, theoretically. But simply s/required/recommended/ in 4291bis
would be a much more elegant way of handling this.
 
> certain cases. Are you proposing that our implementation change or not?

No. But if some new link technology comes along for which there is a good
technical argument for, say, 60 bit interface identifiers, wouldn't you
want to accommodate it? (I have no idea what that argument might be.)

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Jun 2017 08:30:10 +1200

> of consensus, not for any architectural reason.

Yes, because there was clear lack of consensus *about this point*.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Jun 2017 08:34:57 +1200

Ola,
On 14/06/2017 01:57, Ola Thoresen wrote:
...
> prefix length for _Link_Local_ addresses from the RAs.

You cannot do that, because you must be capable of forming the LL address
before you receive any RA.

    Brian

---

From: [email-masked]
Date: Tue, 13 Jun 2017 22:44:04 +0200

Brian,

> want to accommodate it? (I have no idea what that argument might be.)

After we stopped recommending using link-layer addresses in the IID, I have a hard time seeing why a new data-link layer would have requirements for a particular length of the IID. Now if a link-layer is designed that requires to embed link-layer addresses, then sure, but that link-layer is then limited enough to be treated as a special case anyhow.

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Jun 2017 08:45:32 +1200

On 14/06/2017 04:39, 神明達哉 wrote:
> removed with RFC4291?  

No, that was not my intention. I'm sorry if it seemed otherwise.
We have always had this rather strange feature that the address
architecture describes a flexible boundary and then fixes it.

> RFC3513 already had this text:
> 

I largely agree with you. Making the boundary truly flexible is much 
more complex than some people think. All I personally want to see is
a version of 4291 that leaves some flexibility for further discussion,
and doesn't appear to forbid a number of existing operational practices.

I agree with you about the phrase "subnet prefix" in 4291. But I also
believe that making the unicast IID length "recommended" instead of
"required", although it seems like a small point, removes a lot
of the objections we heard during IETF Last Call.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 14 Jun 2017 16:49:34 +0900

> and IID is floating, and then states that it isn't.

There is no contradiction here. The value is floating, but *in the current
standards*, it is set to 64 for all unicast addresses except those in ::/3.
Should we change this? No, I don't think so. Can we change this? Yes,
absolutely - all we need to do is update 4291.

> would be a much more elegant way of handling this.

In the ivory tower, maybe. In the real world, simply changing from "is" to
"should" would be a result in immediate pressure to switch to longer
interface IIDs on currently-defined link types of interest (specifically,
Ethernet and wifi).

Remember that implementations are not built based on what the standard
recommends, but on a balance between what the standard requires and what
the operator desires. (If you doubt this view, I suggest reading your
co-authors' comments.) Also remember that most implementations already
support longer-than-64 bit prefixes today.

> want to accommodate it? (I have no idea what that argument might be.)

It's pretty clear that if an IPv6-over-foo document comes along that says
the IID length is 60 (and correspondingly updates 4291), then in order to
to support IPv6 over foo, either our implementation would need to change,
or the parts that rely on the 64-bit IID lengths would be disabled.

As you say, we don't know whether something like this will come along, and
I don't think we should preemptively update 4291 to accommodate this. It's
hard for me to think of something you can do with 60 bits but can't do with
64 bits.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Jun 2017 12:04:11 +0300

Hello, Brian,

> removed by RFC4291, which IMHO is a bad message to send to the future.

I think that RFC4291 should simply say that the RECOMENDED value is 64,
leaving the door open to other values. With RFC8064 in place, there's
not much reason for this value to be per-link. BUt that doesnt' mean
that a specific value should be mandated (MUST).

> forbids SLAAC from working in this case.

Exactly. SLAAC should be able to work with non-64 bits. Implementations
should be made made flexible with that in mind, no matter we keep 64 as
RECOMMENDED.

Agreed.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Jun 2017 12:05:44 +0300

> Maybe, but that isn't how RFC4862 is written today.

Well, that's why we're here, I guess. :-)

For instance, link-local only works with fe80::/64, no matter what the
spec says (i.e., shorter prefixes do not work).

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Jun 2017 12:09:11 +0300

Hi, Brian,

[....]
> *requires* 64 bits rather than *recommending* 64 bits.

* Mandate fe80::/64 for link-local
* RECOMMENDED /64 for subnets
* Make SLAAC implementations flexible so that they could do SLAAC if a
non-64 PIO is advertised.

(it's kind of weird that we even have flexibility wrt the prefix length
in parts of 4291, and in the PIO options themselves, and then mandate
one specific value)

Thanks,

---

From: Peter Hessler <[email-masked]>
Date: Wed, 14 Jun 2017 11:23:27 +0200

On 2017 Jun 14 (Wed) at 12:09:11 +0300 (+0300), Fernando Gont wrote:
:Hi, Brian,
:
:* Mandate fe80::/64 for link-local
:* RECOMMENDED /64 for subnets
:* Make SLAAC implementations flexible so that they could do SLAAC if a
:non-64 PIO is advertised.

As someone who is on the "/64 is the devil" side, I am perfectly happy
with the above.

-- 
I only touch base with reality on an as-needed basis!
		-- Royal Floyd Mengot (Klaus)

---

From: Erik Kline <[email-masked]>
Date: Wed, 14 Jun 2017 18:32:21 +0900

On 14 June 2017 at 18:09, Fernando Gont <[email-masked]> wrote:

> >>>    (i.e. I don't think a position where one wants to remove the 64 bit
> constant from 4291 and expect the 64 bit boundary

128-bit IPv4, yippee.

IPv6 NAT, I cannot wait.

I propose we also change the name of the working group while we're at it,
maybe v4-128-man.

---

From: [email-masked]
Date: Wed, 14 Jun 2017 11:35:23 +0200

Peter,

> As someone who is on the "/64 is the devil" side, I am perfectly happy

Reason being?

Ole

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Jun 2017 12:18:33 +0300

> This is what _will_ happen as soon as we start chipping away at the boundary by changing the addressing architecture from requires to recommended.

If changing such a value means a change in the architecture, then what
you have is not an architecture.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Jun 2017 12:28:53 +0300

On 06/14/2017 10:49 AM, Lorenzo Colitti wrote:
> On Wed, Jun 14, 2017 at 5:28 AM, Brian E Carpenter
[....]
> In the ivory tower, maybe. In the real world, simply changing from "is"
> to "should" would be a result in immediate pressure to switch to longer
> interface IIDs on currently-defined link types of interest
> (specifically, Ethernet and wifi).
> 

Even if one were to keep the "MUST be /64" for SLAAC, RFC4291 should be
clear that for non-slaac you should be free to use whatever you please
(whether manual or DHCPv6).

> It's pretty clear that if an IPv6-over-foo document comes along that
> says the IID length is 60 (and correspondingly updates 4291), then in
> order to to support IPv6 over foo, either our implementation would need
> to change, or the parts that rely on the 64-bit IID lengths would be
> disabled.

Why should the IID depend on ipv6-over-foo dcuments? We don't recommend
to embed MAC addresses in IIDs anymore.

> As you say, we don't know whether something like this will come along,
> and I don't think we should preemptively update 4291 to accommodate
> this. It's hard for me to think of something you can do with 60 bits but
> can't do with 64 bits.

Then.. why do you want to force 64? :-)

---

From: Peter Hessler <[email-masked]>
Date: Wed, 14 Jun 2017 11:40:34 +0200

On 2017 Jun 14 (Wed) at 11:35:23 +0200 (+0200), [email-masked] wrote:
:Peter,
:
:> :* Mandate fe80::/64 for link-local
:> :* RECOMMENDED /64 for subnets
:> :* Make SLAAC implementations flexible so that they could do SLAAC if a
:> :non-64 PIO is advertised.
:> 
:> As someone who is on the "/64 is the devil" side, I am perfectly happy
:> with the above.
:
:Reason being?
:
:Ole

link-local simply doesn't matter.  since it is on the link, we already
know the mac address and privacy won't help.  it's a silly place, with
silly rules. leave it at /64, so we don't have to fight with it.

leaving a RECOMMENDED for /64 subnets is fine.  forcing it to be a MUST
is not fine to me.  While the arguments in favour of /64 subnets are
valid, there are many differently valid reasons to have non-/64 subnets,
as mentioned many times in this (and other recent) threads.

As mentioned, there is a plen field in SLAAC advertisements, so we
should be able to use them.

-- 
I call them as I see them.  If I can't see them, I make them up.
		-- Biff Barf

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Jun 2017 12:41:50 +0300

On 06/14/2017 12:32 PM, Erik Kline wrote:
> 
> 
> On 14 June 2017 at 18:09, Fernando Gont <[email-masked]
>     >> On 06/11/2017 09:29 PM, [email-masked]
>     <mailto:[email-masked]> wrote:
>     [....]
>     >>>    (i.e. I don't think a position where one wants to remove the
>     64 bit constant from 4291 and expect the 64 bit boundary
> I propose we also change the name of the working group while we're at
> it, maybe v4-128-man.

If your opinion is that the only thing that separates IPv6 from IPv4
(other than the address length) is the 64-bit boundary, that's quite a
message. :-) Probably more controversial than changing the name of the wg.

---

From: Peter Hessler <[email-masked]>
Date: Wed, 14 Jun 2017 11:51:33 +0200

On 2017 Jun 14 (Wed) at 18:32:21 +0900 (+0900), Erik Kline wrote:
:IPv6 NAT, I cannot wait.
:

If you cannot wait, all versions of OpenBSD since 2003 have this
feature.

:I propose we also change the name of the working group while we're at it,
:maybe v4-128-man.

support

-- 
According to my best recollection, I don't remember.
		-- Vincent "Jimmy Blue Eyes" Alo

---

From: [email-masked]
Date: Wed, 14 Jun 2017 11:52:27 +0200

Peter,

> as mentioned many times in this (and other recent) threads.

Which arguments matter to you?
What _problem_ does changing the 64 bit boundary solve for _you_?

Ole

---

From: Peter Hessler <[email-masked]>
Date: Wed, 14 Jun 2017 11:59:10 +0200

On 2017 Jun 14 (Wed) at 11:52:27 +0200 (+0200), [email-masked] wrote:
:Peter,
:
:> leaving a RECOMMENDED for /64 subnets is fine.  forcing it to be a MUST
:> is not fine to me.  While the arguments in favour of /64 subnets are
:> valid, there are many differently valid reasons to have non-/64 subnets,
:> as mentioned many times in this (and other recent) threads.
:
:Which arguments matter to you?
:What _problem_ does changing the 64 bit boundary solve for _you_?
:
:Ole

The problem is wasting space (I acknowledge your arguments, and reject
them), uglyness of the addresses, and the fact that _my_ network is not
_your_ network.

I'm already running non-/64 subnets on my personal networks.  I'm also
running non-/64 subnets on my $work networks.

mandating /64 subnets in the _architectural specification_ is a bug,
period.

IPv4 got rid of classful subnets in 1993, IPv6 can join the last century
as well.

-- 
"A raccoon tangled with a 23,000 volt line today.  The results blacked
out 1400 homes and, of course, one raccoon."
		-- Steel City News

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 14 Jun 2017 19:12:44 +0900

> IPv4 got rid of classful subnets in 1993, IPv6 can join the last century

Brian (and everyone on this thread, really): QED.

Peter, thanks for writing this email so clearly. I think we now have a
clear example of what some operators will feel encouraged to do if we
change "is /64" to "should be /64". With the the current state of affairs,
such networks happen to work but are not guaranteed to interoperate, and
host implementations are not required to work on them. If we change the
standards to admit that subnets may be non-64 bits, there will be pressure
on implementations to conform.

Even if this sort of opinion were a minority opinion among network
operators, it is the nature of networking software development that host
implementations adapt to the lowest common denominator. Let's not do that
here. There is no technical reason to do so.

This is exactly the sort of scarcity thinking that the 64-bit boundary is
intended to avoid. Let's ensure that such limitations - which as Peter
says, belong to the last century - stay in the last century and do not
enter this one.

---

From: Peter Hessler <[email-masked]>
Date: Wed, 14 Jun 2017 12:19:02 +0200

On 2017 Jun 14 (Wed) at 19:12:44 +0900 (+0900), Lorenzo Colitti wrote:
:On Wed, Jun 14, 2017 at 6:59 PM, Peter Hessler <[email-masked]> wrote:
:> mandating /64 subnets in the _architectural specification_ is a bug,
:> period.
:>
:> IPv4 got rid of classful subnets in 1993, IPv6 can join the last century
:> as well.
:>
:This is exactly the sort of scarcity thinking that the 64-bit boundary is
:intended to avoid. Let's ensure that such limitations - which as Peter
:says, belong to the last century - stay in the last century and do not
:enter this one.

Anyone who thinks my statements encourage the /64 boundary is clearly
delusional.

The "last century" comment was about having artificial limitations,
such as /64.  Not about scarcity.

-- 
The bigger the theory the better.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 14 Jun 2017 23:06:49 +1000

> IPv4 got rid of classful subnets in 1993, IPv6 can join the last century

We got rid of classful subnets in 1993 *because* there were not
enough subnets to go around with them.  We didn't get rid of them
because as a concept they were bad.

Do you say that 18446744073709551616 subnets is too few to go
around?

2^64 address would have been enough to support the world using
variable length subnets.  IPng evaluated this and decided that it
was not a good idea as variable length subnets really are too
complicated.  Instead IPng went initially with 128 bit addresses
and, initially, /80 subnets so that we didn't have to deal with
variable sized subnets.  This was later changed to /64 bit subnets
to handle 64 bit mac addresses.

Mark

---

From: [email-masked]
Date: Wed, 14 Jun 2017 15:20:37 +0200 (CEST)

> to handle 64 bit mac addresses.

But since IPv6 *forwarding* is still based on longest prefix match,
plenty of people will need to learn the subtleties of how IPv6 is
*both* variable length *and* fixed size, at the same time. I don't
exactly have high hopes here...

Steinar Haug, AS2116

---

From: Erik Kline <[email-masked]>
Date: Wed, 14 Jun 2017 22:22:46 +0900

> to handle 64 bit mac addresses.

Thank you.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 14 Jun 2017 17:36:38 +0000

-----Original Message-----

> What _problem_ does changing the 64 bit boundary solve for _you_?

A category of problems, such as creating hotspots with smartphones that have been allocated a single /64. A real-world situation, in which there's no conceivable reason to have to go hat in hand to service provider, asking for more /64s. And in fact, from an operator's point of view, would not a user asking for more /64s be a bigger pain than a user subnetting his own /64, with no consequence at all to the operator?

I do acknowledge the "race to the bottom" potential. Then again, being overly stingy with /64s amounts to the same thing. Operators can make things bad, no matter what solution you adopt. Allowing the boundary to move gives users and app designers more flexibility and independence. For some players, that's a good thing.

Plus, I oppose the idea of artificially declaring that a fixed IID length is associated with each link type. This is a legacy notion, driven by rationales no longer valid. It's an unnecessary constraint. Or if stated, add a historical note as to why you have stated it.

If part of what makes IPv6 wonderful is SLAAC, then I don't think it's wise to cripple non-/64 solutions by artificially mandating that SLAAC be only possible with /64s. The smartphone hotspot example is one in which a non-/64 SLAAC would work great. And there's simply no reason to state that SLAAC can only work with /64s. It's not true!

Using RECOMMENDED for /64s? IMO, that RECOMMENDED would only apply to operators. It should be RECOMMENDED that ISPs not hand out /128s, or other overly long prefixes. I would almost rather use the word "typical." The "typical" prefix at the "operator to user boundary" may be /64 (or /56 perhaps). But app designers and users? No, there should be no such recommendations.

Bert

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 14 Jun 2017 19:51:37 +0200

I just don’t see the need for that.

3G/LTE operators providing broadband services to CPEs, have ways (dedicated provisioning or DHCPv6-PD), to receive a /48. I’ve used that.

So why not using the same for a cellular phone that may require instead of /64 a /56?

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de "Manfredi, Albert E" <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 14 de junio de 2017, 19:36
Para: "[email-masked]" <[email-masked]>
CC: 6man WG <[email-masked]>
Asunto: RE: draft-bourbaki-6man-classless-ipv6-00

    -----Original Message-----

    

    
    
    Bert

---

From: james woodyatt <[email-masked]>
Date: Wed, 14 Jun 2017 11:09:58 -0700

On Jun 14, 2017, at 10:36, Manfredi, Albert E <[email-masked]> wrote:
> A category of problems, such as creating hotspots with smartphones that have been allocated a single /64. A real-world situation, in which there's no conceivable reason to have to go hat in hand to service provider, asking for more /64s. […]

This category of problem is about connecting *routers* (not hosts) to the Internet via RFC 7278.

If all you’re connecting at the hotspot are hosts, then why would you need more than one subnet? And if you need more than one subnet— for some premium mobile hotspot thingie I guess— why not use more than one UE?

"What is the killer app for connecting *routers* to the Internet using a /64 subnet sharing scheme?” I ask, bearing in mind that you can’t be talking about 6LBR, because RFC 4944 fixes the subnet prefix length at 64 bits for all 6LO-over-link specifications. And why isn’t simply using IPv6/NAT the simpler and more straightforward solution to your category of problems?

Shorter james: I’m not ready to believe you have any problems in this category. Please provide a clear example.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 14 Jun 2017 18:53:44 +0000

> to the Internet via RFC 7278.

Or hosts which operate like routers?

> If all you’re connecting at the hotspot are hosts, then why would you
> need more than one subnet?

My smartphone is assigned a single /64. It becomes a WiFi hotspot. So, de minimis, it creates a /65, for its WiFi interface, which any number of local WiFi users can use. Why not allow SLAAC for these WiFi users? And, why should we not allow, trivially, more flexibility? We now have these "whole home WiFi" systems. Why should that smartphone's /64 not be capable of supporting two or three local WiFi hotspots?

Point being, all of this can be done with absolutely no consequences to the service provider, other than potentially some extra traffic volume on that one /64 facing the operator. But only if that 64-bit boundary is not fixed.

> And if you need more than one subnet— for some premium mobile hotspot
> thingie I guess— why not use more than one UE?

Of course you can use multiple phones with /64s, if that's what you're asking?  But not without going hat in hand to the operator.

With IoT, example in cars, or in homes, no one can tell how many different subnets will make sense. If a home router is assigned a /64, it should be able to use that one /64 effectively, without constantly having to ask for more? And SLAAC should be available, for inside the home. Why not? Either that, or for sure, you will see NAT used with IPv6.

Summary: I keep seeing people saying that they don’t want to see NAT used with IPv6. In the next sentence, they say they want a fixed boundary at /64. The only way the two ideas can be compatible is if we have a prefix police that mandates some arbitrary max prefix length to be handed out, by operators, like /48. But operators keep saying no way, and they hand out /64s. Rock, hard place. (And, not to be ignored, then there's the hype of this limitless address space offered by 128-bit addresses, as if it's actually usable.)

Bert

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Jun 2017 10:09:42 +1000

In message <[email-masked]>, "Manfredi, Albert E" writes:
> From: ipv6 mailto:[email-masked] On Behalf Of james woodyatt
>
> > If all youre connecting at the hotspot are hosts, then why would you
> My smartphone is assigned a single /64. It becomes a WiFi hotspot. So, de
> minimis, it creates a /65, for its WiFi interface, which any number of
> local WiFi users can use. Why not allow SLAAC for these WiFi users? And,
> why should we not allow, trivially, more flexibility? We now have these
> "whole home WiFi" systems. Why should that smartphone's /64 not be
> capable of supporting two or three local WiFi hotspots?
>
> Point being, all of this can be done with absolutely no consequences to
> the service provider, other than potentially some extra traffic volume on
> that one /64 facing the operator. But only if that 64-bit boundary is not
> fixed.

Operators that only give you a single /64 have already STOLEN 65535
subnets from you.  The architecture document say to give each site
a /48.  Addresses are handed to ISP's in the basis of /48's being
handed out to customers (you don't need to justify the space beyond
saying you are giving out /48s).  It doesn't cost more to route /48
than it does a /64.  These is less than a cent difference per
customer to get a /48 vs a /64 from the RIRs.  A cell phone is a
site border router the moment it turns on tethering.

> > And if you need more than one subnet for some premium mobile hotspot
> > thingie I guess why not use more than one UE?
>
> Of course you can use multiple phones with /64s, if that's what you're
> asking?  But not without going hat in hand to the operator.
>
> With IoT, example in cars, or in homes, no one can tell how many
> different subnets will make sense. If a home router is assigned a /64, it
> should be able to use that one /64 effectively, without constantly having
> to ask for more? And SLAAC should be available, for inside the home. Why
> not? Either that, or for sure, you will see NAT used with IPv6.
>
> Summary: I keep seeing people saying that they dont want to see NAT used
> with IPv6. In the next sentence, they say they want a fixed boundary at
> /64. The only way the two ideas can be compatible is if we have a prefix
> police that mandates some arbitrary max prefix length to be handed out,
> by operators, like /48. But operators keep saying no way, and they hand
> out /64s. Rock, hard place. (And, not to be ignored, then there's the
> hype of this limitless address space offered by 128-bit addresses, as if
> it's actually usable.)

More it is the MBA that thinks saving a couple of dollars on RIR
fees by only requesting just enough space to support a /64 per
customer is a good idea without looking at the entire picture.  Yes,
it adds up when there are millions of customers.  Charging 5 cents
extra per month would cover the additional costs many times over.

---

From: Ca By <[email-masked]>
Date: Thu, 15 Jun 2017 00:16:34 +0000

> extra per month would cover the additional costs many times over.

That MBA does not exist.  I have never seen RIR fees be a factor in subnet
size for ipv6.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 15 Jun 2017 10:00:12 +0900

On Thu, Jun 15, 2017 at 2:36 AM, Manfredi, Albert E <
[email-masked]> wrote:

> A category of problems, such as creating hotspots with smartphones that
> have been allocated a single /64.

That works today on all major smartphone OSes. And the situation is
actually the opposite: the only reason it works today is that phones
*already had* a /64 instead of a /128.

If part of what makes IPv6 wonderful is SLAAC, then I don't think it's wise
> to cripple non-/64 solutions by artificially mandating that SLAAC be only
> possible with /64s. The smartphone hotspot example is one in which a
> non-/64 SLAAC would work great. And there's simply no reason to state that
> SLAAC can only work with /64s. It's not true!
>

SLAAC doesn't work unless the network provides enough address space to make
collisions vanishingly unlikely.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Jun 2017 08:18:00 +0200

Le 15/06/2017 à 03:00, Lorenzo Colitti a écrit :
> On Thu, Jun 15, 2017 at 2:36 AM, Manfredi, Albert E 
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> -----Original Message----- From: ipv6 [mailto:[email-masked] 
> <mailto:[email-masked]>] On Behalf Of [email-masked] 
> <mailto:[email-masked]>
> 
> A category of problems, such as creating hotspots with smartphones 
> that have been allocated a single /64.
> 
> 
> That works today on all major smartphone OSes.

If this refers to '64share' - that's an INFORMATIONAL way of of working. 
  It has drawbacks.

If OS means OS distribution - that's that particular distribution's 
advantage, or inconvenient.

An OS like linux can be distributed as Android (run the non-scalable 
64share, avoid DHCP-PD) or can be distributed as Legato (dont run 
64share and run the scalable DHCP-PD).

Please be precise with respect to 'OS'.

> And the situation is actually the opposite: the only reason it works
> today is that phones *already had* a /64 instead of a /128.

They may have it, in a way.

So, if that category of problems is not sufficient, a similar  category 
of problems is other major IoT or M2M devices that run other major OS 
distribution than smartphones.

In the automotive market these small routers are called for example 
on-board routers and road-side units.

Similar small routers are in the smart building and smart city markets.

These need to connect to cellular networks and offer connectivity to 
more other devices than a smartphone does.

Alex

> If part of what makes IPv6 wonderful is SLAAC, then I don't think 
> it's wise to cripple non-/64 solutions by artificially mandating that
> SLAAC be only possible with /64s. The smartphone hotspot example is
> one in which a non-/64 SLAAC would work great. And there's simply no
> reason to state that SLAAC can only work with /64s. It's not true!
> 
> 
> SLAAC doesn't work unless the network provides enough address space
> to make collisions vanishingly unlikely.
> 
>

---

From: Erik Kline <[email-masked]>
Date: Thu, 15 Jun 2017 15:25:13 +0900

On 15 June 2017 at 15:18, Alexandre Petrescu <[email-masked]>
wrote:

>> [email-masked] <mailto:[email-masked]>>
>> wrote:
>>

I think we should consider promoting 64share from informational to proposed
standard.  We have a not inconsiderable amount of experience doing IPv6
tethering with it at this point.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 15 Jun 2017 15:26:36 +0900

On Thu, Jun 15, 2017 at 3:18 PM, Alexandre Petrescu <
[email-masked]> wrote:

> 64share, avoid DHCP-PD) or can be distributed as Legato (dont run 64share
> and run the scalable DHCP-PD).
>

That's why I said all "major" smartphone OSes.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 15 Jun 2017 11:20:19 +0200

>collisions vanishingly unlikely.

Indeed. So any RFC that makes smaller pseudo random IIDs possible has to
have at least a section that analyses collision probabilities. And set
a lower limit that is generally safe.

Just leaving it to an operator to figure out that a /112 prefix will
sometimes lead to an IoT device failing due to an address collision is
extremely poor protocol design.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Jun 2017 12:46:06 +0200

Le 15/06/2017 à 08:25, Erik Kline a écrit :
> 
> 
> On 15 June 2017 at 15:18, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         wrote:
> 
>         [mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>]
>         On Behalf Of [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>
> 
>         A category of problems, such as creating hotspots with
>         smartphones that have been allocated a single /64.
> 
> 
>     If this refers to '64share' - that's an INFORMATIONAL way of of
>     working.  It has drawbacks.
> 
> 
> I think we should consider promoting 64share from informational to 
> proposed standard.  We have a not inconsiderable amount of experience 
> doing IPv6 tethering with it at this point.

I think that promotion will not work, because despite large experience 
it still does not scale to more.

On the contrary, I think Android and Apple IOS backers should promote 
DHCP-PD.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 15 Jun 2017 21:43:35 +0900

> On the contrary, I think Android and Apple IOS backers should promote

Are there any mobile carriers that support this today, or plan to support
this in the future?

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Jun 2017 15:34:41 +0200

Le 15/06/2017 à 14:43, Lorenzo Colitti a écrit :
> On Thu, Jun 15, 2017 at 7:46 PM, Alexandre Petrescu 
>     On the contrary, I think Android and Apple IOS backers should
>     promote DHCP-PD.
> 
> 
> Are there any mobile carriers that support this today, or plan to 
> support this in the future?

Let's think about that and be back soon.

Alex

---

From: Warren Kumari <[email-masked]>
Date: Thu, 15 Jun 2017 13:04:18 -0400

On Thu, Jun 15, 2017 at 5:20 AM, Philip Homburg
<[email-masked]> wrote:
> have at least a section that analyses collision probabilities.

So, a couple of years ago I was doing some work with Juan Carlos and
Dan Harkins in the IEEE on MAC Randomization (basically randomizing
your (WiFi) MAC address to improve privacy / thwart pervasive
monitors).

There was some discussion on how many bits you would need to randomize
to make it unlikely that multiple machines will independently choose
the same address. I argued that if you randomize 24 bits, and have a
stadium of ~2000 people, you will basically never get a collision.
Dan disagreed, and so, in a fit of pique, I wrote an App Engine app to
prove him wrong -- and achieved exactly the opposite. This is a
birthday paradox problem, and you will get a collision once every ~9
times.

I've just updated my little app and put it here:
https://ipv6-collision-probability.appspot.com/

It's interesting to play with the numbers and see how likely a
collision is, given a certain subnet length and number of hosts.

>  And set

Example: With a /112, and 100 hosts, you will have a collision every
~14 times...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 15 Jun 2017 17:14:41 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandre Petrescu

> So, if that category of problems is not sufficient, a similar
> category of problems is other major IoT or M2M devices that run
> other major OS distribution than smartphones.

Yes, I think this is the broader issue. The cellphone example is an easy way to illustrate the problem, and as far as I can tell, the available solutions treat the lower 64 bits as a flat address space exclusively. Which may be fine for the smartphone hotspot, but hardly fine as a scalable solution.

If nothing else, allowing for 48-bit IIDs should be a no brainer. The collision potential with SLAAC is every bit as low as it was with SLAAC-cum-EUI-64, and *in effect*, such a solution would restore those wasted upper 16 bits of EUI-64 to usefulness. It provides the same benefit as assigning /48s to every customer, but without the egregious waste of address space. And if IIDs get shorter, then DAD will detect collisions more often, but that doesn't have to end up in failure necessarily? Try, try again. Or use DHCP-PD.

I'm not so taken by the privacy benefits of an overly sparsely used block of 64 bits. Other, more address-space-efficient techniques can be used to achieve that goal, like very short address lifetimes.

Anyway, as I see it, such updates can be introduced gracefully, fully backward compatible. A host updated to generate IIDs of various lengths can obviously also generate 64-bit IIDs!

Bert

---

From: Job Snijders <[email-masked]>
Date: Thu, 15 Jun 2017 19:23:38 +0200

On Thu, Jun 15, 2017 at 01:04:18PM -0400, Warren Kumari wrote:
> On Thu, Jun 15, 2017 at 5:20 AM, Philip Homburg <[email-masked]> wrote:
> > Indeed. So any RFC that makes smaller pseudo random IIDs possible
> > has to have at least a section that analyses collision
> > probabilities.
> 

Hah, nice :)

> >  And set a lower limit that is generally safe.
> >
> > sometimes lead to an IoT device failing due to an address collision
> > is extremely poor protocol design.
> 

Luckily there are other methods of numbering things: manually, or
programmatically, or through DHCPv6. I believe there are more use cases
then IoT devices. SLAAC is not the only way of doing things.

Kind regards,

Job

---

From: Warren Kumari <[email-masked]>
Date: Thu, 15 Jun 2017 13:31:14 -0400

> then IoT devices. SLAAC is not the only way of doing things.

Yup, fully agree -- this isn't intended to support (or detract from)
SLAAC, DHCPv6, manual, unicorns, hippopotamuses or any other address
assignment solution, it's just a tool, like a hammer.

Just like with a hammer, you can wield it to justify your views :-P

W

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Jun 2017 13:36:51 +1200

> Brian (and everyone on this thread, really): QED.

QED indeed, if the proposition to be proved is that a rigid boundary
is not required.

> on implementations to conform.

I think that portability out of the box is a much stronger argument. Peter
has chosen to hand-craft his networks. Most people (99.99%) simply unwrap
their new device, ignore the "quick start" guide, and switch it on. There
is an enormous market incentive for that to work 100% of the time, which is
an enormous incentive to stick with /64.
 
> intended to avoid. 

Not to mention the late lamented /48 recommendation to ISPs. Again,
nobody is trying to sabotage /64 as the norm for SLAAC networks, and
nobody is trying to sabotage SLAAC as the norm for plug and play.

> Let's ensure that such limitations - which as Peter

I agree. But at the same time we need to be honest in our specs. RFC4291
does not describe the deployed architecture accurately, which is why
we have to fix it if we're serious about Internet Standard status.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 16 Jun 2017 13:39:43 +0900

On Fri, Jun 16, 2017 at 10:36 AM, Brian E Carpenter <
[email-masked]> wrote:

> has chosen to hand-craft his networks.

... and hand-crafting networks is precisely what network operators do. It
is, after all, their job.

> Most people (99.99%) simply unwrap

Your premise is correct but your conclusion is wrong. Yes, there is an
enormous incentive for things to work 100% of the time. But that does not
mean stick to /64. Quite the opposite - it means "work regardless of the
prefix length on the network". Before you disagree with me, observe the
fact that most implementations work on Peter's network, today, even though
Peter's network is in complete violation of RFC 4291.

> nobody is trying to sabotage SLAAC as the norm for plug and play.

I know that you're not *trying* to do that. I'm trying to make you realize
that by pushing for a non-fixed boundary you *are* doing it.

As for "nobody" - it's not true that nobody is trying to do it. If you read
Job and Peter's statements carefully, you'll see that they are.

> we have to fix it if we're serious about Internet Standard status.

That's not true for any value of "accurate" that is meaningful in the real
world. I'd argue that RFC 4291 (with the exception made in 6164), is
accurate for at least 99.9% of links on the public Internet.

Making it accurate for the remaining 0.1% is not worth removing the text in
the standard that stops operators like Peter being able to claim that hosts
should support addressing models that are bad for their users.

---

From: Job Snijders <[email-masked]>
Date: Fri, 16 Jun 2017 07:07:18 +0200

On Fri, Jun 16, 2017 at 01:39:43PM +0900, Lorenzo Colitti wrote:
> On Fri, Jun 16, 2017 at 10:36 AM, Brian E Carpenter <[email-masked]> wrote:
> > Most people (99.99%) simply unwrap their new device, ignore the
> > "quick start" guide, and switch it on. There is an enormous market
> > incentive for that to work 100% of the time, which is an enormous
> > incentive to stick with /64.
> 
> enormous incentive for things to work 100% of the time. But that does
> not mean stick to /64. Quite the opposite - it means "work regardless
> of the prefix length on the network". Before you disagree with me,
> observe the fact that most implementations work on Peter's network,
> today, even though Peter's network is in complete violation of RFC
> 4291.
> 
> I know that you're not *trying* to do that. I'm trying to make you
> realize that by pushing for a non-fixed boundary you *are* doing it.
> 
> As for "nobody" - it's not true that nobody is trying to do it. If you
> read Job and Peter's statements carefully, you'll see that they are.

That is quite the accusation.

> > I agree. But at the same time we need to be honest in our specs.
> > RFC4291 does not describe the deployed architecture accurately,
> > which is why we have to fix it if we're serious about Internet
> > Standard status.
> 
> That's not true for any value of "accurate" that is meaningful in the
> real world. I'd argue that RFC 4291 (with the exception made in 6164),
> is accurate for at least 99.9% of links on the public Internet.

Even if it is as low as 0.1%, has it ever occurred to you that that
small number might serve a majority of IPv6 users in non-trivial
matters? For example, their ability to reach each other? It is a shame
to see such blatant disregard for this group of IPv6 users.

I've shown before that 6164 accomodates some, but not all cases for both
historic and pragmatic reasons. 6164 does not solve all operational
challenges.

> Making it accurate for the remaining 0.1% is not worth removing the
> text in the standard that stops operators like Peter being able to
> claim that hosts should support addressing models that are bad for
> their users.

You realise that the above remarks come across as extremely judgemental?
Who do you think you are to know what is good for all groups of users?
I still simply argue that nobody can know what is needed in every
context in every situation, pretending otherwise would be folly.

It is painful to see you view operators as some kind of minority (a
nuisance even?), and as such they don't need or deserve to be
accommodated by standards.

Regards,

Job

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 16 Jun 2017 15:16:10 +0900

> That is quite the accusation.

I don't see any other interpretation of your statement "can expand the
routed network at the edges, in absence of PD" in these slides
<https://iepg.org/2017-03-27-ietf98/JobSnijders_IPv6_prefix_length_IEPG_Chicago_2017.pdf>.
Unless you mean that those extended networks are not going to be plug and
play.

> Who do you think you are to know what is good for all groups of users?

My apologies, I thought it was clear that I'm not talking about all users.
To clarify: I'm talking about users of general purpose client devices. My
statement that operators should not be able to claim that implementers of
those devices need to support addressing models that are bad for their
users. I stand by that statement. Right now those practices are not allowed
by the standards, and I'd like to keep it that way.

> accommodated by standards.

Networking standards do not accommodate people, they specify the behaviour
of networking devices. So let's focus on the technical needs.

>From a technical perspective, the main desire I've heard from operators so
far is that they would like to use non-/64 prefix lengths on router
interfaces. It's not necessary to change the 64-bit boundary for that to be
allowed. Saying that the limitation does not cover manually-configured
addresses would meet that need.

As I've said many, many times before - if there are other problems that
need to be solved, let's start from those and design solutions for them.
Saying (as the draft does) that the 64-bit boundary "is the last remnant of
IPv6 classful addressing" might conceivably be accurate, but it says
nothing about which problems, if any, it causes, and thus says nothing
about what solutions we need.

It's clear what solutions the draft authors think we need, but unless we
come to consensus on that solution, that's not useful.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 16 Jun 2017 14:44:22 +0200

Job,

I'm curious what use you have for SLAAC with prefixes longer than /64.

Using pseudo random IIDs for router interfaces seems like a complete
maintainance nightmare to me. Or are you talking about other infrastructure
devices?

The most contentious point in draft-bourbaki-6man-classless-ipv6-00 is that
it tries to change the IID length used for SLAAC. 

As far as I know, any type of address assignment that is not SLAAC already
supports arbitrary prefix lengths, and therefore is compatible with the
goal of this draft.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 16 Jun 2017 19:14:50 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Philip Homburg

> I'm curious what use you have for SLAAC with prefixes longer than /64.

By no means attempting to answer for Job, my answer is simple. SLAAC is a plug and play technique, and I see no reason why that plug and play technique cannot be applied to other than /64 networks. There's no reason to make non-/64 networks always an exception, only available for manual configuration, or even only available with this DHCP-PD that isn't much supported.

To expand a routed network at the edges easily, and allow subnetting in the expanded network, and allow plug and play operation in the expanded part, SLAAC should be one element of the solution. DHCP-PD recycles the same technique used in IPv4, and it's a good additional option, especially useful when the client addresses must be known to the network operator.

Given that variable length IID SLAAC is just not difficult to implement, in a graceful, backward-compatible manner, I can only conclude that opposition to it is opposition to allow for easily moving the 64-bit boundary.

> The most contentious point in draft-bourbaki-6man-classless-ipv6-00
> is that it tries to change the IID length used for SLAAC.

That should hardly be contentious, on technical grounds, because the problem is not difficult to solve. It might be contentious only tangentially, in the sense that it makes variable prefix lengths so easy to contend with?

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 17 Jun 2017 10:15:00 +1200

...
>> is that it tries to change the IID length used for SLAAC.

I find this allegation hard to reconcile with the following sentence
in the Recommendations section of the draft:

"But operationally we recommend,
barring strong considerations to the contrary, using 64-bits for
SLAAC..."

> That should hardly be contentious, on technical grounds, because the problem is not difficult to solve. 

Most problems can be solved as a "small matter of programming", but given
that the deployed base of IPv6, which assumes /64 for SLAAC, is now much
larger** than the whole Internet was when the /64 boundary was defined,
I really don't think that is going to happen for any existing technology.

This draft is not actually about *changing* /64. It's about setting the
the right balance between scenarios where /64 is appropriate and those
where it isn't, given that routing is already defined to handle any
prefix length.

> It might be contentious only tangentially, in the sense that it makes variable prefix lengths so easy to contend with?

I don't understand that sentence.

** I haven't worked out the ratio, but in any case it's apparent that
the operational IPv6 network is already much bigger than the IPv4
network was when CIDR & BGP4 were deployed in 1993. We'd be playing
with fire to change anything fundamental for the existing deployment.

   Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 16 Jun 2017 23:05:23 +0000

-----Original Message-----

> Most problems can be solved as a "small matter of programming",
> but given that the deployed base of IPv6, which assumes /64 for
> SLAAC, is now much larger** than the whole Internet was when the
> /64 boundary was defined, I really don't think that is going to
> happen for any existing technology.

Since you mention in your footnote CIDR deployment with IPv4, which was also what came to mind to me, I think that this non-64-bit-IID SLAAC should be easier to introduce than CIDR was. For one thing, routers already know how to route variable length prefixes with IPv6. But either way, these changes can happen, with software updates, as they have happened in the past.

I see this IID-agnostic SLAAC as being limited to a local subnet issue, which a truly-not-difficult software update to the local hosts can solve. Prefix length agnostic SLAAC can be switched on in a very well controlled manner, by the router, when the net admin determines that the attached hosts are ready, or enough of them are ready. Until such a time, all upgraded hosts continue to work just fine, with 64-bit IIDs.

I largely agree with this draft, really. But, for example:

   (SLAAC) [RFC4862],

I would say instead, even RFC 4862 can be modified, with minimal changes, to not impose such a restriction. That restriction was motivated by RFC 2464. The intent of RFC 2464 no longer applies. The rationale for a particular IID length, with IPv6 over Ethernet, IEEE 802.11, and most other link layers, therefore also no longer applies.

The recommendations of Section 4 are generally non-controversial (to me), although probably overly conservative.

>> It might be contentious only tangentially, in the sense that it
>> makes variable prefix lengths so easy to contend with?
>

Because SLAAC with variable IID lengths seems so straightforward to implement, I can only think that this is contentious because it makes moving that 64-bit boundary too easy? The boundary would be more difficult to change, if the only ways to do so required manual configuration of hosts.

Bert

---

From: Philip Homburg <[email-masked]>
Date: Sat, 17 Jun 2017 01:33:11 +0200

>barring strong considerations to the contrary, using 64-bits for

The way I understand the draft, it tries to make the IID length purely
a decision of the operator.

Operators are adviced to use 64 bits, but the draft tries to give operators
the freedom to advertise a /120 and have the host use an 8 bit IID.

For obvious reasons, Lorenzo is not happy with that. I'm not happy with
that either.

But what I find curious, is that as far as I know Job has no operational
need for SLAAC. Mostly likely, Randy doesn't have an operational need for
SLAAC either.

So why is this mixed in a single draft?

What prefix related issues are encoutered by people who operate core routers?
That's a discussion that should be easy to solve.

On the other hand, there seems to be very little consensus on how to
move forward with SLAAC.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 17 Jun 2017 12:00:39 +1200

> So why is this mixed in a single draft?

Because, I think, the word 'prefix' has three distinct aspects in
IPv6: a prefix used by a routing protocol, a prefix used by a
node to determine if another node is connected to the same link,
and a prefix used to construct the complete address of a node.
We have generally been a bit careless in distinguishing these
three aspects.

   Brian

---

From: David Farmer <[email-masked]>
Date: Fri, 16 Jun 2017 20:43:08 -0500

Sent from my iPhone

> On Jun 16, 2017, at 19:00, Brian E Carpenter <[email-masked]> wrote:
> 

Also, in the last two aspects of an IPv6 prefix, the part of the address leftover, the righthand side, can quite reasonably be referred to as an Interface Identifier (IID) in both cases. And, of those two aspects of IID, only the last one is currently defined to be 64 bits, the other can have any length from 0 to 128 but it Is 64 bit as well in most cases. 

This is all exasperated, by using the term subnet prefix in RFC4291 and it's predecessors, because in IPv4 the last to aspects of a IPv6 prefix, and the two aspects of IID, are bound together and called a subnet prefix, and in IPv6 those two aspects are supposed to be separate.

While I could support a variable length addressing prefix and IID that is no small change and is not something to be included in RFC4291bis, but clearly resolving the ambiguity of the three aspects of an IPv6 prefix and the two aspects of an IPv6 IID is required to move RFC4291bis forward to Internet Standard.

Thanks.

David Farmer

---

From: Mark Smith <[email-masked]>
Date: Sat, 17 Jun 2017 17:16:53 +1000

On 17 Jun. 2017 05:15, "Manfredi, Albert E" <[email-masked]>
wrote:

-----Original Message-----

> I'm curious what use you have for SLAAC with prefixes longer than /64.

By no means attempting to answer for Job, my answer is simple. SLAAC is a
plug and play technique, and I see no reason why that plug and play
technique cannot be applied to other than /64 networks. There's no reason
to make non-/64 networks always an exception, only available for manual
configuration, or even only available with this DHCP-PD that isn't much
supported.

To expand a routed network at the edges easily, and allow subnetting in the
expanded network, and allow plug and play operation in the expanded part,
SLAAC should be one element of the solution. DHCP-PD recycles the same
technique used in IPv4, and it's a good additional option, especially
useful when the client addresses must be known to the network operator.

* DHCPv6 does not record addresses in use on a link. It will not record
link local addresses or manually configured addresses. It is only recording
hosts that asked to acquire addresses via DHCP.

* You're overlooking the cost and service impact of renumbering to increase
the size of the subnet if it isn't large enough. That can be a large cost
and large impact if many hosts are involved. So large, I've seen people
avoid paying it when there were in the order of 1000 hosts involved on an
IPv4 network - the hosts were spread across 4 x /24s on the same Ethernet
segment.

Given that variable length IID SLAAC is just not difficult to implement, in
a graceful, backward-compatible manner, I can only conclude that opposition
to it is opposition to allow for easily moving the 64-bit boundary.

> is that it tries to change the IID length used for SLAAC.

That should hardly be contentious, on technical grounds, because the
problem is not difficult to solve. It might be contentious only
tangentially, in the sense that it makes variable prefix lengths so easy to
contend with?

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sat, 17 Jun 2017 23:09:20 +0000

From: Mark Smith [mailto:[email-masked]] 

> * DHCPv6 does not record addresses in use on a link. It will not
> record link local addresses or manually configured addresses. It
> is only recording hosts that asked to acquire addresses via DHCP.

Okay, like DHCPv4. But when the system admin needs stable addresses for hosts in the network, e.g. a peer-peer network that does not use a DNS, DHCPv6 PD is a good tool to have.

> * You're overlooking the cost and service impact of renumbering to
> increase the size of the subnet if it isn't large enough. That can
> be a large cost and large impact if many hosts are involved. So
> large, I've seen people avoid paying it when there were in the
> order of 1000 hosts involved on an IPv4 network - the hosts were
> spread across 4 x /24s on the same Ethernet segment.

Depends on the scenario. In my reality, expanding a network at the edges easily, without involving in any way the authority that allocates blocks of addresses, is quite valuable. A scheme that makes this difficult is instead a nuisance.

What's behind this debate, from my point of view, is a need for the same functionality offered by NAT in IPv4, but without incurring the penalties of using NAT. A fixed IID length of 64 bits, when /64s or maybe even /56s are what customers are given, is a bit like never having invented NAT for IPv4. It's limiting. I realize this view is not everyone's concern.

Bert

---

From: Mark Andrews <[email-masked]>
Date: Mon, 19 Jun 2017 09:47:28 +1000

In message <[email-masked]>, "M
anfredi, Albert E" writes:
> Okay, like DHCPv4. But when the system admin needs stable addresses for
> hosts in the network, e.g. a peer-peer network that does not use a DNS,
> DHCPv6 PD is a good tool to have.
> 
> Depends on the scenario. In my reality, expanding a network at the edges
> easily, without involving in any way the authority that allocates blocks
> of addresses, is quite valuable. A scheme that makes this difficult is
> instead a nuisance.
>
> What's behind this debate, from my point of view, is a need for the same
> functionality offered by NAT in IPv4, but without incurring the penalties
> of using NAT. A fixed IID length of 64 bits, when /64s or maybe even /56s
> are what customers are given, is a bit like never having invented NAT for
> IPv4. It's limiting. I realize this view is not everyone's concern.

Go complain to the ISP, really.  The IETF allocation scheme was a
/48 for every site and additional /48s if you needed them.  Thats
10's of thousands of /48's per person on the planet.  Thats 100 of
millions of subnets.  If your ISP isn't supplying you with a /48
and additional /48's if needed they are not doing their job.

Just because something is technically possible, can be made to work,
it doesn't mean that it is a good thing.  There a plenty of examples
of where it is a bad thing.

---

From: Erik Kline <[email-masked]>
Date: Tue, 20 Jun 2017 01:26:24 +0900

Agreed.

---

From: Job Snijders <[email-masked]>
Date: Mon, 19 Jun 2017 18:45:12 +0200

On Tue, Jun 20, 2017 at 01:26:24AM +0900, Erik Kline wrote:
> > addr-arch or RFC4862 because of this.  (draft-bourbaki-6man-
> > classless-ipv6-00 seems to be confused on this point, and I suspect
> > it increases the confusion and controversy in this whole thread).
> 
> Agreed.

Is there a document that states that IPv6 routers and hosts must support
on-link prefixes of all sizes? 

Kind regards,

Job

---

From: David Farmer <[email-masked]>
Date: Mon, 19 Jun 2017 12:14:14 -0500

>> confusion and controversy in this whole thread).

While I agree this is confused in draft-bourbaki-6man-classless-ipv6-00, I
believe the root of the confusion is the use of the term Subnet Prefix in
RFC4291 and it's predecessors.  Therefore, I can not agree that addr-arch
(RFC4291bis) doesn't need to be updated, the updated doesn't need to
fundamentally change anything, but it very much has to clarify this issue.
I think they way to do this is to remove the term subnet prefix when
related to IPv6 and only use it related to IPv4. Also add a discussion of
on-link prefixes.

Thanks

---

From: David Farmer <[email-masked]>
Date: Mon, 19 Jun 2017 12:16:21 -0500

> on-link prefixes of all sizes?

I believe this is what RFC7608 says, except I don't think it uses the term
on-link, which it probably should.

Thanks.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 19 Jun 2017 10:25:36 -0700

At Mon, 19 Jun 2017 18:45:12 +0200,

> on-link prefixes of all sizes? 

In my own draft draft-jinmei-6man-prefix-clarify-00 I tried to explain
that's at least the case for configuring on-link prefixes on a host
advertised via Router Advertisements.  RFC4861, or any other RFCs that
I know of, doesn't have an exact phrase like "a host MUST support
on-link prefixes of all lengths", but I believe I provided sufficient
evidences that that's the reasonable interpretation of the current
specification and it matches what's currently implemented.

For manual configuration on hosts and routers, I don't think there is
an RFC that has this exact phrase or equally strong evidence as the
host autoconfiguration case.  But at least for host implementations I
believe it's quite natural to extend that interpretation to manual
configuration.  And same for routers - after all, it's a router to
advertise an on-link prefix of arbitrary lengths via RA PIO.  So, it
shouldn't be unreasonable to assume it should be able to use that
prefix for its own on-link determination.

And, perhaps more important in the context of
draft-bourbaki-6man-classless-ipv6-00, (as far as I know) no one,
even strong 64bit-IID advocates, disagrees on this interpretation.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Jun 2017 07:53:00 +1200

> even strong 64bit-IID advocates, disagrees on this interpretation.

I would say it is a completely separate issue that the draft simply
doesn't care about.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Jun 2017 08:00:58 +1200

> on-link, which it probably should.

Consistent terminology for the different uses of the word "prefix"
is emerging as a major problem in this debate.

I don't see any distinction in RFC7608 between the on-link prefix
and the prefix used for address assignment purposes such as SLAAC.
The distinction in 7608 is between an amalgam of those two and
the prefix used in routing protocols.

     Brian