Subject: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

From: The IESG <[email-masked]>
Date: Wed, 01 Feb 2017 15:51:01 -0800

The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'IP Version 6 Addressing Architecture'
  <draft-ietf-6man-rfc4291bis-07.txt> as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2017-03-01. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This specification defines the addressing architecture of the IP
   Version 6 (IPv6) protocol.  The document includes the IPv6 addressing
   model, text representations of IPv6 addresses, definition of IPv6
   unicast addresses, anycast addresses, and multicast addresses, and an
   IPv6 node's required addresses.

   This document obsoletes RFC 4291, "IP Version 6 Addressing
   Architecture".

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Feb 2017 05:41:13 -0300

Folks,

Some comments:

* Section 4 (Sec Cons) says:
"  IPv6 addresses can
   be created using interface identifiers constructed with unique stable
   tokens.  The addresses created in this manner can be used to track
   the movement of devices across the Internet."

here you meant "constant", rather than stable. Constant IIDs (as
resulting from embedding constant MAC addresses in the IID) allow for
tracking devices across the Internet. Stable IIDs (as resulting from
RFC7217) do not.

Thanks,
Fernando

On 02/01/2017 08:51 PM, The IESG wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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

---

From: David Farmer <[email-masked]>
Date: Mon, 13 Feb 2017 16:32:27 -0600

I have concerns with the following text;

   IPv6 unicast routing is based on prefixes of any valid length up to
   128 [BCP198].  For example, [RFC6164] standardises 127 bit prefixes
   on inter-router point-to-point links. However, the Interface ID of
   all unicast addresses, except those that start with the binary value
   000, is required to be 64 bits long.  The rationale for the 64 bit
   boundary in IPv6 addresses can be found in [RFC7421]

The third sentence seems to limit exceptions to 64 bit IIDs to exclusively
addresses that start with binary vale of 000.  There are at least two other
exceptions from standards track RFCs, that should be more clear accounted
for in this text.  First is [RFC6164] point-to-point links, as mentioned in
the previous sentence.  I think the clear intent of [RFC6164] is to allow
one(1) Bit IIDs for point to point-to-point links using any Global Unicast
Address, not just those that start with 000.  Second is, [RFC6052], which
updates [RFC4921] and seems to allow 32 bit IIDs or /96 prefixes for any
Global Unicast Address when used for IPv4/IPv6 translation, referred to as
""Network-Specific Prefix" unique to the organization deploying the address
translators," in section 2.2 of [RFC6052].

Thanks.

-- 
===============================================
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: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Feb 2017 11:53:51 +1300

At an earlier stage I suggested restricting the applicability
of the "However..." sentence to SLAAC [RFC4862]. A short way
of doing this would be

However, the Interface ID of unicast addresses used for
Stateless Address Autoconfiguration [RFC4862] is required
to be 64 bits long.

Regards
   Brian

---

From: David Farmer <[email-masked]>
Date: Mon, 13 Feb 2017 17:07:10 -0600

I'll bet it comes as no surprise that I find your suggestion the preferred
solution to the issue I raise.  However, there are a number of other ways
to solve this issue, less acceptable to me than the one you suggest, but
they maybe more acceptable to others.

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: Fred Baker <[email-masked]>
Date: Mon, 13 Feb 2017 15:41:43 -0800

> On Feb 13, 2017, at 2:53 PM, Brian E Carpenter <[email-masked]> wrote:
> 

To my understanding, that is exactly the case with SLAAC. One could use the algorithm with any number one chose, but the chosen number is 64. Restricting the limitation to algorithms that require such a limitation makes sense to me. Extending it from there to algorithms that have no such limitation doesn't.

---

From: David Farmer <[email-masked]>
Date: Tue, 14 Feb 2017 09:27:39 -0600

Actually, in addition to your text there still needs to be a recommendation
for 64 bit IIDs in all other cases.  64 bit IIDs are(and should remain) the
norm for IPv6, I do not want to change that.  But the current language say
IIDs are always 64 bit except when an address begins with binary 000,
leaving no room for any other exception.  And this is plainly incorrect, I
provided two clear exceptions that are already standardized.  Furthermore,
IIDs other than 64 bits are in operational use, with manual configuration
and DHCPv6.

So I'd suggest;

However, the Interface ID of unicast addresses used for
Stateless Address Autoconfiguration [RFC4862] is required
to be 64 bits long, in all other cases it is recommended to
be 64 bits long.

The other option is to enumerate all the exceptions, requiring the document
to be updated every time a new exception is standardized.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 14 Feb 2017 16:53:24 +0100

Agree, we shouldn’t change that. Must be 64 bits.

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de David Farmer <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 14 de febrero de 2017, 16:27
Para: Brian E Carpenter <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, 6man WG <[email-masked]>, IETF-Discussion Discussion <[email-masked]>
Asunto: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

    Actually, in addition to your text there still needs to be a recommendation for 64 bit IIDs in all other cases.  64 bit IIDs are(and should remain) the norm for IPv6, I do not want to change that.  But the current language say IIDs are always 64 bit except when an address begins with binary 000, leaving no room for any other exception.  And this is plainly incorrect, I provided two clear exceptions that are already standardized.  Furthermore, IIDs other than 64 bits are in operational use, with manual configuration and DHCPv6.  
    So I'd suggest;

    The other option is to enumerate all the exceptions, requiring the document to be updated every time a new exception is standardized.
    
    On Mon, Feb 13, 2017 at 4:53 PM, Brian E Carpenter <[email-masked]> wrote:

    
    Regards
       Brian

    

    David Farmer               Email:[email-masked] <mailto:[email-masked]>

**********************************************
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: David Farmer <[email-masked]>
Date: Tue, 14 Feb 2017 10:03:37 -0600

The problem we want it to be 64 bits except when it's not suppose to be,
such as RFC6164 for point-to-point and RFC6052 for IPv4/IPv6 translators
with /96 Network-Specific Prefix.

On Tue, Feb 14, 2017 at 9:53 AM, JORDI PALET MARTINEZ <
[email-masked]> wrote:

> De: ietf <[email-masked]> en nombre de David Farmer <[email-masked]
> >
> CC: <[email-masked]>, <[email-masked]>, 6man
> WG <[email-masked]>, IETF-Discussion Discussion <[email-masked]>
> Asunto: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6
> Addressing Architecture) to Internet Standard
>
>     Actually, in addition to your text there still needs to be a
> recommendation for 64 bit IIDs in all other cases.  64 bit IIDs are(and
> should remain) the norm for IPv6, I do not want to change that.  But the
> current language say IIDs are always 64 bit except when an address begins
> with binary 000, leaving no room for any other exception.  And this is
> plainly incorrect, I provided two clear exceptions that are already
> standardized.  Furthermore, IIDs other than 64 bits are in operational use,
> with manual configuration and DHCPv6.
>     So I'd suggest;
>
>     The other option is to enumerate all the exceptions, requiring the
> document to be updated every time a new exception is standardized.
>
> 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: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 14 Feb 2017 17:07:09 +0100

I understand that, but those are two clear exceptions, no others should be “allowed” by default.

Keeping the door open is not good in my opinion. Specific exceptions must be taken in consideration one by one.

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de David Farmer <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 14 de febrero de 2017, 17:03
Para: Jordi Palet Martinez <[email-masked]>
CC: 6man WG <[email-masked]>, <[email-masked]>, IETF-Discussion Discussion <[email-masked]>, <[email-masked]>
Asunto: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

    The problem we want it to be 64 bits except when it's not suppose to be, such as RFC6164 for point-to-point and RFC6052 for IPv4/IPv6 translators with /96 Network-Specific Prefix.
    
    On Tue, Feb 14, 2017 at 9:53 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:

    Regards,
    Jordi

    -----Mensaje original-----
    De: ietf <[email-masked]> en nombre de David Farmer <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: martes, 14 de febrero de 2017, 16:27
    Para: Brian E Carpenter <[email-masked]>
    CC: <[email-masked]>, <[email-masked]>, 6man WG <[email-masked]>, IETF-Discussion Discussion <[email-masked]>
    Asunto: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

    

    
    
        Regards
           Brian

    

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

---

From: Karsten Thomann <[email-masked]>
Date: Tue, 14 Feb 2017 10:36:14 -0800 (PST)

In my opinion the sentence should be restricted to cases where it's required 
to be 64 bit (SLAAC) and allow everything else.

There are enough examples where /127, /126 and /124bit masks are used.

So my favorite version is the one from Brian
>         Stateless Address Autoconfiguration [RFC4862] is required

Followed by David's version extended with recommendation of 64bit IID.

Regards
Karsten

Am Dienstag, 14. Februar 2017, 17:07:09 schrieb JORDI PALET MARTINEZ:
> CC: 6man WG <[email-masked]>, <[email-masked]>,
> IETF-Discussion Discussion <[email-masked]>, <[email-masked]> Asunto:
> Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing
> Architecture) to Internet Standard
> 
>     De: ietf <[email-masked]> en nombre de David Farmer
> <[email-masked]> Responder a: <[email-masked]>
> WG <[email-masked]>, IETF-Discussion Discussion <[email-masked]> Asunto: Re:
> Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing
> Architecture) to Internet Standard
> 
> with manual configuration and DHCPv6. So I'd suggest;
> 
>         >> Administrative Requests:
>         >> https://www.ietf.org/mailman/listinfo/ipv6
>         > Administrative Requests:
>         > https://www.ietf.org/mailman/listinfo/ipv6
> <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>> Networking & Telecommunication Services

---

From: [email-masked]
Date: Tue, 14 Feb 2017 20:06:18 +0100

Brian,

> Stateless Address Autoconfiguration [RFC4862] is required

Brian, changing the 64 bit boundary is such a big change that I would claim it is far outside the scope of advancing 4291 to Internet standard.

See https://tools.ietf.org/html/rfc7421 (which you by the way are the author of), for the set of documents that would have to change.
There are unknown interoperability issues here as well. As well as architectural considerations that probably should have IAB involvement.

Best regards,
Ole

---

From: David Farmer <[email-masked]>
Date: Tue, 14 Feb 2017 13:18:24 -0600

So I hear you saying something like the following would be appropriate in
your opinion;

However, the Interface ID of all unicast addresses is required to be 64 bit
with the exception of the following; addresses for point-to-point links
[RFC6164], Network-Specific Prefixes used for IPv4/IPv6 Translators
[RFC6052], and addresses that start with the binary value 000.

While this is the less preferred approach as far as I'm concerned, I
believe it resolves the issue I raised.

Thanks.

On Tue, Feb 14, 2017 at 10:07 AM, JORDI PALET MARTINEZ <
[email-masked]> wrote:

