Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-why64-01.txt>

From: Ole Troan <[email-masked]>
Date: Wed, 23 Jul 2014 09:52:20 -0400

All,

We have received exactly zero comments on this last call. I assume this doesn't mean that there is no support for the document, given previous discussions.

Can I ask for one or two reviewers to do a detailed review of the document?

Best regards,
Ole

On 20 Jun 2014, at 21:16 , Bob Hinden <[email-masked]> wrote:

> This message starts a two week 6MAN Working Group on advancing:
> 
>       Title           : Analysis of the 64-bit Boundary in IPv6 Addressing
>       Authors         : Brian Carpenter
>                         Tim Chown
>                         Fernando Gont
>                         Sheng Jiang
>                         Alexandru Petrescu
>                         Andrew Yourtchenko
> 	Filename        : draft-ietf-6man-why64-01.txt
> 	Pages           : 23
> 	Date            : 2014-05-07
> 
>        http://tools.ietf.org/html/draft-ietf-6man-why64-01.txt
> 
> as an Informational RFC.  Substantive comments and statements of support for publishing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on July 4, 2014.
> 
> Regards,
> 
> Bob Hinden & Ole Trøan
>

---

From: 神明達哉 <[email-masked]>
Date: Wed, 23 Jul 2014 11:44:28 -0700

At Wed, 23 Jul 2014 09:52:20 -0400,

> Can I ask for one or two reviewers to do a detailed review of the document?

I've just read the latest version of the draft.  It's well written and
useful.  I also confirmed my own comments on the previous version were
addressed properly.  I think it's ready for publication.

A couple of very minor editorial comments:

- In section 3.4, this one-sentence paragraph seems a bit awkward

   Hosts would likely use DHCPv6, or be manually configured with
   addresses.

  Maybe the intent was it's part of the previous paragraph, explaining
  that DHCPv6/manual config would be used in such a situation?  If so,
  it makes sense, but I think it's better to say so clearly and
  explicitly.

- In Section 4.2: s/how to/of how to/?

      [RFC3972] has defined a detailed algorithm how to generate 64-bit
      interface identifier from a public key and a 64-bit subnet prefix.

--
JINMEI, Tatuya

---

From: Matthew Petach <[email-masked]>
Date: Wed, 23 Jul 2014 18:56:21 -0700

>       interface identifier from a public key and a 64-bit subnet prefix.

A minor grammar nitpick; "of how to" would not be as well
structured a sentence as you would instead get using
"showing how to", as in:

      [RFC3972] has defined a detailed algorithm showing how to generate
      a 64-bit interface identifier from a public key and a 64-bit subnet
prefix.

(sorry, I just get fussy about language usage sometimes.  ^_^;)

Thanks!  :)

Matt

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

---

From: Ole Troan <[email-masked]>
Date: Tue, 29 Jul 2014 15:46:29 +0200

I have reviewed the document, and have found a few comments below. apart from that I think the document is ready to go.

Section 1:
   "The fixed length limits the practical length of a routing prefix to
   64 bits, whereas architecturally, and from the point of view of
   routing protocols, it could be anything (in theory) between /1 and /
   128 inclusive.  Here, we mainly discuss the question of a shorter
   IID, which would allow a longer subnet prefix.  The document makes no
   proposal for a change to the IID length."

say something about host routes. for the sake of the argument you could say that the interface-id is still 64 bits, and that the longest match is done on the concatenation of prefix and interface-id.

Section 2:
   "Even though this length is a
   parameter for SLAAC, determined separately for each interface, a
   globally fixed IID length for all link layer media is the simplest
   solution, and is consistent with the principles of Internet host
   configuration described in [RFC5505]."

s/for each interface/link-layer media type/

Section 4.1:
  "Only the IPv6 Subnet Model [RFC5942] refers to the assumption of /64 prefix length
   as a potential implementation error."
 
that almost reads as if the authors believe RFC5942 is in the wrong.
making the assumption that there is a corresponding on-link /64 prefix when the host only has an IPv6 address (e.g. from DHCPv6) is indeed an implementation error.
the simplest resolution would be to delete the above sentence.

  "Default Router Preferences [RFC4191] for its impossibility of Prefix Length 4"

