Subject: Fwd: New Version Notification for draft-farmer-6man-exceptions-64-02.txt

From: David Farmer <[email-masked]>
Date: Wed, 1 Aug 2018 12:14:33 -0500

Made some updates

      *  Rewrote summary paragraph of the Introduction, using both
         subnets and IIDs.
      *  Added that privacy addresses require SLAAC in the Security
         Considerations.
      *  Added that manual config and DHCPv6 can also be used with
         Options 1-3 of Appendix A.
      *  Added quick mention of M and O flags to discussion of DHCPv6 in
         Option 4 of Appendix A.
      *  Fixed typos introduced in version 01.
      *  More formatting changes.
      *  Editorial changes.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Tue, Jul 31, 2018 at 7:20 PM
Subject: New Version Notification for draft-farmer-6man-exceptions-64-02.txt
To: David Farmer <[email-masked]>

A new version of I-D, draft-farmer-6man-exceptions-64-02.txt
has been successfully submitted by David Farmer and posted to the
IETF repository.

Name:           draft-farmer-6man-exceptions-64
Revision:       02
Title:          Exceptions to the 64-bit Boundary in IPv6 Addressing
Document date:  2018-07-31
Group:          Individual Submission
Pages:          14
URL:            https://www.ietf.org/internet-drafts/draft-farmer-6man-excep
tions-64-02.txt
Status:         https://datatracker.ietf.org/doc/draft-farmer-6man-exceptio
ns-64/
Htmlized:       https://tools.ietf.org/html/draft-farmer-6man-exceptions-64
-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-farmer-6man-exc
eptions-64
Diff:           https://www.ietf.org/rfcdiff?url2=draft-farmer-6man-excepti
ons-64-02

Abstract:
   This document clarifies exceptions to the 64-bit boundary in IPv6
   addressing.  The exceptions include unicast IPv6 addresses with the
   first three bits 000, manually configured addresses, DHCPv6 assigned
   addresses, IPv6 on-link determination, and the possibility of an
   exception specified in separate IPv6 link-type specific documents.
   Further, operational guidance is provided, and Appendix A discusses
   the valid options for configuring IPv6 subnets.

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

The IETF Secretariat

-- 
===============================================
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: Fernando Gont <[email-masked]>
Date: Thu, 2 Aug 2018 05:06:32 +0200

Hello, David,

Some quick comments:

*  "Alternatively,
   if an on-link prefix length is not included, the manually configured
   address MUST NOT automatically be considered on-link. "

This looks akward.Being pedantic, this address is always on-link (if you
want to send a packet to yourself, you don't need to go through a router).

* 2.3.  DHCPv6 Assigned Addresses

I'm not sure the I'd say the addreses don't have a structure. They are
still composed of a global rotuing prefix, subnet bits, and an interface
I-D. It may be the case that the node that got the lease just doesn't
have the information.

* I find this text hard to parse:
" Otherwise, if subnet assignment prefixes are not
   configured, then hosts will have to use manually configured addresses
   or DHCPv6 assigned addresses and subnets are configured solely by
   on-link prefixes that are recommended to be 64 bits in length, only
   recommending 64-bit subnets in this circumstance. "

*Meta:
For me, it boils down to this:

/64 is currently required for address configuration with SLAAC.For
everything else, you can use whatever you please. (me thinking out loud)
At the end of the day, a PIO with the L bit set is a simple form of a
RIO. It's just announcing a route. In retrospective, it seems the
"controversy" with RFC6164 really had to do  with... the conflict with
the subnet router anycast address?

Thanks,
Fernando

On 08/01/2018 07:14 PM, David Farmer wrote:
> From: ** <[email-masked] <mailto:[email-masked]>>
> To: David Farmer <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> URL:           
> https://www.ietf.org/internet-drafts/draft-farmer-6man-exceptions-64-02.txt
> <https://www.ietf.org/internet-drafts/draft-farmer-6man-exceptions-64-02.txt>
> Status:       
>  https://datatracker.ietf.org/doc/draft-farmer-6man-exceptions-64/
> <https://datatracker.ietf.org/doc/draft-farmer-6man-exceptions-64/>
> Htmlized:     
>  https://tools.ietf.org/html/draft-farmer-6man-exceptions-64-02
> <https://tools.ietf.org/html/draft-farmer-6man-exceptions-64-02>
> Htmlized:     
>  https://datatracker.ietf.org/doc/html/draft-farmer-6man-exceptions-64
> <https://datatracker.ietf.org/doc/html/draft-farmer-6man-exceptions-64>
> Diff:         
>  https://www.ietf.org/rfcdiff?url2=draft-farmer-6man-exceptions-64-02
> <https://www.ietf.org/rfcdiff?url2=draft-farmer-6man-exceptions-64-02>
> 
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org
> <http://tools.ietf.org>.
> 
> The IETF Secretariat
> 
> 
> 
> 
> -- 
> <mailto:[email-masked]>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Aug 2018 12:37:10 +1200

Hi,

Thanks for doing this. I think it's a step in the right direction
but I still have some radical suggestions...

1) This sets the tone for my other comments: I suggest changing the title to

 Exceptions to the Normal Subnet Boundary in IPv6 Addressing