> IETF-Discussion Discussion <[email-masked]>, <[email-masked]>
>     The problem we want it to be 64 bits except when it's not suppose to
> be, such as RFC6164 for point-to-point and RFC6052 for IPv4/IPv6
> translators with /96 Network-Specific Prefix.
>
>     CC: <[email-masked]>, <[email-masked]>,
> 6man WG <[email-masked]>, IETF-Discussion Discussion <[email-masked]>
>     Asunto: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP
> Version 6 Addressing Architecture) to Internet Standard
>
> ballot/
>         David Farmer               Email:[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>
>     This electronic message contains information which may be privileged
> or confidential. The information is intended to be for the use of the

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Feb 2017 08:59:41 +1300

I certainly agree with that approach too.

In answer to Alexandre: you are correct that this value is a parameter for
RFC4862. But for reasons we have discussed often, it needs to be fixed
by the architecture.

Regards
   Brian

On 15/02/2017 08:18, David Farmer wrote:
>> [email-masked]>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 14 Feb 2017 17:26:17 -0800

On Tue, Feb 14, 2017 at 11:06 AM, <[email-masked]> wrote:

> Brian, changing the 64 bit boundary is such a big change that I would
> claim it is far outside the scope of advancing 4291 to Internet standard.
>

Agreed.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Feb 2017 14:31:20 +1300

>> claim it is far outside the scope of advancing 4291 to Internet standard.

Of course. The point is only that it's a parameter in the design of SLAAC,
whose value is set by the address architecture.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 14 Feb 2017 17:31:54 -0800

On Tue, Feb 14, 2017 at 11:18 AM, David Farmer <[email-masked]> wrote:

> However, the Interface ID of all unicast addresses is required to be 64
> bit with the exception of the following; addresses for point-to-point links

I don't think it makes sense to cite RFC6052 here, since in RFC 6052
addresses it's not really possible to define the IID in way that makes
sense. See
https://mailarchive.ietf.org/arch/msg/ipv6/lyZl3I4rXhnmXYFCAQTRWyohfyI .

---

From: David Farmer <[email-masked]>
Date: Wed, 15 Feb 2017 00:55:28 -0600

On Tue, Feb 14, 2017 at 7:31 PM, Lorenzo Colitti <[email-masked]> wrote:

> sense. See https://mailarchive.ietf.org/arch/msg/ipv6/
> lyZl3I4rXhnmXYFCAQTRWyohfyI .
>

I conceded that is probably true for most of the IPv4-Embedded IPv6 Address
Formats in section 2.2 of RFC6052, but the /96 format seems
indistinguishable from other IPv6 addresses with embedded IPv4 addresses
described in Section 2.4.5 of this draft.

And the following text from from section 2.4.4 of this draft seems to
strongly imply that IPv6 address with embedded IPv4 addresses have an IID
length other than 64.

   As noted in Section 2.4, all Global Unicast addresses other than
   those that start with binary 000 have a 64-bit interface ID field
   (i.e., n + m = 64), formatted as described in Section 2.4.1.  Global
   Unicast addresses that start with binary 000 have no such constraint
   on the size or structure of the interface ID field.

   Examples of Global Unicast addresses that start with binary 000 are
   the IPv6 address with embedded IPv4 addresses described in
   Section 2.4.5.....

Further, the fact that RFC6052 describes it as a /96 prefix, also seems to
strongly imply a 32 bit IID length.  Now I can imagine counter arguments
along the line that IPv6 addresses with embedded IPv4 addresses don't have
IIDs either, but pulling on that string puts me at a loss to explain the
rationale of the exclusion for addresses that start with binary 000 at all.

So, I suppose we limit the statement to the /96 Network-Specific Prefixes.

Also, as I've read through RFC6052 several times, I wonder if there should
be a reference to RFC6052 added in section 2.4.5. of this draft.  Maybe
something like the follow added to the end of the paragraph for section 2.4.5
.

Additional IPv6 address that carry an IPv4 address are defined in IPv6
Addressing of IPv4/IPv6 Translators [RFC6052].

Thanks.

---

From: Randy Bush <[email-masked]>
Date: Wed, 15 Feb 2017 17:56:10 +0900

> In my opinion the sentence should be restricted to cases where it's
> required to be 64 bit (SLAAC) and allow everything else.

thank you.

this classful bleep should have been gone a decade ago.  i can see
slaac, but for the rest, pfui.  enough already.

randy

---

From: [email-masked]
Date: Wed, 15 Feb 2017 10:31:12 +0100

Brian,

> whose value is set by the address architecture.

If your statement is that we only have the 64 bit boundary because of SLAAC I believe you are wrong.
Can you provide any support for that view?

If I understand you correctly, your proposal is to change the fixed 64 bit Interface-ID length in IPv6 to a variable one, with an exception for links where SLAAC is used.

How do you practically suggest to do this, given the issues raised in https://tools.ietf.org/html/rfc7421#section-4.1 ?

Do you think this change is appropriate in the context of advancing 4291?

Do you have implementation reports and are there not interoperability problems here?

Best regards,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 15 Feb 2017 02:54:04 -0800

On Tue, Feb 14, 2017 at 10:55 PM, David Farmer <[email-masked]> wrote:

> I conceded that is probably true for most of the IPv4-Embedded IPv6
> Address Formats in section 2.2 of RFC6052, but the /96 format seems

Could we say that the IID is 64 bits long "for all addresses except those
that start with binary 000, and those that embed IPv4 addresses [RFC 6052]"?

---

From: [email-masked]
Date: Wed, 15 Feb 2017 12:14:17 +0100 (CET)

> that start with binary 000, and those that embed IPv4 addresses [RFC 6052]"?

This is demonstrably false (there are lots of IPv6 interfaces with for
instance /124 or /126 masks, among others). I don't expect all of these
IPv6 interfaces to be changed to /64 even if an RFC says so.

So the question is, what do you gain by stating this in an RFC?

(I know, the discussion is old and I don't expect any views to change.
It stills seems wrong to publish an RFC with such an obviously wrong
statement.)

Steinar Haug, AS2116

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Feb 2017 10:19:39 +1300

> Can you provide any support for that view?

No, that's not what I'm saying. I'm saying that SLAAC - by design - would work
with any reasonable IID length, but we've chosen to fix it at 64.

> If I understand you correctly, your proposal is to change the fixed 64 bit Interface-ID length in IPv6 to a variable one, with an exception for links where SLAAC is used.

No. At least not in the foreseeable future. But we should allow for the fact that if
prefixes between /64 and /127 are used, routing needs to just work. That's all.

> How do you practically suggest to do this, given the issues raised in https://tools.ietf.org/html/rfc7421#section-4.1 ?

I'm not suggesting any change to normal subnets, where all those issues apply.
I can't see how /64 can be changed for them, without changing a great many
things.
 
> Do you think this change is appropriate in the context of advancing 4291?

I don't think I have suggested text that would lead to a single instruction in
running code being changed.

    Brian

---

From: [email-masked]
Date: Wed, 15 Feb 2017 22:34:13 +0100

Brian,

> running code being changed.

CURRENT (RFC4291bis):

PROPOSED:

    IPv6 unicast routing is based on prefixes of any valid length up to
   128 [BCP198].  For example, [RFC6164] standardises 127 bit prefixes
   on inter-router point-to-point links.  However, the Interface ID of unicast
   addresses used for Stateless Address Autoconfiguration [RFC4862] is required
   to be 64 bits long. The rationale for the 64 bit
   boundary in IPv6 addresses can be found in [RFC7421]

My reading of the proposed text, which certainly may be wrong, given that English is not my first language, is that it leaves the Interface-ID length of links _not_ using SLAAC undefined, i.e. not fixed at 64. Is there any other way to interpret this sentence?

The proposed text appears to make the Interface-ID length an operational choice.
How is that _not_ changing the 64 bit boundary?

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Feb 2017 10:52:16 +1300

> The proposed text appears to make the Interface-ID length an operational choice.

Ah, yes, there is a slight loophole there (but I think that somewhere else we
require all nodes to implement SLAAC, so maybe there isn't a real loophole.)
I would certainly agree to wording that closes that loophole. But the anomalies
people noted around the '000' subset need to fixed.

    Brian

---

From: Randy Bush <[email-masked]>
Date: Thu, 16 Feb 2017 11:24:54 +0900

> SLAAC I believe you are wrong.

cite, please.  what else actually needs it?

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 16 Feb 2017 11:27:46 +0900

>    unicast addresses used for Stateless Address Autoconfiguration
>    [RFC4862] is required to be 64 bits long. The rationale for the 64
>    bit boundary in IPv6 addresses can be found in [RFC7421]

i can live with this.

randy

---

From: Karsten Thomann <[email-masked]>
Date: Thu, 16 Feb 2017 06:06:04 +0100

Originalnachricht  

> bit boundary in IPv6 addresses can be found in [RFC7421]

As Randy, I can live with it.‎

---

From: [email-masked]
Date: Thu, 16 Feb 2017 08:40:04 +0100 (CET)

> >    bit boundary in IPv6 addresses can be found in [RFC7421]

+1

Steinar Haug, AS2116

---

From: [email-masked]
Date: Thu, 16 Feb 2017 09:23:44 +0100

Dear Randy,

> cite, please.  what else actually needs it?

https://tools.ietf.org/html/rfc7421

Best regards,
Ole

---

From: [email-masked]
Date: Thu, 16 Feb 2017 09:40:01 +0100

Randy, Karsten, Steinar,

>>   bit boundary in IPv6 addresses can be found in [RFC7421]

I presume the reason why you can live with it, is exactly because of the earlier pointed out loophole? :-)

You can't have it. At least not in this context. Write a draft.

See 7421, 6177, 7368, section 3.4.

There are many reasons for the 64 bit boundary.
  - Allowing identifier locator split: 8+8 / GSE that led to ILNP and NPT66
  - Simplicity in addressing (no more subnet masks)
  - A fair balance between the users and the providers of networks.
    Ensure that users get a fair share of addresses and try to avoid
    operators charging per address.

The 64 bit boundary is so embedded in the set of IPv6 specifications that it would be very hard to unravel at this point. It certainly cannot be a single paragraph put in during the advancement of 4291. Write a draft. Or write a book on protocol politics and the underlaying values reflected in the specifications...

Best regards,
Ole

PS: With an implementor hat on, I write code that can deal with any prefix length.

---

From: Randy Bush <[email-masked]>
Date: Thu, 16 Feb 2017 17:45:20 +0900

> https://tools.ietf.org/html/rfc7421

that excuses it.  cite where it is actually needed to do something
useful other than slaac.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 16 Feb 2017 17:52:07 +0900

On Thu, Feb 16, 2017 at 5:40 PM, <[email-masked]> wrote:

> The 64 bit boundary is so embedded in the set of IPv6 specifications that
> it would be very hard to unravel at this point. It certainly cannot be a
> single paragraph put in during the advancement of 4291.

Right. If we want to change this we can, but the process for that is start
with "write a draft and get consensus in 6man". We cannot change it while
revving 4291 to full standard, because it's a substantial change.

---

From: [email-masked]
Date: Thu, 16 Feb 2017 10:09:39 +0100

Dear Randy,

> that excuses it.  cite where it is actually needed to do something

"something useful" makes it subjective.

If you only care about technical issues, then:
SLAAC, NPT66, ILNP are the biggest one that I can think of.
Trivial to make SLAAC work with variable length prefixes of course.
As well as we don't know the consequences for implementations.
7421 seems to indicate it mostly works.

But then you have people who write code like this:
https://git.fd.io/vpp/tree/src/vnet/map/map.h#n332

Where it clearly will not work with a longer prefix than 64.
Feel free to contribute a patch, but make sure to count the cycles spent through that code.

I expect you'll find that most implementations deal with variable prefix length reasonably well, as long as you stay away from any of the above technologies.

There are many other issues here though, do we want to keep the option of an identifier and locator split open? Do the collective we trust the collective you to not put us into the same situation we had with IPv4 were users are forced to pay per address and instead chooses to deploy NAT?

It is upon you to provide evidence and justification for a proposed change. Not the other way around. Write a draft.

Best regards,
Ole

---

From: Randy Bush <[email-masked]>
Date: Thu, 16 Feb 2017 18:13:49 +0900

> "something useful" makes it subjective.

some of us try to operate networks.  useful is what customers pay us to
do.

> SLAAC, NPT66, ILNP are the biggest one that I can think of.

slaac is real, used, and is useful in some environments that customers
want.

> Trivial to make SLAAC work with variable length prefixes of course.

64 for slaac is fine.

for the rest, we went to cidr over a decade back, when folk scammed mo
out of 8+8.

randy

---

From: Mark Smith <[email-masked]>
Date: Thu, 16 Feb 2017 20:53:58 +1100

One of the benefits of a /64 is that IIDs within it can be sparsely
distributed, making device discovery by unsolicited inbound address probing
ineffective.

I think a router having these sorts of sparse IIDs in its addresses would
be a useful mitigation against router control plane attacks, such as a syn
attack on port 179 from the Internet.

Regards,
Mark.

64 for slaac is fine.

randy

---

From: David Farmer <[email-masked]>
Date: Thu, 16 Feb 2017 08:38:56 -0600

> Feel free to contribute a patch, but make sure to count the cycles spent

So, is that code right or wrong?  To be honest, I feel the current text
says its correct to embed 64 in your code.  If you truly think current text
is correct, then have the courage of your convictions and embed 64 in your
code too.

However, I take your example as evidence that the current text doesn't have
the balance right.  Is the proposed text too far the other way?  Maybe.
Well... actually probably it is too far the other way, but I don't see you
even acknowledging there is an issue with the current text.

As far as I'm concerned, this is a policy statement masquerading as a
technical requirement.  Policy is all about nuance and shades of gray, and
technical requirements are about clarity and making things ether black or
white.  The problem as I see it is, we are trying to use technical
requirements language too describe something that is truly a policy issue.
So we are probably doomed to fail!

How do we move forward? What I think we need is to make it clear that there
are real exceptions to 64, and it is therefore not acceptable to embed 64
in code.  The historic exception of addresses that start with 000 has been
too amorphous, no one thinks it real. I've provided two exception that are
clearly based on current standards track work, but I fear that still isn't
enough.  I fear some will still embed 64 and just add code for the
exceptions, if it's even really needed.

Can you help me find something a little more?

What about an additional exception for manual configuration?

Thanks.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 16 Feb 2017 18:07:13 +0100

Le 16/02/2017 à 15:38, David Farmer a écrit :
>
>
> On Thu, Feb 16, 2017 at 3:09 AM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Dear Randy,
>
>>>>> If your statement is that we only have the 64 bit boundary
> because of
>>>>> SLAAC I believe you are wrong.
>>>>
> <https://tools.ietf.org/html/rfc7421>
>>
> If you only care about technical issues, then: SLAAC, NPT66, ILNP
> are the biggest one that I can think of. Trivial to make SLAAC work
> with variable length prefixes of course. As well as we don't know
> the consequences for implementations. 7421 seems to indicate it
> mostly works.
>
> <https://git.fd.io/vpp/tree/src/vnet/map/map.h#n332>
>
> Where it clearly will not work with a longer prefix than 64. Feel
> free to contribute a patch, but make sure to count the cycles spent
> through that code.
>
>
> So, is that code right or wrong?  To be honest, I feel the current
> text says its correct to embed 64 in your code.  If you truly think
> current text is correct, then have the courage of your convictions
> and embed 64 in your code too.
>
> However, I take your example as evidence that the current text
> doesn't have the balance right.  Is the proposed text too far the
> other way? Maybe.  Well... actually probably it is too far the other
> way, but I don't see you even acknowledging there is an issue with
> the current text.
>
> technical requirement.  Policy is all about nuance and shades of
> gray, and technical requirements are about clarity and making things
> ether black or white.  The problem as I see it is, we are trying to
> use technical requirements language too describe something that is
> truly a policy issue.  So we are probably doomed to fail!
>
> How do we move forward? What I think we need is to make it clear that
> there are real exceptions to 64, and it is therefore not acceptable
> to embed 64 in code.  The historic exception of addresses that start
> with 000 has been too amorphous, no one thinks it real. I've provided
> two exception that are clearly based on current standards track work,
> but I fear that still isn't enough.  I fear some will still embed 64
> and just add code for the exceptions, if it's even really needed.
>

The manual configuration of IPv6 addresses on interfaces is a common
practice in establishing 2-computer one-to-one subnets on an Ethernet
wired link.  This often uses IPv6 addresses with prefix lengths
different than 64; e.g. /56, /60 or /72; in these cases the length of
the Interface ID is 128 minus that figure, to make sure 128 is respected.

During manual configuration gestures System Administrators appreciate
the easy to memorize strings denoting Interface IDs (e.g. ::abba),
rather than hard to spell strings (e.g. 5103:7ad5:4111:c22b).

Many DNS servers reachable on IPv6 have very short Interface IDs; check 
yours but mine is ::6, and a certain preferred is ::8888.  These are not 
normally /64, because they are not SLAAC'ed/Ethernet.

Alex

>
> Thanks. -- =============================================== David
> Farmer               Email:[email-masked]
> <mailto:[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
>  IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 16 Feb 2017 19:23:56 +0000

That RFC describes motivations for /64 that are mostly superseded. I still think we need to wean ourselves of the quasi-stateful address notion, in IPv6, at least for the remaining majority of the address space.

Bert

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, February 16, 2017 03:24
To: Randy Bush <[email-masked]>
Cc: 6man WG <[email-masked]>; IETF-Discussion Discussion <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

Dear Randy,

Best regards,
Ole

---

From: james woodyatt <[email-masked]>
Date: Thu, 16 Feb 2017 11:51:33 -0800

> that excuses it.  cite where it is actually needed to do something

RFC 6282 compresses IPv6 headers over IEEE 802.15.4 in a way that depends on such networks always having 64-bit network prefix length.

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 17 Feb 2017 05:31:20 +0900

> What I think we need is to make it clear that there are real
> exceptions to 64, and it is therefore not acceptable to embed 64 in
> code.

close.  64 is the exception; so slaac can work.

hiding the steaming classful pile in cute places around the document
only gets folk more annoyed.

randy

---

From: Mark Smith <[email-masked]>
Date: Fri, 17 Feb 2017 07:52:52 +1100

> only gets folk more annoyed.

So what is your objection to having a well-known addressing structure?

Objecting to it, calling it "classful", is implying that it is exactly
the same as IPv4 classful addressing. I don't think IPv6 is.

My memory of classful IPv4 addressing is that it not only specified an
addressing structure, it also specified a forwarding method based on
that structure. (e.g., the default route was only used if there
weren't any routes in the table that had the class matching the class
of the destination address.)

IPv6 doesn't. The addressing structure doesn't specify how different
bits are used during forwarding - all 128 are, using a longest match
per BCP 198.

So IPv6 specifically separates the addressing structure from the
forwarding method. I think calling that "classful" is
mischaracterising it.

Regards,
Mark.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 16 Feb 2017 20:55:27 +0000

My response to IEEE 802.15.4 would then be, but you can't assume that this same IPv6 header compression algorithm can be used in the unassigned IPv6 address space.

The message has to be clear. I think all the niggling objections make matters worse, for the future, in which future we will discover that the egregious waste caused by prefixes <= 64 bits creates a need for another IP version. The assumption that 64-bit prefixes are more than enough can become invalid in nit time, e.g. with IoT device that require multiple internal subnets.

Bert

From: ipv6 [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: Thursday, February 16, 2017 14:52
To: IETF-Discussion Discussion <[email-masked]>
Cc: [email-masked]; 6man WG <[email-masked]>; [email-masked]
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

On Feb 16, 2017, at 00:45, Randy Bush <[email-masked]<mailto:[email-masked]>> wrote:

If your statement is that we only have the 64 bit boundary because of
SLAAC I believe you are wrong.

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

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Feb 2017 13:12:28 -0800

> So what is your objection to having a well-known addressing structure?

I think the big problem is that it's well-known except when it isn't. We don't always have a 64 bit IID; we explicitly allow for prefixes like /127 (RFC 6164) etc in certain cases. It's a CIDR prefix (RFC 7608), meaning that prefixes in routing can be any length that makes sense operationally. 7608 was written in large part to advise chip vendors that prefix lengths longer than /64 needed to be OK.

So it isn't so very well-known. The 64 bit IID is a convention, not hard and fast. I would differ from Randy's characterization because of the kernel truth of RFC 7608, and with yours for the same reason.

And we seem to repeat this debate periodically. It gets boring.

---

From: [email-masked]
Date: Thu, 16 Feb 2017 22:25:06 +0100

David,

[...]

> How do we move forward? What I think we need is to make it clear that there are real exceptions to 64, and it is therefore not acceptable to embed 64 in code.  The historic exception of addresses that start with 000 has been too amorphous, no one thinks it real. I've provided two exception that are clearly based on current standards track work, but I fear that still isn't enough.  I fear some will still embed 64 and just add code for the exceptions, if it's even really needed.
> 

I have run out of ideas. :-)

The challenge is to find text that enforces the 64-bit boundary policy (ignoring the technical arguments for a moment), and at the same time ensures implementors do the right thing and make their code handle any prefix length. Of course these are interdependent and doing the latter makes it harder to enforce the first.

> What about an additional exception for manual configuration?

It's an architecture document. It should draw the big lines.
I don't think it should list exceptions, perhaps not even the 6164 one.

Learn to live with it?

(And I promise not to mention host-routes aka addresses with a /128 and interface-id length of 0.) :-)

Best regards,
Ole

---

From: james woodyatt <[email-masked]>
Date: Thu, 16 Feb 2017 14:21:16 -0800

On Feb 16, 2017, at 13:25, [email-masked] wrote:
> On Feb 13, 2017, at 14:32, David Farmer <[email-masked]> wrote:
>> 
>> The third sentence seems to limit exceptions to 64 bit IIDs to exclusively addresses that start with binary vale of 000.  There are at least two other exceptions from standards track RFCs, that should be more clear accounted for in this text. […]
> 
> […]

I propose the following:

>>> IPv6 unicast routing is based on prefixes of any valid length up to 128 bits [BCP198]. However, as explained in [RFC7421], the Interface ID of unicast addresses is generally required to be 64 bits in length, with exceptions only provided in special cases where expressly recognized in IETF standards track documents.

Trying to help out here.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 16 Feb 2017 22:38:55 +0000

RFC 7421 is informational. And many considerations are not so critical anymore, on a specific stateful format.

I don’t think we need to reinforce the notion that IPv6 must have 64-bit prefixes, since that is not true now, and should not even be made to apply to the currently unused address space. So, I’m opposed to text that implies any such restriction, with the exception of (a) currently used unicast  address space, (b) SLAAC, (c) ULA, possibly other exceptions.

In other words, exceptions belong to requiring the 64-bit IID. Any RFC that implies otherwise, IMO, ought to be subject to a –bis version.

Bert

From: ipv6 [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: Thursday, February 16, 2017 17:21
To: IETF-Discussion Discussion <[email-masked]>
Cc: 6man WG <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

On Feb 16, 2017, at 13:25, [email-masked]<mailto:[email-masked]> wrote:
On Feb 13, 2017, at 14:32, David Farmer <[email-masked]<mailto:[email-masked]>> wrote:

[…]

I propose the following:

Trying to help out here.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 17 Feb 2017 15:27:07 +0900

> the same as IPv4 classful addressing. I don't think IPv6 is.

These days IPv4 is classful too, because routing occurs on a 32-bit address
and a 16 bit port.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 17 Feb 2017 15:32:45 +0900

That's a valid opinion but it does not reflect the current state of the
IPv6 standards.

Again, let's bear in mind that this discussion is not about changing the
standard, but about reclassifying the existing standards. We can discuss
changing this part of the standard to our heart's content, but *in 6man, on
another document*, not here.

I would be rather surprised if such a discussion ever reached consensus,
but I certainly wouldn't want to dissuade anyone from trying.

On Fri, Feb 17, 2017 at 7:38 AM, Manfredi, Albert E <
[email-masked]> wrote:

> I don’t think we need to reinforce the notion that IPv6 must have 64-bit
> prefixes, since that is not true now, and should not even be made to apply
> to the currently unused address space. So, I’m opposed to text that implies
> any such restriction, with the exception of (a) currently used unicast
>  address space, (b) SLAAC, (c) ULA, possibly other exceptions.
>
>
>
> In other words, *exceptions belong to requiring the 64-bit IID*. Any RFC
> that implies otherwise, IMO, ought to be subject to a –bis version.
>
>
>
> Bert
>
>
>
>
>
> *From:* ipv6 [mailto:[email-masked]] *On Behalf Of *james woodyatt
> *Sent:* Thursday, February 16, 2017 17:21
> *To:* IETF-Discussion Discussion <[email-masked]>
> *Cc:* 6man WG <[email-masked]>; [email-masked];
> [email-masked]
> *Subject:* Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version
> 6 Addressing Architecture) to Internet Standard
>
>
>
> for in this text. […]
> The challenge is to find text that enforces the 64-bit boundary policy
> (ignoring the technical arguments for a moment), and at the same time
> ensures implementors do the right thing and make their code handle any
> prefix length. Of course these are interdependent and doing the latter
> makes it harder to enforce the first.
>
>
>
> I propose the following:
>
>
>
> IPv6 unicast routing is based on prefixes of any valid length up to 128
> bits [BCP198]. However, as explained in [RFC7421], the Interface ID of
> unicast addresses is generally required to be 64 bits in length, with
> exceptions only provided in special cases where expressly recognized in
> IETF standards track documents.
>
>
>
> Trying to help out here.
>
>
>
>
>
> --james woodyatt <[email-masked]>
>
>
>
>
>
>
>

---

From: [email-masked]
Date: Fri, 17 Feb 2017 08:44:20 +0100

James,

4291:
   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

4291bis:

Proposal:
   IPv6 unicast routing is based on prefixes of any valid length up to
  128 bits [BCP198]. However, as explained in [RFC7421], the Interface ID
   of unicast addresses is generally required to be 64 bits in length, with
   exceptions only provided in special cases where expressly recognised
   in IETF standards track documents.

I think that's a good proposal.
Perhaps with s/is generally required to be/are/

Best regards,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 17 Feb 2017 11:35:05 +0100

Le 16/02/2017 à 23:38, Manfredi, Albert E a écrit :
> prefixes, since that is not true now, and should not even be made to
> apply to the currently unused address space. So, I’m opposed to text
> that implies any such restriction, with the exception of (a) currently
> used unicast  address space, (b) SLAAC, (c) ULA, possibly other exceptions.
>
>
>

I agree.  And RFC2464bis should give the example, as it always did.

Alex

>
>
>
> Bert
>
>
>
>
>
> *From:*ipv6 [mailto:[email-masked]] *On Behalf Of *james woodyatt
> *Subject:* Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP
>         The third sentence seems to limit exceptions to 64 bit IIDs to
>         exclusively addresses that start with binary vale of 000.  There
>         are at least two other exceptions from standards track RFCs,
>         that should be more clear accounted for in this text. […]
>
>
>
>     […]
>
>     The challenge is to find text that enforces the 64-bit boundary
>     policy (ignoring the technical arguments for a moment), and at the
>     same time ensures implementors do the right thing and make their
>     code handle any prefix length. Of course these are interdependent
>     and doing the latter makes it harder to enforce the first.
>
>
>
> I propose the following:
>
>
>
>             IPv6 unicast routing is based on prefixes of any valid
>             length up to 128 bits [BCP198]. However, as explained in
>             [RFC7421], the Interface ID of unicast addresses is
>             generally required to be 64 bits in length, with exceptions
>             only provided in special cases where expressly recognized in

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 17 Feb 2017 11:39:43 +0100

> Perhaps with s/is generally required to be/are/

Perhaps s/is generally required to/MAY instead?

Alex

---

From: David Farmer <[email-masked]>
Date: Fri, 17 Feb 2017 11:32:43 -0600

I had an epiphany this morning and I have to jump back to Brian's proposed
text.

On Wed, Feb 15, 2017 at 3:34 PM, <[email-masked]> wrote:
> unicast
> My reading of the proposed text, which certainly may be wrong, given that
> English is not my first language, is that it leaves the Interface-ID length
> of links _not_ using SLAAC undefined, i.e. not fixed at 64. Is there any
> other way to interpret this sentence?
>

I would add ", in all other cases it is recommended to be 64 bits long."

> How is that _not_ changing the 64 bit boundary?

This has always been an operational choice.  You are mis-interrupting the
intent of the 64 bit boundary, you seem to be saying it intends to specify
the IID length for every interface on the Internet. If that was the intent,
then RA's would never have needed a prefix length, nor would you need to
specify a prefix length when manually configuring an interface.  If this
requirement intended to specify the IID length of every interface on the
Internet, then the requirement would have been sufficient by itself, we
would have been done at that point. However, the fact that RAs have prefix
lengths, and we specify a prefix length when manually configuring an
interface, belies the argument that this was not intended to be an
operational choice from the beginning.

So, for other than SLAAC, the 64 bit boundary has only ever been in
operational guidance, there are serious consequences to not following the
IETF's operational guidance in this regard, this is discussed in
[RFC7421].  However, it is an operational choice to follow that guidance or
not. Interpreting this requirement as ever taking away that operational
choice, shows this as a false imperative.

Best regards,

---

From: james woodyatt <[email-masked]>
Date: Fri, 17 Feb 2017 12:20:01 -0800

In response to various comments to this message, I’d like to propose a refinement:

> IPv6 unicast routing is based on prefixes of any valid length up to 128 bits [BCP198]. However, in accordance with the reasoning explained in [RFC7421], the Interface ID part of host interface addresses is generally 64 bits, with exceptions only provided in special cases expressly recognized in IETF standards track documents.

I disagree with the view that advancing RFC 4291 to standards track admits the opportunity to relax the applicability of the 64-bit boundary to only those cases where SLAAC is used. That would be a technical change to the specification that I’m not comfortable promoting at IETF Last Call. In support of that position, I note that the reasoning in RFC 7421 covers cases beyond just SLAAC, and I have previously written about a case not mentioned in RFC 7421, the LOWPAN_IPHC header compression scheme, which is used in various LLN schemes, e.g. IEEE 802.15.4, for compressing IPv6 addresses using the assumption that network prefixes are 64 bits.

For my personal part, I’d prefer to see a clear statement here using RFC 2119 requirements language keywords, but I recognize that consensus probably requires compromise on that point. Hence, the proposed refinement above, which does not use RFC 2119 keywords. (Here is how I would write this with keywords: “IPv6 unicast routing is based on network prefixes that MAY have any valid length up to 128 bits [BCP198]. However, in accordance with the reasoning explained in [RFC7421], the Interface ID part of host interface addresses SHOULD be 64 bits with exceptions only provided in special cases expressly recognized in IETF standards track documents.”)

---

From: Sander Steffann <[email-masked]>
Date: Sun, 19 Feb 2017 10:36:54 +0100

Hi,

>> IPv6 unicast routing is based on prefixes of any valid length up to 128 bits [BCP198]. However, in accordance with the reasoning explained in [RFC7421], the Interface ID part of host interface add…

Sounds good to me. It's clear on routing, it's clear on IIDs being 64 bits long except in special standards-track cases without trying to enumerate them and it provides an informational reference to explain why it should be 64 bits.

> For my personal part, I’d prefer to see a clear statement here using RFC 2119 requirements language keywords, but I recognize that consensus probably requires compromise on that point. Hence, the p…

I'm a bit worried that the "MAY have any valid length up to 128 bits" definition is too loose when read by router vendors, but otherwise that version sounds good as well. I like to see explicit clear guidance in standards documents.

One question: don't the texts conflict with things like policy based routing? Do we need to take that into account here?

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Sun, 19 Feb 2017 22:48:07 +0100

Hi,

Sorry, replying to myself. An off-list discussion made me realise I made an error.

> Sounds good to me. It's clear on routing, it's clear on IIDs being 64 bits long except in special standards-track cases without trying to enumerate them and it provides an informational reference t…

I have to clarify this a little bit. When reading it I was focusing on the "is generally 64 bits" part. In hindsight the exceptions clause is too strict though. See below for the rest.

> I'm a bit worried that the "MAY have any valid length up to 128 bits" definition is too loose when read by router vendors, but otherwise that version sounds good as well. I like to see explicit cle…

I like the SHOULD. It allows for exceptions. Such special case are recognised by the IETF and documents in standards track. Still good. There should be a clear guidelines to network operators. I have seen too many beginners mess up their addressing plans because they think they know better.

But on the other hand the text above limits exceptions to ONLY the IETF standards track, and that is too strong. Operators who know what they are doing must not be limited.

When writing my previous email I was focusing on giving guidance to operators, and thinking about inexperienced operators. When I saw that exceptions were taken into account I thought that that was good, but in hindsight the exceptions as written are too limited.

So to summarise I think we need to state that in general the IID SHOULD be 64 bits, exceptions MAY be defined, preferably in IETF standards track documents, equipment MUST allow operators to use any prefix length up to 128, and routing MUST support those prefix lengths.

Sorry if my series of messages were confusing. I'm trying to strike a balance between giving good guidance while allowing well-informed deviations, making sure that the text doesn't unnecessarily limit network operators while also protecting users so that ISPs don't start delegating them /96s "because it's more than enough and the RFC allows it" etc. (if you think that last argument is farfetched, sorry, I've seen too many ISPs start from there and only make a more reasonable addressing plan because the "/64 is the standard", so we shouldn't be too loose about that)

When reading the different arguments on this list I often find myself agreeing to most of them, even the conflicting ones, because I understand where the different viewpoints are coming from. And they are all important. It's difficult enough to try to fit everything together in my head, and I hope that this time I did a better job of writing it down in this email :)

Cheers,
Sander

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Feb 2017 10:13:33 +0900

> choice, shows this as a false imperative.

The fact that (most) glonal unicast IIDs are 64 bits is not an operational
choice, it is defined by the standards. The reason that it is a parameter
in various parts of the protocol is *not* that it is an operational choice;
the reason is to leave open the protocol to a future change in the
standards and future address allocations where IIDs are not required to be
64 bits long.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Feb 2017 10:21:49 +0900

On Sat, Feb 18, 2017 at 5:20 AM, james woodyatt <[email-masked]> wrote:

> bits [BCP198]. However, in accordance with the reasoning explained in
> [RFC7421],
>
> Do you think it makes sense to cite RFC 7934 as well? There is text in
there that also justifies the 64 bit boundary.

> the Interface ID part of host interface addresses is generally 64 bits,
>
> Note that this is also a change to the standard, because the previous
standard explicitly excluded global addresses starting with binary 000.

> with exceptions only provided in special cases expressly recognized in
> Can we require that said documents formally update this document?

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 20 Feb 2017 11:06:51 +0100

Hi Sander,

Thank you for clarification.

Le 19/02/2017 à 22:48, Sander Steffann a écrit :
[...]

> while also protecting users so that ISPs don't start delegating them
>  /96s "because it's more than enough and the RFC allows it" etc.

I agree.  An ISP delegating a /96 to an end-user is probably too long a
prefix for SLAAC/Ethernet to work.

In that sense, the ISP should be told to allocate at least a /63 (not a
/64) because of same SLAAC/Ethernet allowing only _one_ subnet if /64,
and allowing no subnet at all if /96.

But, AFAIK nobody could persuade a cellular ISP to provide a /63
rather than a /64 to UE.

Which brings back the question of why /64.

Alex

---

From: Sander Steffann <[email-masked]>
Date: Mon, 20 Feb 2017 16:01:39 +0100

Hi,

> Which brings back the question of why /64.

I think after this many years the answer is "because". If IPv6 had been designed from the start with /96 LANs then that would have been the standard. But today /64 is the standard, a clear standard size makes working with IPv6 easier, and we have enough addresses to actually do this. So is /64 the only technical choice that would work? No. Is it a choice made in the past that we should stick to (with well-informed exceptions where appropriate): Yes. It has advantages beyond pure technical necessity that make it useful.

But there MUST be room for people to use use something else than a /64. While it's good to have a default size that works well, forcing /64 though people's throat when they know what they are doing and need something else must remain possible. (this is both me speaking as an IPv6 teacher and as a network engineer :)

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Mon, 20 Feb 2017 16:12:02 +0100

Hi,

That sentence got messed up. Splitting the two parts of what I wanted to say:

> But there MUST be room for people to use use something else than a /64. While it's good to have a default size that works well, forcing /64 though people's throat when they know what they are doing and need something else

+is bad, and non-/64 networks

> must remain possible. (this is both me speaking as an IPv6 teacher and as a network engineer :)

Cheers,
Sander

---

From: David Farmer <[email-masked]>
Date: Mon, 20 Feb 2017 12:32:54 -0600

> there that also justifies the 64 bit boundary.

I think a reference to RFC 7934 absolutely belong in the IPv6 Addressing
Architecture, but it seems more appropriate in section 2.1, maybe the
second paragraph or even a new paragraph in that section.

---

From: Job Snijders <[email-masked]>
Date: Tue, 21 Feb 2017 00:57:34 +0100

On Fri, Feb 17, 2017 at 08:44:20AM +0100, [email-masked] wrote:
>    all unicast addresses, except those that start with the binary
>    value 000, is required to be 64 bits long.  The rationale for the
>    64 bit boundary in IPv6 addresses can be found in [RFC7421]
> 
> Proposal:
>    128 bits [BCP198]. However, as explained in [RFC7421], the
>    Interface ID of unicast addresses is generally required to be 64
>    bits in length, with exceptions only provided in special cases
>    where expressly recognised in IETF standards track documents.

wow, the last sentence of that proposal is overreaching! The text in
4291bis -07 is not ideal either. At this point, I do not believe
rfc4291bis can advance with such text. The contention around unicast
addresses not starting with a binary value 000 must be resolved.

Let's look at the following:

    job@tardis:~$ sudo ip -6 addr show dev eth1
    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
        inet6 2001:728:1808:1::21/126 scope global
           valid_lft forever preferred_lft forever
        inet6 fe80::20d:b9ff:fe41:d4f5/64 scope link
           valid_lft forever preferred_lft forever
    job@tardis:~$ echo HERESY\! a /126\!

Is the IPv6 Addressing Architecture Police (IAAP) gonna come to crack
down on this? What's IETF going to do about this? Nothing! Is this bad?
No. Should there be any tolerance for "IPv6 capable" hw/sw which can't
cope with a /126, /120 or whatever? No.

The main issue for me on this point is that from a pragmatic point of
view, a architecture policy specification should strive to match the
expected deployment reality. I think we can argue that there now is
sufficient deployment experience to admit that all possible IPv6 prefix
lengths are configured.

Referencing RFC7421 is fine, but please realise that in doing so we're
(by proxy) referencing FDDI, ATM, Token Ring and other fascinating
standards from the good ole' days - imho a 7421 ref is just scrambling
for arguments.

Persisting with a 64-bit boundry fixation is actually making the IPv6
address architecture _less_ expressive. When expressiveness is limited
through an arbitrary rule... that's just shortsighted. 

Nobody can claim that we know all use cases (with their respective up
and downsides). However, the few use cases we _do_ know about arrived at
different prefix lengths. Why continue to document exceptions? That is
just busywork. There is no 'one true subnet size'.

Mandating something arbitrary like 'address ID must be 64 bits' when
there is no technical requirement for such rule would be nothing short
of arrogant.

The ND/SLAAC attack vector was real problem, can still be real, why
pretend that that issue doesn't exist by mandating 64-bit IIDs? Any sane
deployment will take steps to cover that risk surface. A valid
mitigation strategy remains to just configure something longer then a
/64 ... like /120

We must accept that we cannot see into the future. Let operators choose.

Kind regards,

Job

ps. The "Write a draft" argument is weak at best, since we are already
are discussing a draft (called 'draft-ietf-6man-rfc4291bis-07.txt'),
which is in IETF Last call, which means it is in a place to discuss the
contents of that draft. No reason to kick the can down the road.

---

From: Fred Baker <[email-masked]>
Date: Mon, 20 Feb 2017 16:06:33 -0800

> We must accept that we cannot see into the future. Let operators choose.

That, of course, was the point of RFC 7608.

---

From: Job Snijders <[email-masked]>
Date: Tue, 21 Feb 2017 01:19:40 +0100

> - Allowing identifier locator split: 8+8 / GSE that led to ILNP and NPT66

Irrelevant.

> - Simplicity in addressing (no more subnet masks)

That seems an overly optimistic statement.

>   operators charging per address.

IETF is not a product management committee. Regardless of what is fair
or just or reasonable, vendors will charge for the strangest things.
While I sympathize with the objective, I do not think this is the
appropiate forum to achieve such a goal.

Also, I think we here touching upon the very heart of the issue: some
would like to force every link on this planet to have a routable /64
(for perhaps ideological reasons), and some don't (for perhaps
operational reasons).