remove above reference. there is no limitation on prefix length in RFC4191. prefix is zero padded up to a 8 or 16 octet boundary.

Section 4.2
  "Operationally there could
   be a problem unless all hosts on a link use IIDs of the same length
   to configure a link-local address during reboot.  Typically today the
   choice of 64 bits for the link-local IID length is hard-coded per
   interface, and systems behave as if the link local prefix was
   actually fe80::/64. "

remove "during reboot". the prefix length for a global prefix doesn't have to be the same as for the link-local address. perhaps rather make it clear that since there is no way to configure the link-local prefix length, it will be a as defined in IPv6 over foo documents regardless of what the global prefix is.

Section 4.4:
  At least one DHCPv6 client unconditionally installs a /64 prefix as
   on-link when it configures an interface with an address, although
   some specific operating system vendors seem to change this default
   behavior by tweaking a client-side script.  It does this (even if
   technically it violates the protocol) because if there is no router
   on the link, the hosts effectively would fail to communicate each
   other with the configured addresses because the "on-link assumption"
   was removed in [RFC4861].  This is not really about the magic number
   of 64, but an implementation may sometimes pick a specific value of
   prefix length due to the removal of the on-link assumption, and the
   value chosen will most likely be 64.

if so, that is in violation of RFC5942. I don't think this document should make a case for different behaviour than 5942 requires.
just drop the whole paragraph?

Section 4.5:
   "A prefix long enough to limit the number of addresses comparably to
   an IPv4 subnet, such as /120, would create exactly the same situation
   for privacy as IPv4 except for the absence of NAT.  In particular, a
   host would be forced to pick a new IID when roaming to a new network,
   to avoid collisions.  An argument could be made that since this
   reduces traceability, it is a good thing from a privacy point of
   view."

does that logic hold water? outside of the network using the longer prefixes, an attacker would still have to track or guess the prefix length set of bits.

privacy-wise you could make the reverse argument as well. that a constant subnet prefix assigned to every end-user, means that I can now make fairly safe assumptions that I can track a given end-user by tracking the /64. which doesn't help privacy.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 29 Jul 2014 23:53:58 +0900

On Tue, Jul 29, 2014 at 9:46 AM, Ole Troan <[email-masked]> wrote:

>    128 inclusive.

Or /0?

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 29 Jul 2014 16:57:30 +0200

Le 29/07/2014 15:46, Ole Troan a écrit :
[...]
> remove above reference. there is no limitation on prefix length in
> RFC4191. prefix is zero padded up to a 8 or 16 octet boundary.

Right, that text should be removed.

(there was an interpretation error of RFC4191 from my part earlier.)

Alex

>
> Section 4.2 "Operationally there could be a problem unless all hosts
> on a link use IIDs of the same length to configure a link-local
> address during reboot.  Typically today the choice of 64 bits for the
> link-local IID length is hard-coded per interface, and systems behave
> as if the link local prefix was actually fe80::/64. "
>
> remove "during reboot". the prefix length for a global prefix doesn't
> have to be the same as for the link-local address. perhaps rather
> make it clear that since there is no way to configure the link-local
> prefix length, it will be a as defined in IPv6 over foo documents
> regardless of what the global prefix is.
>
> Section 4.4: At least one DHCPv6 client unconditionally installs a
> /64 prefix as on-link when it configures an interface with an
> address, although some specific operating system vendors seem to
> change this default behavior by tweaking a client-side script.  It
> does this (even if technically it violates the protocol) because if
> there is no router on the link, the hosts effectively would fail to
> communicate each other with the configured addresses because the
> "on-link assumption" was removed in [RFC4861].  This is not really
> about the magic number of 64, but an implementation may sometimes
> pick a specific value of prefix length due to the removal of the
> on-link assumption, and the value chosen will most likely be 64.
>
> if so, that is in violation of RFC5942. I don't think this document
> should make a case for different behaviour than 5942 requires. just
> drop the whole paragraph?
>
> Section 4.5: "A prefix long enough to limit the number of addresses
> comparably to an IPv4 subnet, such as /120, would create exactly the
> same situation for privacy as IPv4 except for the absence of NAT.  In
> particular, a host would be forced to pick a new IID when roaming to
> a new network, to avoid collisions.  An argument could be made that
> since this reduces traceability, it is a good thing from a privacy
> point of view."
>
> does that logic hold water? outside of the network using the longer
> prefixes, an attacker would still have to track or guess the prefix
> length set of bits.
>
> privacy-wise you could make the reverse argument as well. that a
> constant subnet prefix assigned to every end-user, means that I can
> now make fairly safe assumptions that I can track a given end-user by
> tracking the /64. which doesn't help privacy.
>
>
> cheers, Ole
>
>
>
>> Title           : Analysis of the 64-bit Boundary in IPv6
>> Addressing Authors         : Brian Carpenter Tim Chown Fernando
>> Gont Sheng Jiang Alexandru Petrescu Andrew Yourtchenko Filename
>> : draft-ietf-6man-why64-01.txt Pages           : 23 Date
>> : 2014-05-07
>>
>> as an Informational RFC.  Substantive comments and statements of
>> support for publishing this document should be directed to the
>> mailing list.  Editorial suggestions can be sent to the authors.
>> This last call will end on July 4, 2014.
>>
>> Regards,
>>
>> Bob Hinden & Ole Trøan
>>
>
>
>
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jul 2014 08:38:21 +1200

