Subject: 6MAN WG Last Call: draft-ietf-6man-ipv6-address-generation-privacy-02.txt

From: Bob Hinden <[email-masked]>
Date: Fri, 5 Dec 2014 17:27:17 -0800

This message starts a two week 6MAN Working Group Last Call on advancing:

       Title           : Privacy Considerations for IPv6 Address Generation Mechanisms
       Authors         : Alissa Cooper
                         Fernando Gont
                         Dave Thaler
       Filename        : draft-ietf-6man-ipv6-address-generation-privacy-02.txt
       Pages           : 16
       Date            : 2014-10-10

       https://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy-02   

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 December 19, 2014.

Regards,

Bob Hinden & Ole Trøan

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 6 Dec 2014 13:33:02 +0900

> https://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy-02

I object to this statement and would like to see it removed:

===
Hiding this information is one motivation for using NAT in IPv6 (see RFC
5902 section 2.4).
===

First, the text does not make sense. It says that IPv4 addresses reveal
information about the location of subnets. Then it says that not revealing
this information is a motivation for using NAT. But in IPv4, NAT is
pervasive. If NAT avoids revealing this information, then why do IPv4
addresses reveal this information as well?

Second, RFC 5902 makes no claim that hiding location information is one
motivation for using NAT in IPv6. It makes a very nuanced statement that
uses words like "it is perceived" and "does not necessarily prove
sufficient" etc.

Also - is there evidence that people are using IPv6 NAT for this? Do we
know of any such deployments?

Instead of mentioning NAT, it would be better to provide a more useful
consideration: if privacy is desired, then prefixes need to be rotated as
well.

Regards,
Lorenzo

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 8 Dec 2014 01:18:15 +0000 (UTC)

>________________________________
> From: Lorenzo Colitti <[email-masked]>
>To: Bob Hinden <[email-masked]> 
>Cc: 6man Chairs <[email-masked]>; 6man WG <[email-masked]> 
>Sent: Saturday, 6 December 2014, 15:33
>Subject: Re: 6MAN WG Last Call: draft-ietf-6man-ipv6-address-generation-privacy-02.txt
> 
>
>
>Hiding this information is one motivation for using NAT in IPv6 (see RFC 5902 section 2.4).
>===
>
>
>First, the text does not make sense. It says that IPv4 addresses reveal information about the location of subnets. Then it says that not revealing this information is a motivation for using NAT. But in IPv4, NAT is pervasive. If NAT avoids revealing this information, then why do IPv4 addresses reveal this information as well?
>
>
>Second, RFC 5902 makes no claim that hiding location information is one motivation for using NAT in IPv6. It makes a very nuanced statement that uses words like "it is perceived" and "does not necessarily prove sufficient" etc.
>
>
>Also - is there evidence that people are using IPv6 NAT for this? Do we know of any such deployments?
>
>
>Instead of mentioning NAT, it would be better to provide a more useful consideration: if privacy is desired, then prefixes need to be rotated as well.
>

Referring to RFC4864, "Local Network Protection for IPv6" in regards to this specific topic might be useful as it is about how to achieve IPv4 NAT like things without IPv6 NAT.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Dec 2014 08:28:24 +1300

I am all for this draft.

I think it would be useful for the reader to include informative
references to RFC 7136 and RFC-to-be draft-ietf-6man-why64
in the Introduction. The three documents together give a complete
picture, I think.

Regards
   Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 9 Dec 2014 00:17:01 +0000 (UTC)

I support publishing this document.

----- Original Message -----
> From: Bob Hinden <[email-masked]>
> To: 6man WG <[email-masked]>
> Cc: 6man Chairs <[email-masked]>
> Sent: Saturday, 6 December 2014, 12:27
> Subject: 6MAN WG Last Call: draft-ietf-6man-ipv6-address-generation-privacy-02.txt
> 
>T his message starts a two week 6MAN Working Group Last Call on advancing:
> 
> 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 December 19, 
> 2014.
> 
> Regards,
> 
> Bob Hinden & Ole Trøan
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Dec 2014 05:31:36 -0300

Hi, Brian,

> in the Introduction. The three documents together give a complete

If you have a concrete suggestion of where/how exactly to achive that,
please do let us now. Otherwise I'll craft some text myself.

P.S.: FWIW, without re-reading our I-D, I'd say I'd expect our document
to contain references to both of the documents you've mentioned. So if
it doesn't, good grief!

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Dec 2014 09:20:32 -0300

Hi, Lorenzo,