Why? Because 64 is just a choice, not a law of nature. It's even
a bit confusing that it happens to be exactly half of 128, so when
we say "64" it's not automatically clear whether we mean the prefix
length or the IID length.

2) I wonder whether this should be standards-track or a BCP.
The argument for BCP is that it's defining how to apply the address
architecture, and that in any case it talks a lot about practice.

3) Most radically, I would like to see most of the instances
of "64" in the text replaced by "N" or "128-N". Along with that,
there would be a short section saying, basically, "N = 64".
(And then we could take it out of 4291bis.)

That isn't a backdoor way of attacking /64; I think it would just
make the whole point clearer, and avoid the possible confusion
between the two 64s.

4) Should we re-insert here the fact lost from RFC2373 and RFC3513
that only 2000::/3 is currently assigned for global unicast?
(See https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml, which still cites RFC3513.)

5) Should we state that "N = 64" only applies to 2000::/3 ?

6) A minor point: it's my understanding that some operators
use slight shorter prefixes than /127 for the RFC6164 scenario
(router-router links). I don't see any harm in that; is there
any reason not to relax the text somewhat?

Regards
   Brian

---

From: David Farmer <[email-masked]>
Date: Fri, 3 Aug 2018 03:26:41 -0500

Thanks for the comments, see inline;

> want to send a packet to yourself, you don't need to go through a router).

Ok I see what you are saying, how about;

Otherwise, if an on-link prefix length is not included, an on-link prefix
MUST NOT be automatically assumed, but an on-link prefix MAY be learned
from a PIO with the L flag set.

> I-D. It may be the case that the node that got the lease just doesn't

Ok, how about;

they are considered opaque 128-bit quantities and are assigned to node
interfaces without any knowledge of the internal structure or the subnets
present on the link network.

>    recommending 64-bit subnets in this circumstance. "

Is this a little easier to parse?

Otherwise, if a subnet assignment prefix is not configured, then hosts will
have to use manually configured addresses or DHCPv6 assigned addresses and
these subnets are solely configured by the on-link prefixes. These on-ink
prefixes that are recommended to be 64 bits in length, therefore only
recommending 64-bit subnets in this circumstance.

---

From: David Farmer <[email-masked]>
Date: Fri, 3 Aug 2018 03:38:36 -0500

> length or the IID length.

I like that, but how about "standard" instead of "normal".

Exceptions to the Standard Subnet Boundary in IPv6 Addressing

While 64 is just a number, it is the consensus or standard number, and I
don't see that changing, at least anytime soon.

> architecture, and that in any case it talks a lot about practice.

I like your argument for BCP, but let's put a pin in that discussion until
later, like after we get enough support to adopt this as a workgroup
document.

> make the whole point clearer, and avoid the possible confusion

I'm not willing to do that in the whole document at least yet. Personally,
I think that "N" or "128-N" and "N=64" is more confusing than 64-bit IIDs
and 64-bit subnets. However, I will use "128-N" and "N=64" in the formal
(normative) operational guidance in section 3. Because I think that will
make the execption for link-type specific documents easier to undersatnd in
that section.

> (See https://www.iana.org/assignments/ipv6-unicast-address-
> assignments/ipv6-unicast-address-assignments.xhtml, which still cites
> RFC3513.)
>

Note 2 on the top of page 7 of RFC2373 says, "The format prefixes 001
through 111, except for Multicast Addresses (1111 1111), are all required
to have to have 64-bit interface identifiers in EUI-64 format.  See section
2.5.1 for definitions."

And, in RFC3513 section 2.5.1 says, "For all unicast addresses, except
those that start with binary value 000, Interface IDs are required to be 64
bits long and to be constructed in Modified EUI-64 format."

To me they both say all unicast addresses. Now only 2000::/3 has been
released to IANA to allocate to the RIRs, but that is a diffrent issue.
Unicast address beginning with 000 are exceptions, but they are all
special-purpose or otherwise reserved addresses. I talk about all this in
section 2.1.

> any reason not to relax the text somewhat?

When subnets are configured solely using on-link prefixes, 64-bit on-link
prefixes are recommended, 127-bit prefixes are explicitly allowed, and
other prefix lengths (like 126, 120, or 112) are valid but not recommended.
Implying that there may exist valid reasons in particular circumstances
when other prefix lengths are acceptable or even useful. Option 4 of
Appendix A discusses this in some detail, without specifing specific other
subnet lengths.