>>    routing protocols, it could be anything (in theory) between /1 and /

Well, that's the default route, and it seemed to me when I drafted
that sentence that describing something of length zero as a prefix
was a bit odd. I don't feel strongly, however.

Ole: thanks for the comments. We'll wait for other reviews before
editing the text.

    Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 30 Jul 2014 04:25:55 -0700

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: Lorenzo Colitti <[email-masked]>
> Cc: 6man WG <[email-masked]>; Bob Hinden <[email-masked]>
> Sent: Wednesday, 30 July 2014 6:38 AM
> Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-why64-01.txt>
> 

I've done a first run though, I'll do another over the next few days and should be able to send comments etc. through Sunday evening.

Regards,
Mark.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 30 Jul 2014 13:43:59 -0700

At Tue, 29 Jul 2014 15:46:29 +0200,

> just drop the whole paragraph?

(I believe) it was me who suggested including this issue in this
document, so I'll respond: at least I didn't intend to endorse this
behavior by mentioning it (if you meant that by "make a case for").
In fact, this text event explicitly notes that it violates the
protocol, although today we might remove "even if", and explicitly
refer to RFC5942 instead of just saying "the protocol".  Also, my
understanding of Section 4.4 is that it generally discusses known real
world issues with implementations that assume a prefix length of 64
bits, some of which could in fact violate the standard.  So I don't
think we should necessarily remove an example simply because it's
about a non-compliant implementation.  In this specific case, I
thought it would be worth noting because this particular
implementation (ISC DHCPv6 client) should be quite widely used, and
because the seeming background reason for this behavior could lead to
other similar broken implementations.

If you and others still think this issue should be dropped with the
clarified intent, I wouldn't necessarily be opposed to that; I just
thought this issue would be useful in general in the context of this
document but that's probably only me.  On the other hand, if the
issue is about specific text rather than the intent and specific
example, IMO we should try to fix the textual issue rather than remove
it.  In the latter case, it would depends on specifically what you
thought was a problem, but if it's that this text could read as if it
endorses the broken behavior, one resolution would clarify that it
violates RFC5942 more explicitly.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Jul 2014 08:54:01 +1200

Ole,

I think we shouldn't drop it; IMHO we should adjust the text to make
it clear that this is faulty behaviour.

    Brian

---

From: David Farmer <[email-masked]>
Date: Wed, 30 Jul 2014 16:59:02 -0500

I concur it shouldn't just be dropped.  This is the kind of 
misunderstanding that needs to be pointed out.  I always read the text 
as pointing out faulty behavior that should be corrected and not 
repeated. But if that intent can be clarified and strengthened, then 
please do so.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Ole Troan <[email-masked]>
Date: Thu, 31 Jul 2014 09:25:21 +0200

> it clear that this is faulty behaviour.

that's fine with me.
my reading of the current text was that it made it appear that it was acceptable of an implementation to just make up a prefix length, if none was given. as long as the text makes it clear that if it has no prefix length, then there is no on-link prefix...

cheers,
Ole