I'm from the school of thought where unenforceable rules have no place
in society. There already is precedent to abandon a classful addressing
paradigm in favor of classless inter-domain routing. This implies that a
the fixed 64 bit boundary is unattainable, as such, getting classless
IPv6 is merely a matter of expending sufficient energy.

> The 64 bit boundary is so embedded in the set of IPv6 specifications
> that it would be very hard to unravel at this point. It certainly
> cannot be a single paragraph put in during the advancement of 4291.
> Write a draft. Or write a book on protocol politics and the
> underlaying values reflected in the specifications...

If this is the case, why proceed 4291bis while its content is contested?
What purpose does that serve?  By publishing 4291bis, one would add yet
another referenceable source to legitimize the 64 bit boundary, which
adds to the pile of things that need to be 'unraveled'. Perhaps the buck
should stop here?

> PS: With an implementor hat on, I write code that can deal with any prefix length.

Excellent! Keep it up.

Kind regards,

Job

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 21 Feb 2017 09:49:32 +0900

> contents of that draft. No reason to kick the can down the road.

I'm sorry, but that's really how it is. The text you dislike has been the
standard for almost 20 years, and is it inappropriate to change it in the
context of reclassifying this document from draft standard to Internet
standard.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Feb 2017 14:11:15 +1300

Hi Job,

>> - Allowing identifier locator split: 8+8 / GSE that led to ILNP and NPT66

Not really. They are both running code. You may not want them in
*your* network but that isn't the point. Some people want them.

And there is a lot of other running code too, not just SLAAC which is
mandatory to implement in every IPv6 host. So this actually trumps all
the other arguments: it's 64 bits because it's 64 bits.

...
> (for perhaps ideological reasons),

No. For running code and interoperability reasons. We could have settled
on 48 bits, but we didn't. But, because of interoperability, we had to
pick something.

> and some don't (for perhaps
> operational reasons).

In practice, there isn't much choice except for point to point links.
All the same, we definitely needed RFC7608 (=BCP198).
 
> IPv6 is merely a matter of expending sufficient energy.

No. IPv6 routing is classless and always has been. RFC7608 simply re-states
it. But automatic address assignment, which is an equally important property
of IPv6, needs a default setting for portable code, and it is /64. That isn't
a matter of opinion. It's a (possibly inconvenient) truth.

...
> If this is the case, why proceed 4291bis while its content is contested?

What we're discussing is the exact text to describe the inconvenient
truth. I'm not aware of any generally available running code that will
be changed in even one instruction by the final text - that is indeed
a requirement for advancement to Internet Standard.

   Brian

---

From: Job Snijders <[email-masked]>
Date: Tue, 21 Feb 2017 11:13:39 +0100

> the other arguments: it's 64 bits because it's 64 bits.

When someone utters the phrase "it is X because it is X", the rhetorical
imperative seems to be to dismiss further conversation (perhaps any
internal dialogue as well, which may be the primary purpose). "It is
what it is" therefore, there’s nothing more to be said about it...

Except when it's not 64 bits?

> a requirement for advancement to Internet Standard.

The below is truth.

AS 2914 is one of the larger Internet backbones. If the Internet
Archives are to believed they started deployment of IPv6 15+ years ago.

I've looked at all configured IPv6 addresses on AS 2914 equipment.
Interestingly enough, the below table is a reflection of not only NTT's
own addressing, and (since AS2914's core function is to connect networks
to each other) also of its peers and customers. In the end, whatever
makes the thing work is the thing that will be configured.

	/127 - 22%
	/126 - 52%
	/125 - 0,9%
	/124 - 0,5%
	/120 - 0,04%
	/112 - 0,02%
	/64  - 23%

The above percentages come from grepping through configurations of
thousands of interconnections. I'm confident that other networks will
show similar prefix length distributions.

I'd be interested to see an accomodation for staticly configured
environments in the text.

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Tue, 21 Feb 2017 18:27:39 +0100

On Tue, Feb 21, 2017 at 09:49:32AM +0900, Lorenzo Colitti wrote:
> > ps. The "Write a draft" argument is weak at best, since we are
> > already are discussing a draft (called
> > 'draft-ietf-6man-rfc4291bis-07.txt'), which is in IETF Last call,
> > which means it is in a place to discuss the contents of that draft.
> > No reason to kick the can down the road.
> 
> I'm sorry, but that's really how it is. The text you dislike has been
> the standard for almost 20 years, and is it inappropriate to change it
> in the context of reclassifying this document from draft standard to
> Internet standard.

Or, perhaps it is inappropiate for the -bis document to target "Internet
Standard" classification at this moment? ¯\_(ツ)_/¯

Especially when solidifying recommendations in an architecture Internet
Standard-to-be, the utmost care should be taken to verify whether the
paper reality (RFCs) and operational reality (what people do, for
$reasons) are aligned.

In those years sufficient data has been collected to conclude that /64
is not the "be all and end all". The current paragraph does not account
for staticly configured environments in which SLAAC plays no role.

Perhaps the following suggestion bridges the gap.

-------

OLD:

NEW:
   IPv6 unicast routing is based on prefixes of any valid length up to
   128 [BCP198]. When using [SLAAC], [ILNP], or [NPT66] the Interface ID
   of unicast addresses is required to be 64 bits long. In other use
   cases different prefix sizes may be required. For example [RFC6164]
   standardises 127 bit prefixes on inter-router point-to-point links.
   For most use cases, prefix lengths of 64 bits is RECOMMENDED, unless
   there are operational reasons not to do so.

OLD:
   As noted in Section 2.4, all unicast addresses, except those that
   with the binary value 000, Interface IDs are required to be 64 bits
   long.

NEW:
    *delete, its superfluous*

-------

Kind regards,

Job

---

From: Karsten Thomann <[email-masked]>
Date: Tue, 21 Feb 2017 11:21:33 -0800 (PST)

Am Dienstag, 21. Februar 2017, 18:27:39 schrieb Job Snijders:
> Standard" classification at this moment? ¯\_(?)_/¯
> 