Regards

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Aug 2018 10:32:18 +1200

> Thanks for the comments, see inline;

I haven't had time yet to catch up with all your changes.
Will do so soon, but please my responses in line...

> I like that, but how about "standard" instead of "normal".

I suggested "normal" to be neutral in the recommended vs mandatory
debate, but I'm OK with "standard" too.
 
> later, like after we get enough support to adopt this as a workgroup

Sure.

> make the execption for link-type specific documents easier to undersatnd in

And it refers back to the terminology in the non-controversial part
of the addressing architecture. I might want to wordsmith this some
more, but thanks for taking the point anyway. 

> special-purpose or otherwise reserved addresses. I talk about all this in

Right. But I'm still a bit bothered by the fact that there is no
current standards-track or BCP document that reserves the other /3
prefixes. IANA has done the right thing, but that involves citing
an obsolete document.

I strongly feel that we should not appear to restrict the prefix
length for the other /3s. When they eventually are released for
assignment, who knows what they will be used for?

> when other prefix lengths are acceptable or even useful.

Which is a perfect example of a normative SHOULD, and that (IMHO)
belongs in the main text. The wordsmithing is a bit fiddly.
Something like:

OLD:
      Alternatively, network operators MAY configure point-to-point
      router links with 127-bit on-link prefixes, typically by manual
      configuration, and no subnet assignment prefix, see RFC 6164
      [RFC6164]
NEW:
      Alternatively, network operators MAY configure point-to-point
      router links with specific on-link prefixes, typically by manual
      configuration, and no subnet assignment prefix. The on-link
      prefix length SHOULD be 127 [RFC6164].

> Option 4 of

---

From: David Farmer <[email-masked]>
Date: Tue, 7 Aug 2018 21:34:46 -0500

> > [email-masked]> wrote:

 ...

> more, but thanks for taking the point anyway.

I'll happily accept wordsmithing suggestions.

But I've worked on it a bit myself already, how about;

Where N = 64 or the IID length specified in the link-type specific document
for the link network in question.

> prefixes. IANA has done the right thing, but that involves citing

The IANA considerations section of RFC3513, Note 2 says;

      For now, IANA should limit its allocation of IPv6 unicast address
      space to the range of addresses that start with binary value 001.
      The rest of the global unicast address space (approximately 85% of
      the IPv6 address space) is reserved for future definition and use,
      and is not to be assigned by IANA at this time.

To me that says just that, the rest of the global unicast address space is
reserved.

I see the issue that RFC3513 is obsoleted by RFC4291 and this isn't
included in RFC4291. But personally, I think this is an issue for
RFC4291bis, this issue should not be tied up in the subnet sizing issues.
IANA doesn't enforce that anyway.

> assignment, who knows what they will be used for?

The status of the currently reserved global unicast address space, as it
relates to the standard subnet boundary, is an issue that if there is a
consensus on it, probably belongs in this draft.

However RFC3587 says;

   RFC 2374 was the definition of addresses for Format Prefix 001
   (2000::/3) which is formally made historic by this document.  Even
   though currently only 2000::/3 is being delegated by the IANA,
   implementations should not make any assumptions about 2000::/3 being
   special.  In the future, the IANA might be directed to delegate
   currently unassigned portions of the IPv6 address space for the
   purpose of Global Unicast as well.

So, my view on the status is; since the rest of the global unicast address
space is reserved the standard subnet boundary does not technically apply
to it at this time. However, when other reserved blocks are allocated as
global unicast address space, by default, the standard subnet boundary will
apply, but we have the option to change things at that time.

So how about this

Note: ever since RFC 2373 [RFC2373] addresses with the first three bits 000
have been an exception to the standard subnet boundary, and addresses with
the first three bits 001 through 111, except for multicast addresses, have
been expected to be consistent with the standard 64-bit IID length and the
standard subnet boundary. However, currently only 2000::/3 has been
allocated as global unicast address space and released to the IANA for
distribution to the Regional Internet Registries (RIRs). The applicability
the standard subnet boundary to future allocations will be determined at
the time the allocations are release to the IANA. Nevertheless,
implementations of IPv6 should assume the standard subnet boundary applies
to future allocations and that 2000::/3 is not special in this reguard.

But I'd really like to hear from others on this issue too.

>       prefix length SHOULD be 127 [RFC6164].

Ok, now I see what you are getting at. How about;

Alternatively, network operators MAY configure point-to-point router links
with on-link prefixes that SHOULD be 127 bits in length, typically by
manual configuration,
and with no subnet assignment prefix. See RFC 6164 [RFC6164] Section 6 for
address selection considerations.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Aug 2018 15:10:27 +1200

David,

In a word, yes. I agree with your points below and your suggestions.

Regards
   Brian Carpenter

"Looks like a disaster; why wasn’t I invited?" - Eeyore (2018)