On 12/06/2014 01:33 AM, Lorenzo Colitti wrote:
> On Sat, Dec 6, 2014 at 10:27 AM, Bob Hinden <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>          
> information about the location of subnets. Then it says that not
> revealing this information is a motivation for using NAT. But in IPv4,
> NAT is pervasive. If NAT avoids revealing this information, then why do
> IPv4 addresses reveal this information as well?

Re-reading the text (I had forgotten this text was even there), I'd say
you're misreading the text.

It essentially says: Addresses reveal information about subnets, as in
IPv4. However, such information is concealed by NATs in the IPv4
world... and that's indeed one of the motivations for using IPv6 NAT.

FWIW, I could personally live without such sentence, or even without
Section 5.1 as a whole (well, its just a para). - I'll let the other
co-authors weigh in.

> know of any such deployments?

I'd probably say it has t do with topology and host obfuscation than
hiding "geographic location".

> consideration: if privacy is desired, then prefixes need to be rotated
> as well.

You mean the subnets being renumbered over time?

Thanks!

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 9 Dec 2014 21:33:08 +0900

> hiding "geographic location".

That doesn't answer the question, though. Are people doing this?

Also - if it doesn't have to do with geographic location, then the
statement should not be the only statement in a section entitled
"geographic location".

I thought the point of this draft was how to preserve privacy without using
NAT? If you assume the presence of a NAT there's little point ensuring the
interface ID does not expose information.

> You mean the subnets being renumbered over time?

Yes.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Dec 2014 09:46:38 -0300

Hi, Lorenzo,

> That doesn't answer the question, though. Are people doing this?

Yes. I'm aware of folks requiring IPv6 NAT "or else we will not deploy it".

> statement should not be the only statement in a section entitled

Me, I'm of the idea that that section doesn't add much. Hence my comment
of "could live without it". At least, one might want to expand it a bit.

> I thought the point of this draft was how to preserve privacy without
> using NAT? 

The goal of this I-D is to analyze the security and privacy prperties of
IPv6 addressing.

> If you assume the presence of a NAT there's little point
> ensuring the interface ID does not expose information.

Agreed.

>     You mean the subnets being renumbered over time?

Me, I'd prefer not to get into that. :-)

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 9 Dec 2014 21:54:41 +0900

> Yes. I'm aware of folks requiring IPv6 NAT "or else we will not deploy it".

If that's the reason for having this text there, then we should remove it.

I've heard "we need X or else we will not deploy IPv6" over and over again.
Every time it has meant "we don't see a strong enough business reason to
deploy IPv6, and the first technical obstacle that comes to mind is X".

In practice, what usually happens is that when X is delivered, the
statement changes to "we need Y or else we will not deploy IPv6" - and now
you've done the work to provide X and suffered any consequences, but no
deployment resulted.

In any case, if we want to talk about IPv6 NAT, then we should not talk
about it in a section buried somewhere in a document on IPv6 interface ID
generation. It's a controversial topic, and if we want to discuss it we
should do so properly.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Dec 2014 10:42:44 -0300

On 12/09/2014 09:54 AM, Lorenzo Colitti wrote:
> On Tue, Dec 9, 2014 at 9:46 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

No, that's the answer to your question. And people do this. But then...
people do lots of things.. so this shouldn't be news....

> statement changes to "we need Y or else we will not deploy IPv6" - and
> now you've done the work to provide X and suffered any consequences, but
> no deployment resulted.
> 
> about it in a section buried somewhere in a document on IPv6 interface
> ID generation. It's a controversial topic, and if we want to discuss it
> we should do so properly.

As noted, I personally think that the aforementioned section (at least
"as is") doesn't add much... and hence can personally live without it.
I'll let the other co-authors weigh in.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Dec 2014 13:58:05 +1300

> I'll let the other co-authors weigh in.

I felt that we had put this line of argument to bed seven years ago
with RFC 4864, and the NPTv6 document also covers it. So you could drop
it here or reduce it to citations.

    Brian

---

From: 神明達哉 <[email-masked]>
Date: Fri, 12 Dec 2014 09:22:31 -0800

At Fri, 5 Dec 2014 17:27:17 -0800,

> 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.  Thi…

I've read it, and I support for the publication.  I found it useful and
didn't notice anything obviously wrong (although it's quite possible
that I overlooked something as I'm not particularly a privacy/security
expert).

--
JINMEI, Tatuya

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 22 Dec 2014 15:09:49 -0800

> I'll let the other co-authors weigh in.

I’m fine with dropping section 5.1.
Alissa