Satisfies my desired outcome of the text, but I would like to modify it:
    IPv6 unicast routing is based on prefixes of any valid length up to
    128 [BCP198]. When using [SLAAC], [ILNP], or [NPT66] the Interface ID
    of unicast addresses is required to be 64 bits long. An exception is for
    example [RFC6164] which standardises 127 bit prefixes on point-to-point
    links. The RECOMMENDED prefix length is 64 bit, but prefix lengths up to
   128 bit can be possible on explicit configuration.

>     *delete, its superfluous*
Ok for me.

---

From: Mark Smith <[email-masked]>
Date: Wed, 22 Feb 2017 06:43:56 +1100

> paper reality (RFCs) and operational reality (what people do, for

Flexibility isn't cheaper, it is more operationally expensive, because
it creates opportunity for complexity and errors.

A very simple example to demonstrate the additional cost of flexibility.

You showed the the distribution of prefix lengths in an AS. That may
have taken say 5 minutes to assemble and calculate? If all your prefix
lengths were /64s, you could have saved 5 minutes because you would
know the single value.

Multiply that sort of example 5 minutes over the many times you deal
with the complexity and errors that will occur when having a range of
prefix lengths, and that will add up to a significant amount of time.
It was an unavoidable cost in IPv4 because it was necessary to stretch
the usable life of IPv4's 32 bits of address space. It is an avoidable
cost in IPv6.

IPv4 too started out with a fixed or well known boundary between the
network portion and the host portion.

RFC760:

"   Addresses are fixed length of four octets (32 bits).  An address
    begins with a one octet network number, followed by a three octet
    local address.  This three octet field is called the "rest" field."

I advocate for /48s for all customers over a mix of /56s and /48s for
the same reason. The cost of managing the different prefix lengths and
resolving errors when the incorrect size prefix is assigned to a
customer are significant compared to the savings in RIR fees, and
perhaps may eliminate all those savings. When there is a single value
or size, there is no ambiguity and no opportunity for error.

I think many network engineers (and many technical people in general)
consider flexibility to be a a desirable property because they think
it means they'll be able to adapt to any future requirement without
any significant constraints. It's an understandable view (which I used
to have), however, I don't think they often consider the cost that
flexibility creates. I've also haven't seen that flexibility pay off
as much as it is supposed to.

> is not the "be all and end all".

Alternatively, it could show that people are applying IPv4 practices
they're familiar with to IPv6, even when it isn't necessary. They're
missing out on operational savings from simplicity.

Regards,
Mark.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 21 Feb 2017 19:50:50 +0000

> From: ipv6 [mailto:[email-masked]] On Behalf Of Job Snijders

>    there are operational reasons not to do so.

Sounds about right to me. Another exception that requires /64 would be ULAs.

I think that after RFC 2460-bis becomes the standard, this /64 debate will be revisited. Why? To make it super clear that for unicast, in general, /64 are going to be the exception, not the rule (as so much text now suggests). The 64 bit prefix applies to the 2000::/3 address space, and those few exceptions.

For example, this is all up in the air still, but we can assume that just as households are being assigned one /64 prefix frequently, so will cars? Each car gets a /64. Does anyone think that cars will only include one IPv6 subnet? Not me. So we will need CIDR.

Bert

---

From: Mark Smith <[email-masked]>
Date: Wed, 22 Feb 2017 06:56:53 +1100

>> > On Tue, Feb 21, 2017 at 8:57 AM, Job Snijders <[email-masked]> wrote:
<snip>
>     links. The RECOMMENDED prefix length is 64 bit,

It has to be stronger than a RECOMMENDED, because that implies it is
an arbitrary choice that won't have any protocol operational and
privacy or security impacts. That is not the case.

Have you and Job read,

"Analysis of the 64-bit Boundary in IPv6 Addressing
https://tools.ietf.org/html/rfc7421

?

(It has been referenced at some point in a version of this text
proposed I think.)

Regards,
Mark.

---

From: Job Snijders <[email-masked]>
Date: Tue, 21 Feb 2017 21:28:21 +0100

On Wed, Feb 22, 2017 at 06:43:56AM +1100, Mark Smith wrote:
> > In those years sufficient data has been collected to conclude that
> > /64 is not the "be all and end all".
> 

Have you read rfc1925 section 2.4?

You are grossly overstating these 'operational savings'. Also, for the
sake of this dialogue I'll apply Hanlon's razor and operate under the
assumption that you are not familiar with my work environment. 

I am amazed your reaction to my sharing of real-world data is the
equivalent of "well, i think you are doing it wrong". A lack of empathy
is exhibited in that you do not wonder _why_ things are what they are.

Kind regards,

Job

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 21 Feb 2017 16:52:42 -0500

> >     links. The RECOMMENDED prefix length is 64 bit,
Firstly, the last update to the suggested text seems great to me. As I see
it, operating a reasonably large mixed-mode network... and some smaller
networks around the place... There are operational reasons why /64 makes
sense, for instance: "I just want all these things to get a v6 address, I
don't really care which one" and SLAAC fits that bill.

For my network interfaces I may (for my own reasons) decide that /127 is
perfect for me, and roll out all NNI type interfaces as /127's (hey, I even
helped with the rfc about this) ... for 'operational reasons' I don't care
about SLAAC, so I don't care about /64... and having to 'break the
standard' seems silly. Yes, this case is already taken care of by
RFC6164... but i have servers on which I don't need SLAAC to manage
addressing and simply assign addresses according to some other
systems-management automation... I even limit the number of devices per
subnet for internal reasons, so I don't need a /64 there, I just need a
/124.

I think the idea that some 'applications' need /64 is fine... but making
'all the things must be /64' just silly, in light of the actual deployment
and use-cases today. Therefore, the text as proposed above seems on target.

There have certainly been plenty of baked-in (to asics and/or software)
assumptions about /64 over the years, we shouldn't want that to happen
longer term and wording like:

  "However, the Interface ID of
   all unicast addresses, except those that start with the binary value
   000, is required to be 64 bits long"

ends up letting people make assumptions again, which get baked into
code/asics :(

> privacy or security impacts. That is not the case.

Someone else pointed out that the 2119 language isn't used/referenced in
4291, looking quickly:
  $ grep MUST rfc4291.txt

  $

seems to agree with that assertion... so I don't think "RECOMMENDED" is
right here, I think: "recommended" is correct.. and that since 2119 isn't
used you can't expect anything in the document to actually be binding :(
whoops! Also, /64 really was an 'arbitrary choice' ... more or less anyway.
Trusting in people to follow without MUST/SHOULD/RECOMMENDED seems a bit
crazy, but :)

thanks job@ for making a suggested fix here, I too am troubled by the
'classful' ideas in the ipv6 space, those didn't seem useful long-term in
ipv4 so I can't see how they would be useful in the short-term here in
v6-land.

I'm really not a fan of the: "But this makes subnetting easy!" arguments...
i don't think those hold water since we have tooling to do subnetting, it's
just not a problem looking for a solution anymore.

-chris

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Feb 2017 11:44:42 +1300

> Except when it's not 64 bits?

That wasn't quite my intention. I just wanted to underline that
(like it or not) it was set at 64 bits many years ago and a lot
has been built on that.

...
> makes the thing work is the thing that will be configured.

Thanks, that's interesting. So 23% of the devices might have 
RFC4291-compliant IIDs. The others are configured with 128 bit
IPv6 addresses. Is that correct?

That being so, perhaps the words that are missing are
"The IID length requirement does not apply to interfaces that
are explicitly configured with 128 bit addresses." Because the
requirement is meaningless for such interfaces.

   Brian

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 21 Feb 2017 17:56:52 -0500

> (like it or not) it was set at 64 bits many years ago and a lot
I think one of the points the thread has brought out is that: "just because
we have always been at war with elbonia, does not mean we have to keep
being at war with elbonia"

We don't have to keep promulgating advice that we don't actually use in
practice... If we set the "Internet Standard" today we can move forward to
a better world in the time it takes to age out old 'broken'
gear/software... (yes, that's a while but eventually :) )

> requirement is meaningless for such interfaces.
specifying the 128 here seems wrong... or I'm using it wrong in my
interpretation :)
I would have said:
  "The IID length requirement does not apply to interfaces that are
explicitly configured."

all ipv6 interfaces have 128 addresses, they may have a subnet
configuration which is shorter though. right?

---

From: Job Snijders <[email-masked]>
Date: Tue, 21 Feb 2017 23:58:57 +0100

> IPv6 addresses. Is that correct?

The percentage is not the percentage of devices, but the percentage of
interconnections. In all instances the addresses are staticly
configured.

Back to my example from earlier, to make sure we are on the same page,
this is output from a standard Linux machine:

    job@tardis:~$ sudo ip -6 addr add 2001:728:1808:1::21/126 dev eth1
    job@tardis:~$ 

Most network engineers would call the above example "configuring a /126
on an interface" - but am I understanding correctly that in your
taxonomy you would call this "configuring a 128 bit IPv6 address"?

> requirement is meaningless for such interfaces.

The terminology might confuse some people, as in common language when
one configures "a /128", or 'a 128 bit address', it usually means you
are configuring something like a loopback address.

Perhaps:

    "The IID length requirement does not apply to interfaces that are
    explicitly configured without autoconfiguration."

(perhaps even remove the word 'explicitly')

    "The IID length requirement does not apply to interfaces that are
    configured without autoconfiguration."

Kind regards,

Job

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Feb 2017 12:23:17 +1300

> interconnections. In all instances the addresses are staticly

OK, but from the outside I can't know that for the /64 subnets.

> taxonomy you would call this "configuring a 128 bit IPv6 address"?

Well that does two things: configures a 128 bit address (as Chris points
out, *all* addresses are 128 bits, duh) and associates a prefix length
with it, which afaik is optional. But the interface has already
auto-configured a link-local address, with a 64 bit IID. So yes, that's
exactly what I mean.

>     configured without autoconfiguration."

Personally I think that's right. (However, if you manually configure
an address that matches a pre-existing prefix announced by an RA,
it will be assumed to belong to that prefix. I've done that by
hand on Windows, not sure I've done it in Linux.)

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Feb 2017 09:19:58 +0900

> show similar prefix length distributions.

"Thousands of interconnections" are not really relevant given that we're
well into the hundreds of millions of IPv6 hosts on residential or mobile
connections that provide one or more /64s.

---

From: David Farmer <[email-masked]>
Date: Tue, 21 Feb 2017 19:07:03 -0600

Sent from my iPhone

> On Feb 21, 2017, at 18:19, Lorenzo Colitti <[email-masked]> wrote:
> 
> "Thousands of interconnections" are not really relevant given that we're well into the hundreds of millions of IPv6 hosts on residential or mobile connections that provide one or more /64s.

It can equally be said that the millions of IPv6 hosts don't matter either, because without those thousands of interconnections the millions of hosts aren't connected to each other or the Internet.  But both perspectives are equally correct, its not one or the other, it's both, they are interdependent on each other.  Without hosts there is no need for the interconnections, and without the interconnections there wouldn't be millions of hosts in the first place.

---

From: Job Snijders <[email-masked]>
Date: Wed, 22 Feb 2017 02:50:41 +0100

Perhaps you are jesting, but I'll bite.

Those "thousands of interconnections" facilitate the communication between millions of those hosts. Have you considered that not all interconnections are equal? The type of interconnection I am mainly (but not exclusively) referring to is the interconnection between Autonomous Systems to facilitate the exchange of routing information using BGP-4. Autoconfiguration plays no role here, everything is configured explicitly. I'd argue that the use case is hardly comparable with a residential or mobile connection.

Surely you don't mean to say that the Internet's backbone routers are irrelevant because they are the minority from a device count perspective? It's fine if you do, it'll help me put your comments in perspective.

In the last 15 years we've been through all kinds of phases, the observant reader might perceive an intricate tension between two schools of thought blossom, a dance even:

RFC 3513 "only /64 is valid"
RFC 3627 "don't use /127, use /126 if you must"
RFC 4291 "reaffirming: only /64 is valid"
RFC 6164 "a /127 is OK to use too"
RFC 6583 "there are problems with /64"
RFC 7421 "/64 is the best!"
RFC 7608 "every prefix length must be forward-able"
RFC 4291bis-07 "fine, /64 and /127 are valid, but nothing else!"

As pointed out in this thread, real networks use all kinds of prefix lengths. Also, one doesn't renumber everything every time a new document comes out - you stick to things that work for you.

Some vendors in this thread have admitted to strive to make things work with any prefix length, why is there then still a discussion that people must use /64 - when both vendors and users are not always doing so, for good reasons?

I'm confident this discussion will eventually resolve itself and conclude that /64 is not the only valid prefix length, rigid positions rarely are attainable. Water can flow or it can crash.

Kind regards,

Job

On 22 Feb 2017, 01:20 +0100, Lorenzo Colitti <[email-masked]>, wrote:
> On Tue, Feb 21, 2017 at 7:13 PM, Job Snijders <[email-masked] (mailto:[email-masked])> wrote:

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Feb 2017 12:00:18 +0900

On Wed, Feb 22, 2017 at 10:50 AM, Job Snijders <[email-masked]> wrote:

> Those "thousands of interconnections" facilitate the communication between
> millions of those hosts.
>

But the configuration cost and management overhead is not proportional to
the hosts that are served by those interconnections, it is proportional to
the number of interconnections. A 10x100G peering interconnection that
serves X million hosts is one interface that has to be managed.

Have you considered that not all interconnections are equal? The type of
> interconnection I am mainly (but not exclusively) referring to is the
> interconnection between Autonomous Systems to facilitate the exchange of
> routing information using BGP-4. Autoconfiguration plays no role here,
> everything is configured explicitly. I'd argue that the use case is hardly
> comparable with a residential or mobile connection.
>

Those use cases are very well served by /127 for PNIs and /64s for Internet
exchanges. What's left?

As pointed out in this thread, real networks use all kinds of prefix
> lengths. Also, one doesn't renumber everything every time a new document
> comes out - you stick to things that work for you.
>

As discussed above, most links use /64.

Some vendors in this thread have admitted to strive to make things work
> with any prefix length, why is there then still a discussion that people
> must use /64 - when both vendors and users are not always doing so, for
> good reasons?
>

You're forgetting about host operating system developers and host users,
both of which benefit substantially to having a subnet size that is always
the same and never runs out of addresses.

I'm confident this discussion will eventually resolve itself and conclude
> that /64 is not the only valid prefix length, rigid positions rarely are
> attainable. Water can flow or it can crash.
>

Even if you're right, the place to have that discussion is not on this
document.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 21 Feb 2017 22:12:18 -0500

On Tue, Feb 21, 2017 at 10:00 PM, Lorenzo Colitti <[email-masked]>
wrote:

>> Those "thousands of interconnections" facilitate the communication
>> between millions of those hosts.
>>
>
isn't the dicsussion here really:
  "If you want to use /64 go ahead, if you want to use /121 go for it, if
you want to use SLAAC you'll get a /64 and like it"

which fits both the interconnect problem space and the home-consumer
problem space. The change outlined ~6 messages back seemed to be a more
officious way to say what my quoted bit above says, and seemed just fine
for both use cases.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Feb 2017 12:51:51 +0900

> you want to use SLAAC you'll get a /64 and like it"

Not sure. I for one wouldn't agree with that position, because I don't see
that /121 has enough advantages over /127 and /64 - and few enough
downsides for general-purpose hosts - to make it a good idea in general.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 21 Feb 2017 23:44:18 -0500

> downsides for general-purpose hosts - to make it a good idea in general.

I don't think /121 is anymore special than /127... or /64. My point was we
don't care what prefix people use, generally, that there are cases where a
/64 is required and that's fine, there are cases where /64 isn't and people
can do what they want there.  It's simple enough to do SLAAC/64 on lans and
other places.

Requiring /64 or /127 and nothing else means when you do have to do a /120
or something else you MAY end up fighting vendor problems because they made
assumptions about: "only ever 64 or 127".

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 Feb 2017 15:08:51 +0700

>   "If you want to use /64 go ahead, if you want to use /121 go for it,
> if you want to use SLAAC you'll get a /64 and like it"

with which i do not have a probem.

and i even use slaac at home where things such as address control,
reverse dns, etc. do not matter and are not worth the effort.

randy

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 22 Feb 2017 10:55:22 +0100

Le 22/02/2017 à 04:00, Lorenzo Colitti a écrit :
> On Wed, Feb 22, 2017 at 10:50 AM, Job Snijders <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> But the configuration cost and management overhead is not proportional
> to the hosts that are served by those interconnections, it is
> proportional to the number of interconnections. A 10x100G peering
> interconnection that serves X million hosts is one interface that has to
> be managed.
>
>     Have you considered that not all interconnections are equal? The
>     type of interconnection I am mainly (but not exclusively) referring
>     to is the interconnection between Autonomous Systems to facilitate
>     the exchange of routing information using BGP-4. Autoconfiguration
>     plays no role here, everything is configured explicitly. I'd argue
>     that the use case is hardly comparable with a residential or mobile
>     connection.
>
>
> Those use cases are very well served by /127 for PNIs and /64s for
> Internet exchanges. What's left?
>
>     lengths. Also, one doesn't renumber everything every time a new
>     document comes out - you stick to things that work for you.
>
>
>     Some vendors in this thread have admitted to strive to make things
>     work with any prefix length, why is there then still a discussion
>     that people must use /64 - when both vendors and users are not
>     always doing so, for good reasons?
>
>

I think you talk about users of hosts like smartphones, situated at the
edge of the Internet, not in the core.

In straightforward IP addressing architectures ("hierarchical"), the
prefixes of routes towards the edges are naturally shorter than that 64:
e.g. prefix /60 for site, /63 for building, /64 for office desk.

In practice these hierarchical architectures are ideals hard to
implement. Because some hosts even in the core use SLAAC/Ethernet/64,
because edges expand, etc.

This makes that people need prefix lenghts of routes to lead to a
particular /64 carved out of some other prefix, instead of aggregating.
This leads to waste of publically routable space, or to the use of ULA
prefixes, or NAT66 prefixes, which have inconvenients too.

Alex

> both of which benefit substantially to having a subnet size that is
> always the same and never runs out of addresses.
>
>     I'm confident this discussion will eventually resolve itself and
>     conclude that /64 is not the only valid prefix length, rigid
>     positions rarely are attainable. Water can flow or it can crash.
>
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 22 Feb 2017 21:15:32 +1100

In message <[email-masked]>, Alexandre Petrescu writes:
> 
> 
> Le 22/02/2017 =E0 04:00, Lorenzo Colitti a =E9crit :

In a straight forward addressing architecture a site gets a /48 and 
sub entities request the numbers of /64's they need and it uses a
autoconfiguring routing protocol for routing traffic.   Homes and
most sites don't need heirachical routing.  65000 routing entries
should be able to be handled even by a $15 router.

> prefixes, or NAT66 prefixes, which have inconvenients too.

Or you just requests the prefixed you need and use a routing protocol.

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 22 Feb 2017 11:43:25 +0100

Le 22/02/2017 à 11:15, Mark Andrews a écrit :
>>> Those "thousands of interconnections" facilitate the
>>> communication between millions of those hosts.
>>>
>>>
>>> But the configuration cost and management overhead is not
>>> proportional to the hosts that are served by those
>>> interconnections, it is proportional to the number of
>>> interconnections. A 10x100G peering interconnection that serves X
>>> million hosts is one interface that has to be managed.
>>>
>>> type of interconnection I am mainly (but not exclusively)
>>> referring to is the interconnection between Autonomous Systems to
>>> facilitate the exchange of routing information using BGP-4.
>>> Autoconfiguration plays no role here, everything is configured
>>> explicitly. I'd argue that the use case is hardly comparable with
>>> a residential or mobile connection.
>>>
>>>
>>> Those use cases are very well served by /127 for PNIs and /64s
>>> for Internet exchanges. What's left?
>>>
>>> As pointed out in this thread, real networks use all kinds of
>>> prefix lengths. Also, one doesn't renumber everything every time
>>>  a new document comes out - you stick to things that work for
>>> you.
>>>
>>>
>>> Some vendors in this thread have admitted to strive to make
>>> things work with any prefix length, why is there then still a
>>> discussion that people must use /64 - when both vendors and users
>>> are not always doing so, for good reasons?
>>>
>>>
>> I think you talk about users of hosts like smartphones, situated at
>> the edge of the Internet, not in the core.
>>
>> In straightforward IP addressing architectures ("hierarchical"),
>> the prefixes of routes towards the edges are naturally shorter than
>> that 64: e.g. prefix /60 for site, /63 for building, /64 for office
>> desk.
>
> sub entities request the numbers of /64's they need

Yes, that is when human planners make an architecture for a stable
situation, for a longer term like 10 years.

> and it uses a autoconfiguring routing protocol for routing traffic.

Except that edge computers caring about SLAAC/Ethernet/64 dont typically
run routing protocols, and even less autoconfiguring routing protocols.

> Homes and most sites don't need heirachical routing.  65000 routing
> entries should be able to be handled even by a $15 router.

Households: yes a 15eur a router can handle many routes;  but
househodls get one /64 from ISP, others get 16 such /64s, but no more.
However, the more IoT devices arrive the more subnets are needed in a
house network.  That will challenge the initial thoughts of the address
planners, again.

The /64 limit has become very popular thanks to SLAAC/Ethernet/64.  But
if one keeps the /64 limit in the standards one is bound to revisit the
initial address plans continuously.

If on another hand the /64 limit is removed, and SLAAC/Ethernet made to
allow for shorter-than-64 Interface IDs, or a new address autoconf
mechanism altogether (DHCP?), then one no longer needs to regularly
revisit initial addressing plans.  Well, maybe with a successor to
IPv6 but that would be much later.

>> implement. Because some hosts even in the core use
>> SLAAC/Ethernet/64, because edges expand, etc.
>>
>> particular /64 carved out of some other prefix, instead of
>> aggregating. This leads to waste of publically routable space, or
>> to the use of ULA prefixes, or NAT66 prefixes, which have
>> inconvenients too.
>>
>> Alex
>

Except it's not very sure to be able to dynamically request prefixes.

The places where this /64 limit is so visible, like cellular networks,
are precisely places where DHCPv6 Prefix Delegation is crucially absent.

Even if by specs (the theory) 3GPP mandates DHCPv6-PD, in practice
cellular operators oppose the use of DHCPv6-PD on smartphones.  The
reasons of this opposition are: one /64 is more than enough for many
devices (they dont understand SLAAC/Ethernet/64 and ptp links),
difficulty to revisit address plans, lack of DHCPv6-PD software at a
certain router manufacturer, etc.  One could write a 100-page report
about these reasons at cellular operators who dont reply to DHCPv6
PrefixDelegation requests.

Also, one could list a number of non-cellular network operators, and IT
departments, who also oppose DHCPv6 Prefix Delegation.  Each have their
reasons.

Because of that, I propose to avoid painting ourselves in an "ivory
tower" and imagine one could dynamically request /64 prefixes at a snap
of a finger...

Alex

Alex

>
>
>>> both of which benefit substantially to having a subnet size that
>>>  is always the same and never runs out of addresses.
>>>
>>> Even if you're right, the place to have that discussion is not on
>>> this document.
>>>
>>>
>>> [email-masked] Administrative Requests:

---

From: Job Snijders <[email-masked]>
Date: Wed, 22 Feb 2017 11:46:25 +0100

One of the immediate benefits of using a /126, is that it's not a /64! Also, a /126 is the smallest non-64 size with the highest likeliness to get the job done from an interoperability perspective (not the /127). Another example: when you use a /120, the advantage again is that it is not a /64, and you can make a bunch of routers talk BGP with each other on a layer-2 segment. This is why /126, /125, /124 etc end up being used.

An Addressing Architecture that does not admit this has been common practice for 15+ years, is disassociated from reality and thus inconsequential and no good. It does not follow that because you don't see enough advantages, the idea and practice are bad.

Kind regards,

Job

On 22 Feb 2017, 04:52 +0100, Lorenzo Colitti <[email-masked]>, wrote:
> On Wed, Feb 22, 2017 at 12:12 PM, Christopher Morrow <[email-masked] (mailto:[email-masked])> wrote:
> > > But the configuration cost and management overhead is not proportional to the hosts that are served by those interconnections, it is proportional to the number of interconnections. A 10x100G peering interconnection that serves X million hosts is one interface that has to be managed.
> >
> > "If you want to use /64 go ahead, if you want to use /121 go for it, if you want to use SLAAC you'll get a /64 and like it"
>
> Not sure. I for one wouldn't agree with that position, because I don't see that /121 has enough advantages over /127 and /64 - and few enough downsides for general-purpose hosts - to make it a good idea in general.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Feb 2017 23:17:09 +0900

Host developers and users do care what the prefix length is.

There are lots of things you can do if you know that the network will never
run out of addresses. For example, you can form new addresses at will and
use them for anything you want (privacy; per-application addresses, or
whatever else you can think of). Read RFC 7934 for a list of the things
we've thought of so far, and bear in mind that if this IPv6 thing even only
lasts as long as IPv4, that's still several decades, and I'm sure we'll
have lots of bright ideas during that time if we don't shortsightedly carry
over IPv4 practices motivated by address scarcity.

A fixed prefix length is also very beneficial because it allows hosts to
extend the network indefinitely at layer 2 without giving up the benefits
provided by autoconfiguration and end to end connectivity. It means that
ill-informed or ill-intentioned network administrators cannot use
addressing to constrain apps in a way that leads to suboptimal user
experience. That sort of thing obviously does not happen in the 2914 or
15169 backbone. It does happen in lots of other places.

On Wed, Feb 22, 2017 at 1:44 PM, Christopher Morrow <
[email-masked]> wrote:

>>>> to the hosts that are served by those interconnections, it is proportional
>>>> to the number of interconnections. A 10x100G peering interconnection that
>> Not sure. I for one wouldn't agree with that position, because I don't
>> see that /121 has enough advantages over /127 and /64 - and few enough

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Feb 2017 23:20:33 +0900

On Wed, Feb 22, 2017 at 7:46 PM, Job Snijders <[email-masked]> wrote:

> One of the immediate benefits of using a /126, is that it's not a /64!
>

That argument is nonsensical. You can't prove that A is better than B only
by saying that A is not the same as B.

> Also, a /126 is the smallest non-64 size with the highest likeliness to
> get the job done from an interoperability perspective (not the /127).
>

I don't see how you can simultaneously argue that /126 is good because
vendors don't implement the RFC 6164 and allow /127 AND that you want to
change the standard. If vendors don't implement the standard, then what
good does changing the standard do you?

---

From: Job Snijders <[email-masked]>
Date: Wed, 22 Feb 2017 15:41:47 +0100

> by saying that A is not the same as B.

Since you are unwilling to accept that there could be downsides to using
a /64, i understand the argument makes no sense to you. Reasonable
people can disagree with each other.

> > Also, a /126 is the smallest non-64 size with the highest likeliness
> > to get the job done from an interoperability perspective (not the
> > /127).
> 
> vendors don't implement the RFC 6164 and allow /127 AND that you want
> to change the standard. If vendors don't implement the standard, then
> what good does changing the standard do you?

Don't you see the common theme here? The "standard" is a red thread.

I'm advocating to align the Addressing Architecture documentation with
operational reality and operational expectations. If vendors support
/64-/127, and if operators use /64-/127 - then you should not insist
that anything non-/64 is invalid. Its not.

The 64-bit boundry is useful in some contexts [SLAAC], nobody is
disputing that. The boundry is not useful in every context, especially
in the case of explicit configuration, and the documentation should
reflect and acknowledge that fact. 

Why publish a document that conflicts with (almost) every deployed
global IPv6 backbone? This would be a farce.

Kind regards,

Job

---

From: David Farmer <[email-masked]>
Date: Wed, 22 Feb 2017 08:51:06 -0600

> assumptions about: "only ever 64 or 127".

I have to disagree with Chis slightly, /127 and /64 are slightly special,
in that they are clearly RECOMMENDED and the others (/126 through /65)
are NOT RECOMMENDED.  The problem we have is that some people think it
isn't enough to say /64 is only RECOMMENDED and want something stronger,
the stronger option is REQUIRED, and the current and historic text says
"required".  On the other hand we have people saying REQUIRED is too
strong, because it implies that /126 through /65 are not possible to use,
which is demonstrably false.

There is no universal (Internet wide) requirement, to make the Internet
work, that all interfaces have /64 as their as their prefix.  In fact as a
host on the other side of the Internet from me, you are forbidden from
making that very assumption, you must treat my 128 IPv6 address as opaque.

Their is a local requirement that all interfaces on the same link have the
same prefix.  The easies way to achieve this is to assume a fixed prefix
everywhere, and we picked /64 for that, and built it into SLAAC.  Once we
picked it, we have also built a whole bunch of other things that depend on
that pick, many of those other things are discussed in RFC7421.

Is the operational effort to utilize other prefix lengths (/126 through
/65) justified, including the issues discussed in RFC7421?  Most of the
time, probably NO, but some times, YES it is.  Here is the crux of this
issue, some of you think it is never justified.  But tough, this simply is
not your call, and again on the other side of the Internet you are not
supposed to care anyway.

Furthermore, as currently written it is easy to misinterpret the text as
implying that a configuration of something other than /64 MUST be ignored
or overridden.  My preferred solution is to simply change "required" to
"recommended" in the current text. I'd also be ok with saying /64 is
required for SLAAC, and recommended for everything else. But, If current
"required" is kept for everything, then it needs to be clarified who the
requirement is directed at, and that there are other exceptions than just
addresses that begin with 000. I think something like the following would
would deal with the first part;

   Other than the implications for Stateless Address
Autoconfiguration(SLAAC)[RFC4862],
   this requirement primarily constrains operators of IPv6 networks and
does not imply
   implementations of IPv6 are to ignore or override a configuration that
is in conflict with
   this requirement.

And as has been talked about, for the second part we can enumerate the
exceptions or say that there are other standards track exceptions beyond
just the addresses that begin with 000.

Thanks.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Feb 2017 23:53:29 +0900

> people can disagree with each other.

I stand by the position that "/126 is better than /64 because /126 is not
/64" is a nonsensical argument. Saying "/126 is better than /64 due to
reasons A, B, C, ..." will likely be more effective - well, depending on
what A, B and C are. But I haven't heard much in the way of supporting
evidence from you other than "my network uses lots of prefix lengths thus
/64 is bad". That in itself is not convincing to me. Perhaps I am missing
something else you said?

> global IPv6 backbone? This would be a farce.

"Conflicts with the NTT backbone" != "conficts with almost every deployed
backbone". The backbone I am familiar with uses a combination of /127, /64,
and link-local point to point interfaces, or at least it did last time I
checked.

Also, backbone networks are a tiny percentage of the links on the planet.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 00:21:56 +0900

On Wed, Feb 22, 2017 at 11:51 PM, David Farmer <[email-masked]> wrote:

> work, that all interfaces have /64 as their as their prefix.
>

Where "make the Internet work" means what, exactly? I assume you don't mean
"experiences no loss in functionality" - all it takes is one implementation
that breaks when configured with a non-/64 prefix to make the statement
false.

That might seem like a specious distinction, but if you think about it more
broadly, then I think you'll agree that "work" is not black and white, and
also covers degraded functionality. In which case it's absolutely true that
moving away from /64 everywhere is going to cause some amount of loss of
functionality. The question is how much, and whether that's acceptable.

> same prefix.

Actually, there isn't. The requirement for working communication is that
all hosts are configured with a prefix length that covers all hosts on the
link (or, more narrowly, all hosts they want to talk to). It IS a
requirement in IPv4 because of the broadcast address, but it's not in IPv6.
Again, this might seem like nitpicking, but if you think about it some
more, I think you might realize that some of what is being written on this
thread is based on unstated assumptions that are not necessarily correct,
and in many cases based only on IPv4 practices where they were actually
necessary for reasons that are no longer applicable in IPv6.

> issue, some of you think it is never justified.
>

I think this is where the disconnect lies. As a host OS developer and app
developer, my work is not impacted by what you, Job, or Chris, individually
do in your networks. My work is impacted by the minimum common denominator,
because that is what constrains the code I need to write.

If we don't have a fixed subnet size, that minimum common denominator
quickly ends up being /128-to-the-host. I don't want to end up at /128
because it makes my code more complex and brittle and my users' experience
much more battery intensive and less reliable. (Again, see RFC 7934.)

If we do have a fixed subnet size, and the only loss is that that backbone
operators cannot use RFC 4291bis to complain if host vendors refuse to
implement configuring /117 prefixes on their links, then I truly believe
that that is a better outcome for the Internet as a whole. As you point
out, /117 already "works", anyway - at least in your definition of "works".

When I was still involved in writing its addressing plans, the backbone I
am familiar with ran on a mix of /127, link-local point to point, and
/64-to-the-rack with some operational measures to defend against ND cache
exhaustion attacks. I never found the lack of /117 prefix lengths to be a
limitation.

---

From: Job Snijders <[email-masked]>
Date: Wed, 22 Feb 2017 16:31:29 +0100

On Wed, Feb 22, 2017 at 11:53:29PM +0900, Lorenzo Colitti wrote:
> > > That argument is nonsensical. You can't prove that A is better
> > > than B only by saying that A is not the same as B.
> >
> > Since you are unwilling to accept that there could be downsides to
> > using a /64, i understand the argument makes no sense to you.
> > Reasonable people can disagree with each other.
> 
> I stand by the position that "/126 is better than /64 because /126 is
> not /64" is a nonsensical argument. Saying "/126 is better than /64
> due to reasons A, B, C, ..." will likely be more effective - well,
> depending on what A, B and C are. But I haven't heard much in the way
> of supporting evidence from you other than "my network uses lots of
> prefix lengths thus /64 is bad". That in itself is not convincing to
> me. Perhaps I am missing something else you said?

Apologies to the working group for having to repeat these refences
again.

rfc6164 and rfc6583 are great examples that document considerations
regarding not using a /64, it simply is not always the best fit. Their
very existence show me that one can legitimately state "i want to use
something other then a /64".

The tandem of RFC 3627 and RFC 6164 is what caused both /126 and /127 to
become popular in operational circles. While /126 does not enjoy the
same recognised status as /127 from an IETF paperwork perspective, that
doesn't invalidate its use and existence.

Of course it is possible that two people look at the same data and
arrive at different conclusions.

> "Conflicts with the NTT backbone" != "conficts with almost every
> deployed backbone".

You gross over the fact that NTT connects with many other backbones, and
that the data I shared is a reflection on both NTT's own addressing
structure as well as peering partner's or customer's addressing. When
NTT interconnects with another network, both parties have to agree on a
prefix and prefix length, and which party will use what IP address.
Thus, if the other party proposes and configures a /126, NTT will also
configure a /126.

As such, I am confident to state that almost every deployed backbone
uses a mixture of /64, /127, /126 and perhaps other lengths. This
information can also be gleaned from public resources such as PeeringDB,
public BGP Looking Glasses and hallway conversations at IETF.

> The backbone I am familiar with uses a combination of /127, /64, and
> link-local point to point interfaces, or at least it did last time I
> checked.

There is public data that suggests that the backbone you are familiar
with might be connected to a public internet exchange which uses a /112
as peering lan prefix. I hope this won't cause an existential crisis!

Of course one such anecdotal datapoint is worthless, and perhaps it is
childish of me to bring it up. I hope you'll share my amazement at all
the curious things that together form the internet. :-)

The key point here is that there is a larger pattern of '/64 avoidance'
amongst internet backbone operators, and that needs to be acknowledged
in the Addressing Architecture document. There have been numerous
suggestions to improve the text.

> Also, backbone networks are a tiny percentage of the links on the planet.

I certainly will not deny that fact. Are you familiar with the concept
of the McNamara fallacy?

Kind regards,

Job

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 00:56:45 +0900

On Thu, Feb 23, 2017 at 12:31 AM, Job Snijders <[email-masked]> wrote:

> regarding not using a /64, it simply is not always the best fit.
>

RFC6583-style attacks (of which the class addressed by RFC6164 is a subset)
are low payoff and pretty easy to mitigate using very small changes to ND
implementations. You can solve most or all of the problem by using
per-interface ND queues and prioritizing existing and gleaned ND entries
over incomplete ones. You can do even better by pushing the filtering away
from the host so that you don't have to carry the packets.

Also, bear in mind that the interface ID length is *not* the same as the
prefix you route to the link. Given that you're talking about static
configuration, you can perfectly well configure all the hosts with /64
prefixes, but give them addresses that are all in a given /120 and then
route only the /120 to that link. That will also avoid all the attacks.

It also makes configuration much simpler, because you don't have to touch
any of the hosts when you run out of the /120: just increase the /120 to a
/119 on the router and move up from ::ff to ::100. That is 100% supported
by the current text of RFC4291bis, which requires that the router forward
packets to the /120.

This trick doesn't work in IPv4, so it will take a bit of getting used to
for people who only know IPv4, but I doubt that's the common case in NTT.

> uses a mixture of /64, /127, /126 and perhaps other lengths.

...

> as peering lan prefix.

For the record, I don't dispute either of those.

> I certainly will not deny that fact. Are you familiar with the concept

I wasn't. But that fallacy would apply to your arguments just as well as to
mine. You're the one that brought numbers to the thread first.

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Feb 2017 04:42:24 +1100

<snip>

>Have you read rfc1925 section 2.4?

My operational experience is why I value simplicity, consistency and
less variation, as I've worked on and troubleshooted networks that
have been unnecessarily complex.

I think RFC1925 2.12 is more important.

> You are grossly overstating these 'operational savings'.

I've seen 4x/24s on a router interface because renumbering hosts into
a single /22 was operationally too expensive. Those hosts also were
being left with default "class B" subnet masks because that was
allowing their broadcast based discovery to work. Fortunately their
router was performing proxy ARP which then allowed them to access
other off-link destinations within the Class B address space.

I've seen a router with 25 subnets on its interface because they were
collapsed down from many PCs acting as routers, and renumbering the
hosts into a single large enough prefix was too operationally
expensive. That also meant the router was sending two RIP packets for
each update because the limit is 25 routes in a RIP packet.

If you see those sorts of things, and have experience with other
protocols like IPX where subnets are always large enough for any
number of devices the layer 2 technology can support, you value the
simplicity of /64s everywhere, even on links with two addresses.

>Also, for the

>is exhibited in that you do not wonder _why_ things are what they are.

I know quite well why IPv4 has been operated the way it has.

Your data doesn't measure motivation.

If I see a set of prefix lengths in IPv6 that vary like IPv4 ones
would, which is what your data set showed, then I think the motivation
is that IPv4 addressing methods and thinking have been applied to
IPv6.

If your mix of prefix lengths was only /64s, or only /64s and /127s,
then I think that shows an understanding of IPv6 addressing models and
intents.

A lot of IPv4's addressing models and methods are a consequence of
IPv4 never being designed to be used to build the Internet we have
today.

Here's what Vint Cerf has said about IPv4's address size and design context.

http://mailman.nanog.org/pipermail/nanog/2010-April/020488.html

IPv4 was designed for a research network that escaped and became a
global network. IPv6 is really the first protocol designed by the IETF
to solve a global internetwork problem. Let's leave behind unnecessary
practices that have been used to extend IPv4's life, and that make
things unnecessarily complicated and more costly to operate and
troubleshoot.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 02:46:25 +0900

On Thu, Feb 23, 2017 at 2:42 AM, Mark Smith <[email-masked]> wrote:

> Let's leave behind unnecessary practices that have been used to extend
> IPv4's life, and that make things unnecessarily complicated and more costly
> to operate and troubleshoot.
>

What he said.

---

From: David Farmer <[email-masked]>
Date: Wed, 22 Feb 2017 12:01:58 -0600

>> to operate and troubleshoot.

Yes, what he said is a very compelling argument to use /64 in most places,
the default. However, you cannot extrapolate there exists no places were
something other than /64 make sense.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 03:04:46 +0900

>From a complexity, reliability, and cost point of view, it is likely better
to say that everything should be /64 rather than say that 99.9% of links
will be /64 or /128 but we still need to support other prefix lengths for
0.1% of cases.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 22 Feb 2017 20:02:34 +0100

Le 21/02/2017 à 18:27, Job Snijders a écrit :
>>> 'draft-ietf-6man-rfc4291bis-07.txt'), which is in IETF Last
>>> call, which means it is in a place to discuss the contents of
>>> that draft. No reason to kick the can down the road.
>>
>> I'm sorry, but that's really how it is. The text you dislike has
>> been the standard for almost 20 years, and is it inappropriate to
>> change it in the context of reclassifying this document from draft
>>  standard to Internet standard.
>
> Or, perhaps it is inappropiate for the -bis document to target
> "Internet Standard" classification at this moment? ¯\_(ツ)_/¯
>
> Especially when solidifying recommendations in an architecture
> Internet Standard-to-be, the utmost care should be taken to verify
> whether the paper reality (RFCs) and operational reality (what people
> do, for $reasons) are aligned.
>
> /64 is not the "be all and end all". The current paragraph does not
> account for staticly configured environments in which SLAAC plays no
>  role.
>
> OLD: IPv6 unicast routing is based on prefixes of any valid length up
> to 128 [BCP198].  For example, [RFC6164] standardises 127 bit
> prefixes on inter-router point-to-point links.  However, the
> Interface ID of all unicast addresses, except those that start with
> the binary value 000, is required to be 64 bits long.  The rationale
>  for the 64 bit boundary in IPv6 addresses can be found in [RFC7421]
>
> NEW: IPv6 unicast routing is based on prefixes of any valid length up
> to 128 [BCP198]. When using [SLAAC], [ILNP], or [NPT66] the Interface
> ID of unicast addresses is required to be 64 bits long. In other use

I agree with the NEW paragraph if Ethernet is mentioned, and if its last
paragraph gets updates.

I propose this:
NEW NEW:
> 128 [BCP198]. When using [SLAAC]/[Ethernet], [ILNP], or [NPT66] the
> Interface ID of unicast addresses is required to be 64 bits long. In
>  other use cases different prefix sizes may be required. For example
>  [RFC6164] standardises 127 bit prefixes on inter-router
> point-to-point links.  Prefix lengths of 64 bits were observed on
> popular connections and are taught on IPv6 lectures.  Prefix lengths
> of 96 bits were observed at Virtual Machine providers.

[note SLAAC alone can work with /65 too]

> OLD: As noted in Section 2.4, all unicast addresses, except those
> that with the binary value 000, Interface IDs are required to be 64
> bits long.
>
> NEW: *delete, its superfluous*

I agree.  But I dont know whether registries have not set this 000 apart
for maybe 200 years later or so. (it may sound not serious, but I know
there are serious public plans for such long term on other matters).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 22 Feb 2017 20:04:21 +0100

cost?

Let us talk cost... how much does it cost to get a /64 on a cellular 
network?  It's around 5Eur here.  How much does it cost to get a /56?

Alex

Le 22/02/2017 à 19:04, Lorenzo Colitti a écrit :
> From a complexity, reliability, and cost point of view, it is likely
> better to say that everything should be /64 rather than say that 99.9%
> of links will be /64 or /128 but we still need to support other prefix
> lengths for 0.1% of cases.
>
> On Thu, Feb 23, 2017 at 3:01 AM, David Farmer <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     On Wed, Feb 22, 2017 at 11:46 AM, Lorenzo Colitti
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         On Thu, Feb 23, 2017 at 2:42 AM, Mark Smith
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Let's leave behind unnecessary practices that have been used
>             to extend IPv4's life, and that make things unnecessarily
>             complicated and more costly to operate and troubleshoot.
>
>
>         What he said.
>
>
>     Yes, what he said is a very compelling argument to use /64 in most
>     places, the default. However, you cannot extrapolate there exists no
>     places were something other than /64 make sense.
>
>     --
>     <mailto:[email-masked]>

---

From: David Farmer <[email-masked]>
Date: Wed, 22 Feb 2017 13:24:54 -0600

I'm perfectly fine with "should be" or even "almost alway", but that's not
"required", "must be", or "always", just like 5 - 9s uptime isn't never
have an outage.  And yes you still need to deal with that 0.1% or 0.0001%
in the case of 5 - 9s, there is no way off that hook.

On Wed, Feb 22, 2017 at 12:04 PM, Lorenzo Colitti <[email-masked]>
wrote:

> better to say that everything should be /64 rather than say that 99.9% of
> links will be /64 or /128 but we still need to support other prefix lengths
> for 0.1% of cases.
>
>> places, the default. However, you cannot extrapolate there exists no places
>> were something other than /64 make sense.
>>
>> --

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 22 Feb 2017 19:46:28 +0000

Observing this thread, this seems to be the minority opinion. And I suppose it’s normal that people would generalized based on their personal experiences.

My experience is one of being allocated address blocks per platform, and having a very strong incentive to make these work over the long haul. As such, arbitrary constraints, such as /64, don’t seem like a flexible design at all.

Plus, for those who opine that “everyone” should be allocated a /48, I’d suggest two problems with that notion. First, it does not reflect today’s reality. And secondly, it seems quite limiting. No better than MAC addresses, which by now we know are hardly “guaranteed” to be globally unique.

IoT changes all of our preconceived notions about what is “ample.”

From: ipv6 [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Wednesday, February 22, 2017 12:46
To: Mark Smith <[email-masked]>
Cc: 6man WG <[email-masked]>; [email-masked]; [email-masked]; IETF <[email-masked]>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

On Thu, Feb 23, 2017 at 2:42 AM, Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:
Let's leave behind unnecessary practices that have been used to extend IPv4's life, and that make things unnecessarily complicated and more costly to operate and troubleshoot.

What he said.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Feb 2017 09:20:32 +1300

On 23/02/2017 03:41, Job Snijders wrote:
...
> global IPv6 backbone? This would be a farce.

Job is correct, and I think the document editor can find one of the
various proposed formulations that avoids the farce.

Nobody is saying that /64 isn't extremely widely used where it's
appropriate to have a portable fixed length IID. Set the default
at 64 and trust operators to change it where they need to.
That's realistic.

     Brian

---

From: Randy Bush <[email-masked]>
Date: Thu, 23 Feb 2017 03:25:43 +0700

> structure as well as peering partner's or customer's addressing.

face it job.  what we have here is non-ops telling us what we should do
and denying what we actually do and intend to keep doing.  welcome to
the ietf; we want ops here but that does not mean we want to listen to
them.

this is not new.  this is the last classful sickness needing expunging
from ipv6.  it has been a long trail.  you would have loved the insanity
of NLA/TLA; and it took some years of bloodshed to get rid of them.

randy

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 09:41:43 +0900

> at 64 and trust operators to change it where they need to.

As a host developer I strongly oppose that. It will make life easier for
network operators but make life harder for host OS developers, host
operators, and host users.

And it is absolutely inappropriate to change this now in given that the /64
boundary has been the standard for the last 20 years. It will break
deployed code that relies on the current standard. (That includes concrete
code I can point to that I know runs on tens of millions of devices.)
That's not acceptable to do in a standard reclassification.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 09:50:00 +0900

> the ietf; we want ops here but that does not mean we want to listen to

Host developers could just as well claim "this is just network ops telling
us what we should do do and denying what we actually do and intend to keep
on doing".

With the difference that the standards clearly specify what the current
state of affairs is.

---

From: Randy Bush <[email-masked]>
Date: Thu, 23 Feb 2017 07:56:15 +0700

> us what we should do do and denying what we actually do and intend to keep

how is that working out for dual-stack and dhcp android users?

> With the difference that the standards clearly specify what the current

and now we need to make the wannabe document match what the state of
affairs is in networking.

randy

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 10:50:49 +0900

> how is that working out for dual-stack and dhcp android users?

What do you mean? Are you saying that host developers don't always and
automatically do what network operators want them to do? If that's
motivated by the fact that they are acting in their users' interests, it
seems to me that they are justified in doing so, and in fact, would be
remiss not to.

> affairs is in networking.

That doesn't mean "we've been violating the standards, so now the standards
have to change to match what we've been doing, even if other parties are
depending on the standards", does it? :-)

---

From: Randy Bush <[email-masked]>
Date: Thu, 23 Feb 2017 09:11:50 +0700

> As a host developer I strongly oppose that. 

as a network operator, i strongly opposed classfulness and will hold my
breath and have a tantrum.

> It will make life easier for network operators but make life harder
> for host OS developers, host operators, and host users.

users do not notice, except when device programmers break things.  i am
a host operator, and i do not need classfulness.  slaac is nice in small
lans, and the /64 id is fine for the slaac niche.

> And it is absolutely inappropriate to change this nowin given that the /64
> boundary has been the standard for the last 20 years. 

the other week you were saying i should be patient and we could change
it in another decade from now.  now you say forever, it's cast in
concrete.

well, we are breaking that concrete, have broken it for years, and it's
time 6man wakes up, smells the coffee, and gets with reality.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Feb 2017 16:44:01 +1300

> operators, and host users.

I'm sorry, I'm wondering which word in my recent message that said
"I'm not aware of any generally available running code that will
be changed in even one instruction by the final text - that is indeed
a requirement for advancement to Internet Standard."
is hard to understand.

We are not suggesting to change the /64 usage in all the hosts that need to
use it. We are simply pointing out other nodes do and will behave differently.
/64 is an interop requirement on links that use /64. It is not an interop
requirement on links that don't use /64. RFC4291 is mistaken about this.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 13:13:29 +0900

> lans, and the /64 id is fine for the slaac niche.

Please think about the arguments in RFC 7934. If some misguided operator
assigns your device exactly one IPv6 address, that hugely constrains what
the device can do and how well it does it. And I do think that users notice
when their network is flaky.

> it in another decade from now.  now you say forever, it's cast in

Sorry, let me clarify: it is inappropriate to change that now *in this
document*. As I said elsewhere, the IETF and 6man absolutely have the
ability to change the standard, but it should follow the proper process:
write a draft, get consensus, update whatever RFC RFC 4291bis eventually
becomes. I'm not saying we need to wait a decade.

(I do also happen to think that it would be better if we waited a decade
before changing this, because we're only 5 or so years into large-scale
deployment that will hopefully last at least 3 or 4 decades. However, I
don't expect many people to agree with me on that, so I'm not trying to
make that argument here.)

> time 6man wakes up, smells the coffee, and gets with reality.

What you do in your network is your business. If it works for you - which
we know it does - I have no problem with that. What I have a problem with
is when someone tells me that OS code needs to change because some operator
thinks that "we give this network a /120 subnet makes sense because that
matches the /24 we use IPv4, and we should be free to do that".

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 13:16:46 +0900

> a requirement for advancement to Internet Standard."

Help he understand, then. There is widely-deployed code that assumes that
the interface ID is 64 and does not work on anything other than 64 bit
prefix lengths. Currently that code is correct on all unicast space. If you
change RFC 4291, won't that code be incorrect?

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Feb 2017 01:25:30 -0300

On 02/23/2017 01:13 AM, Lorenzo Colitti wrote:
> On Thu, Feb 23, 2017 at 11:11 AM, Randy Bush <[email-masked]
> <mailto:[email-masked]>> wrote:
[...]
> make that argument here.)

Isn't that actually an argument for waiting before moving rfc4291bis to
full standard?

If you'd wait to change it, why would you want to cast this into stone
now? So that, later you can argue that "it's a full standard document...
so we shouldn't change it"?

---

From: Randy Bush <[email-masked]>
Date: Thu, 23 Feb 2017 11:28:28 +0700

> the IETF and 6man absolutely have the ability to change the standard,
> but it should follow the proper process: write a draft, get consensus,

that is the process we are currently in.  but there seems to be serious
disagreement over the draft.

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 23 Feb 2017 11:34:08 +0700

> prefix lengths.

if you have code which is hard coded to want to be on a network with a
17.5 bit netmask, then put it on networks with 17.5 bit masks.  enjoy.

unless it is doing something useful with that restriction, such as
slaac, you're severly restricting the usability of your product.  your
choice.

randy

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 23 Feb 2017 04:39:18 +0000

> Help he understand, then. There is widely-deployed code that assumes
> that the interface ID is 64 and does not work on anything other than
> 64 bit prefix lengths. Currently that code is correct on all unicast
> space. If you change RFC 4291, won't that code be incorrect?

This shows precisely why it is urgent to update RFC 4291, to correct that notion of a fixed IID, before it's too late to set things straight again.

RFC 4291 describes any number of address prefixes that are not /64. For example:

   IPv6 unicast addresses are aggregatable with prefixes of arbitrary
   bit-length, similar to IPv4 addresses under Classless Inter-Domain
   Routing.

Important point. Arbitrary length. That does not mean 64 bits.

And

   |          n bits               |           128-n bits            |
   +-------------------------------+---------------------------------+
   |       subnet prefix           |           interface ID          |
   +-------------------------------+---------------------------------+

This next needs to be clarified/corrected, as it should only apply to the 2000::/3 space:

   All Global Unicast addresses other than those that start with binary
   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
   described in Section 2.5.1.  Global Unicast addresses that start with
   binary 000 have no such constraint on the size or structure of the
   interface ID field.

Bert

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 14:58:01 +0900

On Thu, Feb 23, 2017 at 1:39 PM, Manfredi, Albert E <
[email-masked]> wrote:

> This shows precisely why it is urgent to update RFC 4291, to correct that
> notion of a fixed IID, before it's too late to set things straight again.
>

Ok, so you're suggesting that we drop the attempt to reclassify RFC 4291,
and instead write a new document to update it? That's a possible course of
action. It would only result in your desired outcome if there was rough
consensus to change the boundary, but as I said before, I'm not going to
oppose that course of action.

> Important point. Arbitrary length. That does not mean 64 bits.

Nobody is disagreeing with that text. Please refer to the earlier
clarifications in this thread and the discussion in 6man that pointed out
that *routing* based on prefix lengths != 64 is independent from *interface
IDs* being required to be 64 bits long or not.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 14:59:39 +0900

> 17.5 bit netmask, then put it on networks with 17.5 bit masks.  enjoy.

That would be correct behaviour if the standard specified that IIDs are
17.5 bits long.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 15:05:03 +0900

> disagreement over the draft.

AIUI the goal of the process is to reclassify the current specification.
That severely restricts the types of changes that are possible. That is the
basis on which this document gained WG consensus and reached IETF last call.

If we want to say that we're no longer reclassifying the current
specification but are instead opening the door to bigger changes, then the
document should go back to the WG for further work because the existing WG
consensus was based on the stated goal of reclassifying the document.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 15:24:45 +0900

> so we shouldn't change it"?

I don't see why that argument would carry any weight. Full standards can be
changed and updated, too.

What I most care about is that if we make fundamental changes like this,
then it's not done as part of a reclassification, and the working group has
its say.

Whether the document says "full standard" or "draft standard" is not as
important as whether it says the right thing.

---

From: Erik Kline <[email-masked]>
Date: Thu, 23 Feb 2017 15:58:41 +0900

> consensus was based on the stated goal of reclassifying the document.

I agree with the procedural concerns here.  Among other things, if we make
substantial changes it's hard to claim we have experience running the new
thing we've documented.

I tend to think of IID concept's primary use as: if I have the IID
::dead:beef/64 then for every new /64 PIO that's announced *I* can
reasonably expect to lay claim to prefix1::dead:beef/64,
prefix2::dead:beef/64, and so on.  (Support for this mode operations,
SLAAC, is a MUST.)

I don't personally find any major conflict when considering static and
stateful addressing.  For example, if there are 2 prefixes on a link, and
the administrators are using static addressing then prefix1::cafe and
prefix2::cafe do not in any way have to belong to the same interface on the
same host. ... at least as far as I understand it.  If prefix1 and prefix2
are each longer than /64 then each 64bit IID would still be unique--no
problems.  But if each were <=64 then it's just violating a recommendation
in the first paragraph of 2.4.1--not a big deal for the administrator that
wants to run that way.

I'm not sure if this adds anything useful to the discussion, though.
-Erik

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Feb 2017 04:33:50 -0300

On 02/23/2017 03:24 AM, Lorenzo Colitti wrote:
> On Thu, Feb 23, 2017 at 1:25 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> I don't see why that argument would carry any weight. Full standards can
> be changed and updated, too.
> 
> then it's not done as part of a reclassification, and the working group
> has its say.
> 

Exactly. And if a document does not reflect operational reality, it has
a big problem.

My understanding is that Randy et al are trying to get rfc4291bis to
reflect operational reality, but you want to progress the document with
no changes, essentially meaning that you want to publish a document as
full standard which doesn't agree with how the protocol is being deployed.

If, even at the time of publication our documents already do not reflect
reality, we are not going to be taken seriously.

If you're argument is that we cannot do what is right because moving
rfc4291 to full standard doesn't allow it, then you're implicitly asking
not to move rfc4291bis to full standard (or are just aasking us to do
the wrong thing).

Thanks,

---

From: Erik Kline <[email-masked]>
Date: Thu, 23 Feb 2017 16:49:02 +0900

> not to move rfc4291bis to full standard (or are just aasking us to do

Actually, I was saying that I don't see that there's a real problem with
the current text.

---

From: [email-masked]
Date: Thu, 23 Feb 2017 09:12:54 +0100 (CET)

> change RFC 4291, won't that code be incorrect?

Since there are plenty of addresses with non 64bit IIDs in use, isn't
that code by definition *already* broken? I don't see how changing the
4291bis document to reflect operational reality makes the code any
more broken.

Steinar Haug, AS2116

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Feb 2017 05:17:57 -0300

On 02/22/2017 09:41 PM, Lorenzo Colitti wrote:
> On Thu, Feb 23, 2017 at 5:20 AM, Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> And it is absolutely inappropriate to change this now in given that the
> /64 boundary has been the standard for the last 20 years. It will break
> deployed code that relies on the current standard. (That includes
> concrete code I can point to that I know runs on tens of millions of
> devices.) That's not acceptable to do in a standard reclassification.

If the above will break your code, then your code is already broken. Fix it.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Feb 2017 05:20:43 -0300

On 02/22/2017 10:50 PM, Lorenzo Colitti wrote:
> That doesn't mean "we've been violating the standards, so now the
> standards have to change to match what we've been doing, even if other
> parties are depending on the standards", does it? :-)

Oh, well... you said this exact words at the 6man wg meeting in Seoul,
when you were suggesting that we should allow EH insertion because some
folks had implemented and deployed code that was violating RFC2460.

Looks like you like to bend the rules depending on what you want to push
forward.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 17:25:08 +0900

> full standard which doesn't agree with how the protocol is being deployed.

I think we all agree that the document doesn't agree with what Randy et al
deployed, because the document matches the existing standard and Randy et
al chose to violate the standard. What I'm saying is:

   1. The "operational reality" that Randy et al want to match is not
   widely deployed (in terms of number of links). The overwhelming majority of
   links on the Internet (of which backbone links are just a small number)
   follow the standards.
   2. There are hosts that follow the standards and only support /64 in
   some cases, or rely on /64 to provide useful functionality. Changing the
   standards to match said limited operational reality will render those hosts
   noncompliant.
   3. We should not render compliant hosts noncompliant because a minority
   of links purposely violated the standards.

> reality, we are not going to be taken seriously.

But they do reflect reality. If you look at the whole Internet, think there
are probably 1000 /64 links for every /65-126 link deployed today. Removing
the fixed /64 boundary will cause way more than 0.1% of hosts - which
*correctly* implemented a fixed /64 IID - to become noncompliant. Thus,
changing the document as suggested by Randy et al will actually cause the
document to reflect reality less than it does today.

Repeating a "classful addressing is bad" mantra isn't going to change those
facts.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 17:26:47 +0900

> If the above will break your code, then your code is already broken. Fix

Nope. That code implements the standard, and thus by definition it's not
broken.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 17:27:44 +0900

> folks had implemented and deployed code that was violating RFC2460.

If you want to accuse me of inconsistency, please quote me literally and in
context.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 23 Feb 2017 09:44:10 +0100

Le 23/02/2017 à 05:13, Lorenzo Colitti a écrit :
> assigns your device exactly one IPv6 address, that hugely constrains
> what the device can do and how well it does it. And I do think that
> users notice when their network is flaky.
>
>
> What you do in your network is your business. If it works for you -
> which we know it does - I have no problem with that. What I have a
> problem with is when someone tells me that OS code needs to change
> because some operator thinks that "we give this network a /120 subnet
> makes sense because that matches the /24 we use IPv4, and we should be
> free to do that".

You are not forced to change OS code: DHCPv6 runs in the userspace.

Alex

---

From: [email-masked]
Date: Thu, 23 Feb 2017 09:47:11 +0100 (CET)

> are probably 1000 /64 links for every /65-126 link deployed today.

1000 /64 links for every /65-126 link may well be the case. However,
plenty of non /64 links exist, and I see no sign of them going
away. Claiming that all IIDs are 64 bit is simply incorrect, and
doesn't reflect operational reality no matter how hard you try to
make that claim.

At least the ISP I work for will make sure (through RFP requirements
etc) that /65-126 links *continue to work*.

Steinar Haug, AS2116

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Feb 2017 06:01:54 -0300

On 02/23/2017 05:25 AM, Lorenzo Colitti wrote:
> On Thu, Feb 23, 2017 at 4:33 PM, Fernando Gont <[email-masked]
[...]
> 
> 
> But they do reflect reality. If you look at the whole Internet, think
> there are probably 1000 /64 links for every /65-126 link deployed today.
> Removing the fixed /64 boundary will cause way more than 0.1% of hosts -
> which *correctly* implemented a fixed /64 IID - to become noncompliant.

The proposed fix is to stick to /64 for slaac, and make /64 the default
for other cases (while allowing the operator to override it).

If your comment above was made on the basis that hosts would be
non-compliant because some might not be able to e.g. be configured with
a longer-than-64 prefix, then... that's what usually happens as you
update a spec.

OTOH, if your point is that we cannot do that in the process of moving
this document to full standard, my take is that it's better and more
productive to get the document right, than to cast it into stone "no
matter what".

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 23 Feb 2017 10:03:27 +0100

Le 23/02/2017 à 07:58, Erik Kline a écrit :
> On 23 February 2017 at 15:05, Lorenzo Colitti <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Thu, Feb 23, 2017 at 1:28 PM, Randy Bush <[email-masked]
>     AIUI the goal of the process is to reclassify the current
>     specification. That severely restricts the types of changes that are
>     possible. That is the basis on which this document gained WG
>     consensus and reached IETF last call.
>
>     specification but are instead opening the door to bigger changes,
>     then the document should go back to the WG for further work because
>     the existing WG consensus was based on the stated goal of
>     reclassifying the document.
>
>
> I agree with the procedural concerns here.  Among other things, if we
> make substantial changes it's hard to claim we have experience running
> the new thing we've documented.
>

No.  It is a MAY.  When doing manual configuration one does need to run 
SLAAC too.

Alex

> stateful addressing.  For example, if there are 2 prefixes on a link,
> and the administrators are using static addressing then prefix1::cafe
> and prefix2::cafe do not in any way have to belong to the same interface
> on the same host. ... at least as far as I understand it.  If prefix1
> and prefix2 are each longer than /64 then each 64bit IID would still be
> unique--no problems.  But if each were <=64 then it's just violating a
> recommendation in the first paragraph of 2.4.1--not a big deal for the
> administrator that wants to run that way.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 18:03:35 +0900

> doesn't reflect operational reality no matter how hard you try to

I'm not saying that all IIDs are 64 bits. I'm saying that as a percentage
of the Internet, more code is deployed that expects/requires 64 bit IIDs
than links than non-/64 links. So if we want to make the standard reflect
reality, then we should keep it as is.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 23 Feb 2017 11:20:53 +0100

>That's not acceptable to do in a standard reclassification.

Lorenzo,

I'm curious about the issues the host developer faces.

It seems to me that there are three basic ways of configuring addresses:
1) SLAAC
2) DHCP IA_NA
3) Manual

There is of course also DHCP IA_PD, but I'll leave that out for the moment
as it is not directly relevant to IIDs.

For DHCP IA_NA, the host should not care about the length of the IID. The
host just configures the address as a whole. Not need to look at the prefix
length.

With manual configuration, again the host doesn't care. If is possible that
manual configuration is done using IIDs. But combining an IID and a prefix is
not magic. There is no reason why manually configured IIDs whould have to be
64 bits.

Then there is SLAAC. I'm fully on board to say that SLAAC should require
64 bit IIDs for ever. 

So it seems to me that there are operators that want to use longer prefixes
with manual configuration and you want to keep SLAAC at 64-bit. That sounds
perfectly consistent.

I can't think of any reason why IA_NA or manually configured IIDs would have
to be 64 bit. 

So a text like 'implementations MUST support 64-bit IIDs for SLAAC.
implementations SHOULD support other lengths for other ways of configuring
addresses (IA_NA, manual).' should work. Or did I miss something?

---

From: Pierre Pfister <[email-masked]>
Date: Thu, 23 Feb 2017 11:24:33 +0100

Hello all,

>  in IETF standards track documents.

The only place in IPv6 standards where the 64 boundary is mandated is on the 2000::/3 rule.
There is not a single implementation or deployment of that rule. There is no instance where 
trying to configure a prefix of length different than 64 will work when the prefix is within 2000::/3, and fail when it is not.
That is a sufficient reason to not include this rule as part of the standard track.

Nevertheless, SLAAC over Ethernet links indeed requires prefix length of 64.
As documented in the RFC7421, there are a few examples of protocols which require 64 bits long interface identifiers.

SLAAC is not the only way to configure IPv6 hosts though.
Manual configuration, automated configuration, and DHCP are all IETF approved ways of configuring IPv6 hosts. 
They all work with prefixes of various lengths. 
Does 'special cases' in the proposed text covers manual/automated configuration or DHCP ? If so, it is far from being clear.

You obviously should use /64s if you want SLAAC to work, as well as other protocols which are documented in RFC7421,
but /64 is not the rule, it is an architectural consideration that you have to take into account when you design your network depending on the protocols that you want to run there.

Therefore, as far as this discussion is concerned, there is no reason to mandate 64 bits boundaries as part of the IPv6 specification.

- Pierre

---

From: Job Snijders <[email-masked]>
Date: Thu, 23 Feb 2017 12:37:05 +0100

On Thu, Feb 23, 2017 at 12:56:45AM +0900, Lorenzo Colitti wrote:
> RFC6583-style attacks (of which the class addressed by RFC6164 is a
> subset) are low payoff and pretty easy to mitigate using very small
> changes to ND implementations. You can solve most or all of the
> problem by using per-interface ND queues and prioritizing existing and
> gleaned ND entries over incomplete ones. You can do even better by
> pushing the filtering away from the host so that you don't have to
> carry the packets.

The perfect solution is always just one upgrade away! :-)

> Also, bear in mind that the interface ID length is *not* the same as
> the prefix you route to the link. Given that you're talking about
> static configuration, you can perfectly well configure all the hosts
> with /64 prefixes, but give them addresses that are all in a given
> /120 and then route only the /120 to that link. That will also avoid
> all the attacks.
> 
> It also makes configuration much simpler, because you don't have to
> touch any of the hosts when you run out of the /120: just increase the
> /120 to a /119 on the router and move up from ::ff to ::100. That is
> 100% supported by the current text of RFC4291bis, which requires that
> the router forward packets to the /120.

Thanks for sharing this Lorenzo, it something I did not think of. I
appreciate the cleverness of this trick, just as much as the next person
appreciates this funny photo [2]. :-)

However, while the trick can be made to work on Linux, it does not
appear to work on Cisco IOS XR, JunOS and OpenBSD. As such, its no more
then a party trick, and cannot be considered as a supportive argument
for an Internet Standard.

For the benefit of the working group, what Lorenzo describes is the
following in linux-lingo:

    $ sudo ip -6 address add    2001:67c:208c:4291::1/64 dev eth1
    $ sudo ip -6 route   delete 2001:67c:208c:4291::/64 dev eth1
    $ sudo ip -6 route   add    2001:67c:208c:4291::/126 dev eth1

    $ sudo ip -6 route show dev eth1
    2001:67c:208c:4291::/126  metric 1024

    $ sudo ip -6 addr show dev eth1
    3: eth1: <BROADCAST,MULTICAST> mtu 1500 qlen 1000
        inet6 2001:67c:208c:4291::1/64 scope global tentative
        valid_lft forever preferred_lft forever

I also fear that the moment "disunited addressing & routing" become
commonplace, you'll find your devices on the dirty end of a
'/120 routed + /64 addressed'-link and have a dysfunctional experience.
As far as I know there is no way to signal host "only a /120 out of this
/64 is routed".

Kind regards,

Job

[2]: http://instituut.net/~job/ietf-6man.jpg

---

From: Wilco Baan Hofman <[email-masked]>
Date: Thu, 23 Feb 2017 12:43:17 +0100

> host just configures the address as a whole. Not need to look at the prefix
For stateful DHCPv6 the prefix length should also be /64 and should
allow multiple addresses, at least in my opinion. And I have seen
several devices that only allowed configuration of /64 prefixes
(printers, etc) for even static addresses, which is a perfectly valid
assumption right now.

So we see SLAAC, ILNP and NPT66 requiring 64-bit prefix length. But
these cases all cover edge networks, with hosts, printers and similar
nodes. Keeping the requirement (or moving to SHOULD) for edge networks
seems reasonable to me.

However, this does not make the carrier use case any less relevant. The
main problem with /64 is TCAM exhaustion through ND attacks. Because NDP
follows a multicast discovery model, it simply does not scale up to 2^64
addresses in a subnet when being scanned/attacked. A subscription model
(like WiFi proxyNDP does) would scale a lot better. This is something
that needs to be addressed as well, separately.

Another problem carriers face is that /127 can not be configured on a
lot of routers, because of the subnet router anycast requirement that
was only lifted for /127 with rfc6164 in 2011. That means that
operationally people go out-of-spec, because frankly, going out-of-spec
works more reliably and consistently.

And because /64s don't really work for inter-router-links because of the
attack surface, and /127s don't really work because of older routers,
people will start configuring /126 for inter-router-links and /125 and
(slightly) shorter for VRRP and for BGP sessions with multiple routers.

In my opinion, there should at least be some room in the IPv6 standard
for arbitrary prefix lengths for interconnects.

-- Wilco

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 23 Feb 2017 13:25:24 +0100

Le 23/02/2017 à 12:43, Wilco Baan Hofman a écrit :
>>>> Nobody is saying that /64 isn't extremely widely used where
>>>> it's appropriate to have a portable fixed length IID. Set the
>>>> default at 64 and trust operators to change it where they need
>>>> to. That's realistic.
>>> As a host developer I strongly oppose that. It will make life
>>> easier for network operators but make life harder for host OS
>>> developers, host operators, and host users.
>>>
>>> And it is absolutely inappropriate to change this now in given
>>> that the /64 boundary has been the standard for the last 20
>>> years. It will break deployed code that relies on the current
>>> standard. (That includes concrete code I can point to that I
>>> know runs on tens of millions of devices.) That's not acceptable
>>> to do in a standard reclassification.
>>
>> For DHCP IA_NA, the host should not care about the length of the
>> IID. The host just configures the address as a whole. Not need to
>> look at the prefix length.
>
> For stateful DHCPv6 the prefix length should also be /64

In DHCPv6-for-addresses (not for prefixes) the prefix length field is
absent.

Some of the DHCPv6 Client code sets a 64 (hardcoded in C language) in
the source code when assigning that address to the interface.

That is completely wrong.

I suppose programmers having written this thought to themselves that
since SLAAC/Ethernet does that, and since RFC4191 reinforces it, then
why not DHCPv6 too?

They miss that DHCPv6 spec does not include a prefix length in their
messages.

> and should allow multiple addresses, at least in my opinion.

Yes, DHCPv6 should allow for multiple addresses.  It is the case.  But
no plen.

Also DHCPv6 Prefix Delegation is made to be able to request a prefix (a
P1/64, or a P2/63 or even a P3/3 - the plen is a parameter).  With that,
the Client is free to form addresses out of maybe P1 by setting an
Interface ID of a parametrable length, and delegate further something
out of a P3.

> And I have seen several devices that only allowed configuration of
> /64 prefixes (printers, etc) for even static addresses, which is a
> perfectly valid assumption right now.

It is a wrong assumption even right now to assume a /64 plen for a
manually configured address.  This has strong consequences on routing.

A host on a /120 subnet MUST NOT set /64 for manually configured
addresses, but /120; otherwise it can eat out of a subnet of someone else.

This is simply covered in the 4191 IPv6 Architecture by the statement
sayint that the Interface ID length plus the prefix length must equal
128.  120 plus 64 equals 184 which is different than 128.

> So we see SLAAC, ILNP and NPT66 requiring 64-bit prefix length.

Again, 64-bit in SLAAC is a side effect of using Ethernet with that
SLAAC.  SLAAC per se uses a parametrable prefix length.

As such, it is SLAAC/Ethernet requiring 64-bit prefix length.

For ILNP and NPT66 I dont know, but I thought I saw /48 in some Network
Prefix Translator implementation on linux.

> But these cases all cover edge networks, with hosts, printers and
> similar nodes. Keeping the requirement (or moving to SHOULD) for
> edge networks seems reasonable to me.

I would disagree, because we want these edge networks to further grow.

I would agree with a statement that says Ethernet can only work with
SLAAC if it has an IID of length 64.  One can not make an Ethernet
subnet with SLAAC and plen 65.  That is a problem of Ethernet - RFC2464
- and try to update it.  Otherwise it wont grow.

> However, this does not make the carrier use case any less relevant.
> The main problem with /64 is TCAM exhaustion through ND attacks.
> Because NDP follows a multicast discovery model, it simply does not
> scale up to 2^64 addresses in a subnet when being scanned/attacked.
> A subscription model (like WiFi proxyNDP does) would scale a lot
> better. This is something that needs to be addressed as well,
> separately.

I agree.

> operationally people go out-of-spec, because frankly, going
> out-of-spec works more reliably and consistently.
>
> And because /64s don't really work for inter-router-links because of
> the attack surface, and /127s don't really work because of older
> routers, people will start configuring /126 for inter-router-links
> and /125 and (slightly) shorter for VRRP and for BGP sessions with
> multiple routers.
>
> In my opinion, there should at least be some room in the IPv6
> standard for arbitrary prefix lengths for interconnects.

I agree.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 22:37:52 +0900

> following in linux-lingo:

Actually no, what I was saying was literally to leave the addresses as /64s
and configure the first-hop router to route the /126 to the prefix. The
hosts won't care.

> As far as I know there is no way to signal host "only a /120 out of this

The host doesn't really need to know.

---

From: Job Snijders <[email-masked]>
Date: Thu, 23 Feb 2017 14:47:33 +0100

On Thu, Feb 23, 2017 at 10:37:52PM +0900, Lorenzo Colitti wrote:
> Actually no, what I was saying was literally to leave the addresses as
> /64s and configure the first-hop router to route the /126 to the
> prefix. The hosts won't care.

And how to protect the interconnection between the first-hop router and
the edge-of-your-network? or the edge of the network itself? I suspect
this idea is still in a theoretical stage.

Can you point me to a RIPE, NANOG or APRICOT talk where this idea is
shared in its entirety?

Kind regards,

Job

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 23:06:20 +0900

> this idea is still in a theoretical stage.

Not sure what you mean. If you have an edge ACL and you want to ensure that
packets in the machine /64 but not in the arbitrarily small subnet you've
decided to restrict the machines to, just allow the /120 at the edge and
drop the /64. If you're talking about protecting the interconnects between
routers, you can just use /127.

> Can you point me to a RIPE, NANOG or APRICOT talk where this idea is

You don't need a RIPE talk to do some experimentation, do you? If it works
well, you give the talk. :-)

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 23 Feb 2017 12:39:18 -0500

>> to operate and troubleshoot.
I like this as well, I'm not convinced that any of mark's problems won't
show up in v6 networks though, even if the mandate (and hardware/software
fixes the mandate) is /64 only... people do dumb things, we can't really
stop them.

I don't see how the proposed wording makes this more complicated, for MOST
things people will just pick the default /64 and never look back (because
their upstream will be doing SLAAC and they won't even really 'pick').

For cases where people need (or feel the need) another prefix length
'RECOMMENDED'  means they can, they are adults, they can (and will) do what
they want.

-chris

---

From: 神明達哉 <[email-masked]>
Date: Thu, 23 Feb 2017 10:45:44 -0800

At Thu, 23 Feb 2017 13:16:46 +0900,

> the interface ID is 64 and does not work on anything other than 64 bit

Out of curiosity: which code is it, and exactly what does its
assumption mean?  Does it mean, for example, it allows manual
configuration of an address but requires its IID length be 64 bits?
(If it means something like this, I'd also wonder how its "IID"
matters in the first place - does that implementation use the lower 64
bits for some specific purpose?)

I thought general-purpose OSes are actually quite flexible about the
length of "IIDs" (in many cases it's actually derived from the length
of on-link prefix corresponding to the address).  I know BSD variants
are intentionally flexible on this.  I also know at least some (if not
all) kernel versions of Linux are flexible.

The only example of "widely-deployed code" with such an assumption
that I know of is ISC DHCPv6 client (though I'm not sure if its latest
version still has that assumption) as described in Section 4.4 of
RFC7421.  But I guess you're referring to something else.

If you can be more specific it might help provide some clarity for the
discussion, although I'm not so optimistic that it will automagically
resolve the conflicting views we are seeing.

--
JINMEI, Tatuya

---

From: David Farmer <[email-masked]>
Date: Thu, 23 Feb 2017 16:43:51 -0600

> change RFC 4291, won't that code be incorrect?

OK, what if we said something like this;

   IPv6 unicast routing is based on prefixes of any valid length up to
   128 [BCP198]. However, all implementations of IPv6 are REQUIRED to
   support an IID length of 64 bits, other IID lengths are OPTIONAL.
   Subnet prefixes of /64 are RECOMMENDED for general purpose use,
   subnet prefixes of /127 are RECOMMENDED for point-to-point router
   links [RFC6164], other subnet prefix lengths are NOT RECOMMENDED,
   as their use could be incompatible with some implementations of IPv6.
   The rationale for the 64 bit boundary in IPv6 addresses can be found
   in [RFC7421].

I'd prefer other IID lengths to be RECOMMENDED for implementations, but I
can live with OPTIONAL.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 23 Feb 2017 18:03:56 -0500

> when their network is flaky.

A bunch of networks do silly things... they aren't going to stop doing
those silly things just because the IETF says something, are they?

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Feb 2017 12:10:24 +1100

In message <[email-masked]>, Alexandre Petrescu
> run routing protocols, and even less autoconfiguring routing protocols.

Except that is exactly what homenet does completely automated.

> house network.  That will challenge the initial thoughts of the address

They also get /48's from the sane ISPs.  If your ISP is insane go find
one that isn't.

---

From: Jared Mauch <[email-masked]>
Date: Thu, 23 Feb 2017 21:53:40 -0500

> On Feb 21, 2017, at 2:21 PM, Karsten Thomann <[email-masked]> wrote:
> 

I’m reminded of when a vendor decided that /31 on ethernet was not a suitable configuration and did not properly disclose in the release notes, causing a subsequent series of outages.

I’m therefore cautious about the usage of any normative comment on bit mask length.

Nothing quite like your interfaces losing their IP config after upgrade because someone decided to more strictly interpret guidance.

- Jared

---

From: Jared Mauch <[email-masked]>
Date: Thu, 23 Feb 2017 22:05:22 -0500

> On Feb 22, 2017, at 10:56 AM, Lorenzo Colitti <[email-masked]> wrote:
> 
> RFC6583-style attacks (of which the class addressed by RFC6164 is a subset) are low payoff and pretty easy to mitigate using very small changes to ND implementations

The duration of time it takes to roll out new code is measured in years in a backbone.  Some vendors are still missing negative-arp caching for v4 in 2017, so I’m having trouble treating this as a low-payoff attack.  Even when it’s not intended as an attack, the side-effects are well documented, and is something the IETF NOC team has experienced first-hand.

Not all vendors, hardware or implementations are equal, and convergence here takes some time.  Setting the right standard in the first place helps, and when doing a -bis, it’s furthermore important to incorporate the operational lessons learned.  If the WG decides to not listen, that’s certainly it’s prerogative but does not move the standards forward.

For me, this is just one of many things in IPv6 that requires servicing, so not the end of the world if this one doesn’t get fixed, but being overly prescriptive here is begging for trouble.

- Jared

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Feb 2017 00:13:03 -0300

On 02/23/2017 07:43 PM, David Farmer wrote:
> 
> 
> On Wed, Feb 22, 2017 at 10:16 PM, Lorenzo Colitti <[email-masked]

I'd remove a few sentences here, as in:

   IPv6 unicast routing is based on prefixes of any valid length up to
   128 [BCP198]. Subnet prefixes of /64 are RECOMMENDED for general
   purpose use, subnet prefixes of /127 are RECOMMENDED for point-
   to-point router links [RFC6164]. The rationale for the 64 bit
   boundary in IPv6 addresses can be found in [RFC7421].

Thanks,

---

From: David Farmer <[email-masked]>
Date: Fri, 24 Feb 2017 01:15:48 -0600

>    boundary in IPv6 addresses can be found in [RFC7421].

The problem is you have stripped out all the implementation guidance and
only left operational guidance.  But maybe the the right idea is to
separate the two, putting the operational guidance in Section 2.4 where we
are talking about prefixes and the implementation guidance in section 2.4.1
where we are talking about IIDs.
2nd Paragraph of 2.4;

   IPv6 unicast routing is based on prefixes of any valid length up to
   and including 128 [BCP198].  However, subnet prefixes of 64 bits in
   length are REQUIRED for use with Stateless Address Autoconfiguration
   (SLAAC)[RFC4862] and are RECOMMENDED for all other general purpose
   use. The rationale for the 64 bit boundary in IPv6 addresses can be
   found in [RFC7421].

4th paragraph of 2.4.1

   For all unicast addresses, except those that start with the binary
   value 000, support for Interface IDs that are 64 bits long is
   REQUIRED, support for other Interface IDs lengths is OPTIONAL. The
   rationale for the 64 bit boundary in IPv6 addresses can be found in
   [RFC7421].

This clearly say that implementations that only support 64 bit IID lengths
are just fine, but also says implementations that allow IID lengths other
than 64 bits are just fine too.  I think the current and historic text
actually implies implementations are not to allow other IID lengths, is
that what we really intended to say?  A lot of implementations seem to
allow other IID lengths, are they wrong?  I don't think so.

This also gives strong operational guidance that 64 bit length subnet
prefixes are expected in most situations.  Reinforcing the 64 bit boundary,
however without outlawing the use of other subnet prefix lengths when
implemented and they could be useful.  This is done without distracting
from the 64 bit boundary, by not directly calling attention to RFC6164 or
the other longer prefix lengths. Since BCP198 and RFC7421 both reference
RFC6164 calling it out here doesn't seem necessary, and would unnecessarily
weaken the focus on the 64 bit boundary that I'm trying to maintain.

I don't see how this text would require changes in any code, nor does it
imply other IID lengths are not allowed operationally, again which a lot of
implementations seem to allow.

Thanks.

---

From: Pierre Pfister <[email-masked]>
Date: Fri, 24 Feb 2017 08:53:25 +0100

Hello David,

> Le 24 févr. 2017 à 08:15, David Farmer <[email-masked]> a écrit :
> 
> 
> 
> On Thu, Feb 23, 2017 at 9:13 PM, Fernando Gont <[email-masked] <mailto:[email-masked]>> wrote:
> The problem is you have stripped out all the implementation guidance and only left operational guidance.  But maybe the the right idea is to separate the two, putting the operational guidance in Section 2.4 where we are talking about prefixes and the implementation guidance in section 2.4.1 where we are talking about IIDs.
> 2nd Paragraph of 2.4;
> 

Except RFC4862(SLAAC) does not say anywhere that 64 bits long IIDs are required.
Only mention I find of 64 is given as an example for EUI-64 for ethernet links.

>    rationale for the 64 bit boundary in IPv6 addresses can be found in

1) The ::/3 rule is blatantly ignored by all implementations that I know of.
I don't see how something that has been ignored for years, and has 
no implementation and deployment experience, could make its way to full standard.

2) "support for other Interface IDs lengths is OPTIONAL" -> Wait. What !?
This is not a compromise. You are just relaxing the requirement even more than it already is.
This is not what is implemented, nor what is deployed.

- Pierre

> 
> This clearly say that implementations that only support 64 bit IID lengths are just fine, but also says implementations that allow IID lengths other than 64 bits are just fine too.  I think the current and historic text actually implies implementations are not to allow other IID lengths, is that what we really intended to say?  A lot of implementations seem to allow other IID lengths, are they wrong?  I don't think so.
> 
> This also gives strong operational guidance that 64 bit length subnet prefixes are expected in most situations.  Reinforcing the 64 bit boundary, however without outlawing the use of other subnet prefix lengths when implemented and they could be useful.  This is done without distracting from the 64 bit boundary, by not directly calling attention to RFC6164 or the other longer prefix lengths. Since BCP198 and RFC7421 both reference RFC6164 calling it out here doesn't seem necessary, and would unnecessarily weaken the focus on the 64 bit boundary that I'm trying to maintain.
> 
> I don't see how this text would require changes in any code, nor does it imply other IID lengths are not allowed operationally, again which a lot of implementations seem to allow. 
> 
> Thanks.
> -- 
> 2218 University Ave SE        Phone: 612-626-0815 <tel:(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <tel:(612)%20812-9952>

---

From: David Farmer <[email-masked]>
Date: Fri, 24 Feb 2017 02:20:09 -0600

> Only mention I find of 64 is given as an example for EUI-64 for ethernet

I believe most implementations of SLAAC require /64, but I could be wrong.

> no implementation and deployment experience, could make its way to full

I'm willing to let that go too, but it was there so I left it for now.

> This is not what is implemented, nor what is deployed.

Most routers let you specify any subnet length you want they default to /64
usually.  Also, many host OSes when you manually config let you specify any
subnet length too.  By making it OPTIONAL, I'm saying it ok to do that, or
not if the you don't want too.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 24 Feb 2017 14:25:19 +0100 (CET)

(posting this in the last call thread as well)

I just came back from PTO not reading IETF email for 5-6 weeks, and read
up on this thread.

I just want to state my opinion that whatever text we come up with should
reflect current operational reality, in that SLAAC A=1 only works on /64,
and that people use all kinds of subnet sizes when manually configuring
interfaces.

If current code doesn't treat 000::/3 in any special case, then documents
should reflect this.

Mandating /64 only for any IPv6 use case doesn't reflect reality as I see
it. I don't want to see A=1 /64 SLAAC requirement relaxed either.

I just want the -bis document to reflect what is currently in the field
and we know works. Nothing more, nothing less.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 24 Feb 2017 15:44:55 +0100

Le 23/02/2017 à 19:45, 神明達哉 a écrit :
> At Thu, 23 Feb 2017 13:16:46 +0900, Lorenzo Colitti
> <[email-masked]> wrote:
>
>> Help he understand, then. There is widely-deployed code that
>> assumes that the interface ID is 64 and does not work on anything
>> other than 64 bit prefix lengths.
>

For example - is it normal that when manually adding an address to an
interface w/o specifying the plen, a /64 'connected' route pops there?
Why 64?  I dont mind the route, but I mind the 64.

Alex

> matters in the first place - does that implementation use the lower
> 64 bits for some specific purpose?)
>
> length of "IIDs" (in many cases it's actually derived from the
> length of on-link prefix corresponding to the address).  I know BSD
> variants are intentionally flexible on this.  I also know at least
> some (if not all) kernel versions of Linux are flexible.
>
> that I know of is ISC DHCPv6 client (though I'm not sure if its
> latest version still has that assumption) as described in Section 4.4
> of RFC7421.  But I guess you're referring to something else.
>
> If you can be more specific it might help provide some clarity for
> the discussion, although I'm not so optimistic that it will
> automagically resolve the conflicting views we are seeing.
>
> -- JINMEI, Tatuya
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 24 Feb 2017 15:57:36 +0100

> Except that is exactly what homenet does completely automated.

Except homenet still relies on SLAAC/Ethernet on end devices.

> They also get /48's from the sane ISPs.  If your ISP is insane go find

/48 from sane ISP, but with drawbacks: tunnelling, right?

Alex

---

From: Peter Hessler <[email-masked]>
Date: Fri, 24 Feb 2017 15:59:32 +0100

On 2017 Feb 24 (Fri) at 15:44:55 +0100 (+0100), Alexandre Petrescu wrote:
:Le 23/02/2017 à 19:45, 神明達哉 a écrit :
:>At Thu, 23 Feb 2017 13:16:46 +0900, Lorenzo Colitti
:><[email-masked]> wrote:
:>
:>>Help he understand, then. There is widely-deployed code that
:>>assumes that the interface ID is 64 and does not work on anything
:>>other than 64 bit prefix lengths.
:>
:>Out of curiosity: which code is it, and exactly what does its
:>assumption mean?  Does it mean, for example, it allows manual
:>configuration of an address but requires its IID length be 64 bits?
:
:For example - is it normal that when manually adding an address to an
:interface w/o specifying the plen, a /64 'connected' route pops there?
:Why 64?  I dont mind the route, but I mind the 64.
:
:Alex

That is an implementation detail.  And, even though I strongly object to
*forcing* it to be /64, I am perfectly happy with a default of /64.  As
stated, there are many advantages to that subnet size.

If you don't choose one, then the implementation will choose one for
you.

-- 
What garlic is to salad, insanity is to art.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 24 Feb 2017 15:11:17 +0000

> and we know works. Nothing more, nothing less.

I wholly agree with this as it applies to draft-ietf-6man-rfc4291bis.

As a general comment, it should be reiterated that operational feedback
is critical to standards development and that if field deployment issues
are neglected, this damages the standards development process.  It would
be unfortunate if this document fell prey to this folly.

Nick

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Feb 2017 15:26:51 -0300

On 02/24/2017 12:11 PM, Nick Hilliard wrote:
[....]

+1

---

From: 神明達哉 <[email-masked]>
Date: Fri, 24 Feb 2017 11:40:31 -0800

At Fri, 24 Feb 2017 15:44:55 +0100,

> Why 64?  I dont mind the route, but I mind the 64.

I wouldn't interpret this example as such an implementation "does not
work on anything other than 64 bit prefix lengths" in this context,
since "64" is just the default of the implementation and can be
"operationally" changed.  But in any case, I don't know if this
something what Lorenzo meant.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 24 Feb 2017 14:24:41 -0800

At Fri, 24 Feb 2017 02:20:09 -0600,

> I believe most implementations of SLAAC require /64, but I could be wrong.

I don't know about "most implementations", but at least BSD variants
don't unconditionally require /64 for the IID (and therefore prefix)
length of SLAAC.  It literally implements what RFC4862 states:

   interface identifier -  [...]  The
      exact length of an interface identifier and the way it is created
      is defined in a separate link-type specific document that covers
      issues related to the transmission of IP over a particular link
      type (e.g., [RFC2464]).

That is, for the SLAAC implementation the length of the IID is a
parameter per link-type, not a magic constant value of 64.  And, as
specified in RFC2464, the value for Ethernet links is defined to be
64.  For an external observer it may not be distinguishable from the
magic number is hardcoded as if required for the entire
implementation, but the actual implementation is far from that.

So, aside from whether the above text is good in the main context of
this thread, just to make it more accurate it should be, e.g.:

    IPv6 unicast routing is based on prefixes of any valid length up to
    and including 128 [BCP198].  However, subnet prefixes of 64 bits
    are REQUIRED for use with Stateless Address Autoconfiguration
    (SLAAC)[RFC4862] in some link types such as Ethernet [RFC2464]. [...]

BTW, I think your idea of separating the implementation guidance and
operational guidance can be a compromise.  If I correctly interpret
the interests of main stake holders in this thread, these are:

- some educated adults (aka "operators") want to be allowed to
  configure there IPv6 addresses with an arbitrary IID (and therefore
  arbitrary length of subnet prefix).  and they don't want rfc4291bis
  to explicitly ban such an operation
- some implementers want to be allowed to write code that only allows
  64-bit IIDs for IPv6 addresses (except those that start with the
  binary value 000) to configure for that implementation.  and they
  don't want rfc4291bis to make such an implementation non-compliant.
- maybe some others also want to use the existence of such
  implementations as leverage to refuse ISPs offering very small size
  of subnet.

If I'm correct that these are main concerns, text like your proposal
seems to meet these even if no one is completely satisfied.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 25 Feb 2017 11:02:45 +0100

Le 24/02/2017 à 20:40, 神明達哉 a écrit :
> At Fri, 24 Feb 2017 15:44:55 +0100, Alexandre Petrescu
> <[email-masked]> wrote:
>
>>>> assumes that the interface ID is 64 and does not work on
>>>> anything other than 64 bit prefix lengths.
>>>
>> For example - is it normal that when manually adding an address to
>> an interface w/o specifying the plen, a /64 'connected' route pops
>> there? Why 64?  I dont mind the route, but I mind the 64.
>

I dont know what Lorenzo meant more precisely - and I would like to know
too.

Because I have a set of specific questions to Host programmers about how
64 is - or is not - a barrier in making e.g. a smartwatch talk to the
Internet through a smartphone.  Or how a set of in-car computers (map
database, vision camera, etc.) can be remotely updated through an
on-board LTE module.

Alex

---

From: Xing Li <[email-masked]>
Date: Sun, 26 Feb 2017 08:07:28 +0800

> You are not forced to change OS code: DHCPv6 runs in the userspace.

+1, xing

---

From: Xing Li <[email-masked]>
Date: Sun, 26 Feb 2017 08:07:16 +0800

+1, xing

---

From: Xing Li <[email-masked]>
Date: Sun, 26 Feb 2017 08:14:21 +0800

+1, xing

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Feb 2017 00:40:24 +0900

> configuration of an address but requires its IID length be 64 bits?

The first example that came to mind was one in the Android 464xlat
implementation. This takes the IPv6 prefix configured on the interface,
fills the bottom 64 bits with randomness, adjusts the middle bytes to make
the result checksum-neutral, and uses that as the IID. If we change the IID
to != 64 bits, then that code becomes incorrect.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 27 Feb 2017 17:58:03 +0100

Le 27/02/2017 à 16:40, Lorenzo Colitti a écrit :
> On Fri, Feb 24, 2017 at 3:45 AM, 神明達哉 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> implementation. This takes the IPv6 prefix configured on the
> interface, fills the bottom 64 bits with randomness, adjusts the
> middle bytes to make the result checksum-neutral, and uses that as
> the IID. If we change the IID to != 64 bits, then that code becomes
> incorrect.

For my part, I agree with you: we want that IID len to continue working
with 464xlat.

I dont appreciate the confusion android - and linux for that matter
- introduces when adding by default an fe80::/64 entry in the routing
table.  I dont mind the route, but I mind the 64.

I dont appreciate the linux kernel complaining when receiving a plen==65
in RA.

I think text in 4291bis - if any text - should allow the first case
(IID==64 for 464xlat), but disallow the other two cases (fe80::/64 by
default in linux rt, and linux kernel complaining of plen==65 in RA).

I.e. text in 4291bis - if any text - should allow IID==64, RA plen==65
but should disallow by-default fe80::/64.

Contrary to expectactions, allowed IID==64 for 464xlat should not mean
that plen==65 in RA is prohibited.

(I now realize that because 64 is precisely half of 128 we actually have
two problems: default plens at 64 and also default IIDs at 64.)

Alex