Subject: Re: [Int-area] draft-boucadair-intarea-nat-reveal-analysis

From: <[email-masked]>
Date: Fri, 2 Sep 2011 14:32:23 +0200

Dear all,

I have just submitted a new version of the document: http://www.ietf.org/id/draft-boucadair-intarea-nat-reveal-analysis-04.txt

The new version:

* clarifies more the discussion about HOST_ID and privacy
* update the section about TCP option
* add a note about the issue in IPv6 context.

I cceed authors of I-D.morris-privacy-considerations so that they can check the content of the privacy section. Your feedback is more than welcome.

We didn't sketched any recommendation yet in the document. We will propose one once the analysis section is frozen.

Comments and suggestions on how to make this item progress are encouraged.

Cheers,
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : vendredi 22 juillet 2011 23:10
À : [email-masked]
Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Objet : draft-boucadair-intarea-nat-reveal-analysis

I realize INTAREA is not meeting at IETF81, but we would like to bring
attention to the informational document
http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis,
abstract:
  "This document analyzes a set of solution candidates which have been
   proposed to mitigate some of the issues encountered when address
   sharing is used.  In particular, this document focuses on means to
   reveal a host identifier when a Carrier Grade NAT (CGN) is involved
   in the path.  This host identifier must be unique to each host under
   the same shared IP address.

   The ultimate goal is to assess the viability of proposed solutions
   and hopefully to make a recommendation on the more suitable
   solution(s)."

This document seems to belong in INTAREA, considering the various solutions
to the abuse problem described in that document is due to IPv4 address 
sharing, and INTAREA has already taken on documents related to IPv4 
address sharing:
  draft-ietf-intarea-shared-addressing-issues       (RFC6269)
  draft-ietf-intarea-server-logging-recommendations (RFC6302)

Based on that analysis document, the most preferred solution is 
draft-wing-nat-reveal-option (standards track).  I expect we will
pursue draft-wing-nat-reveal-option in BEHAVE or perhaps TSVWG.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 6 Sep 2011 16:37:19 -0700

Dearest Internet Area,

The INTAREA document RFC6269 discussed the harm of IPv4 abuse in
http://tools.ietf.org/html/rfc6269#section-13.1 and we're trying to see if
there is interest in solving the problem for IPv4 users -- some of whom
cannot or will not upgrade to IPv6 (IPv4-only television, Roku streaming
player, Grandma's Windows 95 box, etc.).  If this isn't solved, IPv4 will
become a cesspool or very expensive to continue to operate for content
providers (who will have to terminate TCP and TLS sessions for abusers and
legitimate users, alike).

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dan Wing
> Sent: Friday, July 22, 2011 2:10 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Int-area] draft-boucadair-intarea-nat-reveal-analysis
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: "Lee Howard" <[email-masked]>
Date: Wed, 7 Sep 2011 14:05:57 -0400

Is it true that the stacks/applications on the devices you name could
be updated as described, but could not be updated to support IPv6?

That section of rfc6269 says blacklisting and penalty boxes won't work.
For the solutions offered, the effort of draining the cesspool may be 
greater than living with the stink (or moving to the new house with all
the extra bits).

The draft nicely describes the solution space, though.

Lee

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dan
> Wing
> Sent: Tuesday, September 06, 2011 7:37 PM
> To: [email-masked]
> Subject: [Int-area] IPv4 address sharing abuse [was RE:
draft-boucadair-intarea-nat-reveal-
> analysis]

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 7 Sep 2011 12:05:15 -0700

> From: Lee Howard [mailto:[email-masked]]
> Sent: Wednesday, September 07, 2011 11:06 AM
> To: 'Dan Wing'; [email-masked]
> Subject: RE: [Int-area] IPv4 address sharing abuse [was RE: draft-
> boucadair-intarea-nat-reveal-analysis]
> 

The host stacks wouldn't be updated.  

The address-sharing device (NAT, A+P router, etc.) would add the
additional data.  

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2011 19:29:31 +0200

Perhaps I repeat myself but as far as I know solutions to the
draft-boucadair-intarea-nat-reveal-analysis problem are illegal
at some places, in particular in European Union (and at a level
which overrules national texts)...
IMHO this issue should be clarified before adopting any document
as a WG item.

Regards

[email-masked]

PS: I am not a lawyer
PPS: I know that to consider the source IP address is a personal piece
of data is silly but who did say lawyers should be rational (:-)?
PPPS: of course the best should be to simply go to IPv6!

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 8 Sep 2011 10:52:25 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, September 08, 2011 10:30 AM
> To: Dan Wing
> Cc: [email-masked]; draft-boucadair-intarea-nat-reveal-
> [email-masked]
> Subject: Re: [Int-area] IPv4 address sharing abuse [was RE: draft-

Because IPv6 doesn't have source IP addresses.

-d

---

From: Simon Perreault <[email-masked]>
Date: Thu, 08 Sep 2011 14:03:20 -0400

> IMHO this issue should be clarified before adopting any document

I would argue the opposite: the IETF should completely discard this issue. Much
of the rationale behind RFC 2804 would apply equally here.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: <[email-masked]>
Date: Thu, 8 Sep 2011 20:08:32 +0200

Dear Simon,

I don't see how RFC2804 applies here. Please refer to the problem space as described in the document; in particular:

http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-04#section-1.1
http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-04#section-1.2
http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-04#section-1.3

Please let me know what I missed.

Cheers,
Med

________________________________________
De : [email-masked] [[email-masked]] de la part de Simon Perreault [[email-masked]]
Date d'envoi : jeudi 8 septembre 2011 20:03
À : [email-masked]
Objet : Re: [Int-area] IPv4 address sharing abuse [was RE:      draft-boucadair-intarea-nat-reveal-analysis]

Simon

---

From: "Lee Howard" <[email-masked]>
Date: Thu, 8 Sep 2011 14:12:51 -0400

> The address-sharing device (NAT, A+P router, etc.) would add the

I missed that text.  Now I find it: "For almost all the analyzed solutions,
the 
address sharing function injects the HOST_ID."  
The stack or application on the other side of the connection would also
have to be updated.  For instance, the web server.  Or the p2p client?

More trouble than it's worth.

Lee

---

From: Simon Perreault <[email-masked]>
Date: Thu, 08 Sep 2011 14:16:57 -0400

[email-masked] wrote, on 09/08/2011 02:08 PM:
> I don't see how RFC2804 applies here.

I was replying to Francis Dupont's statement that the IETF should clarify the
European issue with revealing somebody's IP address.

My response was that the IETF should not care about this issue. It should not
prevent this document from moving forward.

Simon

---

From: <[email-masked]>
Date: Thu, 8 Sep 2011 20:30:55 +0200

Hi Francis,

I don't know if you are talking about legal data storage or something else, but source IP address is part of the information providers are required to store for a given amount of time. There is a section in the I-D which discusses privacy concerns. 

As for your comment about IPv6, I'm afraid we have similar issues, please refer to: http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-04#section-1.3 

Cheers
Med
________________________________________
De : [email-masked] [[email-masked]] de la part de Francis Dupont [[email-masked]]
Date d'envoi : jeudi 8 septembre 2011 19:29
À : Dan Wing
Cc : [email-masked]; [email-masked]
Objet : Re: [Int-area] IPv4 address sharing abuse [was RE:      draft-boucadair-intarea-nat-reveal-analysis]

Regards

PS: I am not a lawyer

---

From: SM <[email-masked]>
Date: Thu, 08 Sep 2011 11:48:05 -0700

Hi Francis,
>IMHO this issue should be clarified before adopting any document

Are you saying that what draft-boucadair-intarea-nat-reveal-analysis 
argues for cannot be implemented in the European Union?

As a general comment, Section 1.2 of the draft discusses about 
privacy.  I have read
draft-morris-privacy-considerations-03.  I could not find which point 
in that draft, the following is based:

   "The HOST_ID does not reveal more privacy information than what the
    source IP address does in a non-shared address environment"

Regards,
-sm

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2011 23:52:46 +0200

In your previous mail you wrote:

   I would argue the opposite: the IETF should completely discard this
   issue. Much of the rationale behind RFC 2804 would apply equally
   here.
   
=> it is a very different issue than wiretapping, here the problem
is the proposed mechanisms are clearly against the end-user privacy.
So even without the legal problem at some places some of us already
believe this (HOST_ID stuff) is bad idea.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 09 Sep 2011 00:20:03 +0200

I don't know if you are talking about legal data storage or
   something else

=> no, I am talking about the privacy principle which is included
in the European Convention on Human Rights and at the exception of
the USA is in similar texts in all modern democracies.

    There is a section in the I-D which discusses privacy concerns.

=> yes, the I-D confirms the proposed mechanisms could reduce the
privacy and decribes it as "what the source IP address does in a
non-shared address environment". If this seems technically valid
I remember well some European lawyers already described the IP source
address as being a piece of personal data.
   
   As for your comment about IPv6, I'm afraid we have similar issues

=> no, in IPv6 we have RFC 4941 and the point of control is not
at the same place (i.e., nobody trusts ISPs to protect privacy :-).
   
So if you still want to go forward I strongly suggest to make HOST_ID
hard to reverse (i.e., to get the user should require the NAT logs)
and short life.

Regards

PS: cf. the discussion about this topics in the mailing list during
the March IETF meeting.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 09 Sep 2011 00:41:48 +0200

=> IMHO it may be implemented but not be deployed, and I cited
the European Union only because as a citizen I am supposed to know
its laws (treaty in this case), i.e., this should be true at al
places where privacy is protected and BTW privacy is supposed to
be a goal in IETF protocols too...

Regards

PS: I am more concerned by the potential damages this could do
to the IETF's image, this is why I said I am happy these I-Ds are
personal contribs and not WG items.

---

From: SM <[email-masked]>
Date: Thu, 08 Sep 2011 16:50:26 -0700

Hi Francis,
>=> IMHO it may be implemented but not be deployed, and I cited

Ok.

>personal contribs and not WG items.

I don't know whether this working group has the expertise to deal 
with the privacy angle.  It can end up being negative for the IETF's 
image if it publishes such work without due care to privacy.  I don't 
think it is a good idea to take this draft as a WG item.

Regards,
-sm

---

From: <[email-masked]>
Date: Fri, 9 Sep 2011 07:33:53 +0200

Hi Francis,

Please see inline.

Cheers
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : vendredi 9 septembre 2011 00:20
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Dan Wing; [email-masked]; [email-masked]
Objet : Re: RE : [Int-area] IPv4 address sharing abuse [was RE: draft-boucadair-intarea-nat-reveal-analysis] 

Med: OK.

Med: This is not the point. RFC4941 does not solve the issue of blacklisting for instance all hosts belonging to a given /64 prefix (e.g., all users of a hotel, IETF meeting, etc.). 

Med: We have this text in the current version. Do you think we should add more? 

   The volatility of the HOST_ID information is similar to the source IP
   address: a distinct HOST_ID may be used by the address sharing
   function when the host reboots or gets a new internal IP address.  If
   the HOST_ID is persistent it may be used to track a host (similar to
   persistent IP addresses).

---

From: <[email-masked]>
Date: Fri, 9 Sep 2011 07:41:02 +0200

Dear SM,

The HOST_ID can enclose the origin source IPv4 address, IPv6 address, IPv6 prefix, vlan, random value, etc. The only requirement on the HOST_ID is as mentioned in the I-D:

        "It must be unique to each host under the same
        IP address.  It does not need to be globally unique.  Of course,
        the combination of the (public) IPv4 source address and the
        identifier (i.e., HOST_ID) ends up being relatively unique.  As
        unique as today's 32-bit IPv4 addresses which, today, can change
        when a host re-connects."

As such the HOST_ID does not reveal other information than the source IP address if there is no NAT in the path. 

According to draft-morris-privacy-considerations-03, 

   "The following list contains examples of information that may be
   considered personal data:

   o  Name

   o  Address information

   o  Phone numbers, email addresses, SIP/XMPP URIs, other identifiers

   o  IP and MAC addresses or other host-specific persistent identifiers
      that consistently links to a particular person or small, well-
      defined group of people

   o  Information identifying personally owned property, such as vehicle
      registration number"

IP addresses and host-specific persistent identifiers are on the same level and may be considered as personal data. This is why we have the following in the draft:

  "If the HOST_ID is persistent it may be used to track a host (similar to
   persistent IP addresses)."

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de SM
Envoyé : jeudi 8 septembre 2011 20:48
À : Francis Dupont
Cc : [email-masked]
Objet : Re: [Int-area] IPv4 address sharing abuse [was RE: draft-boucadair-intarea-nat-reveal-analysis]

Hi Francis,

Regards,
-sm

---

From: <[email-masked]>
Date: Fri, 9 Sep 2011 07:54:04 +0200

Hi Francis,

Just a clarification, as mentioned in the draft-boucadair-intarea-nat-reveal-analysis:

   The purpose of this document is not to argue in favor of mandating
   the use of a HOST_ID but to document encountered issues, proposed
   solutions and their limitations.

We believe discussions are needed to understand the implication of analyzed solutions which are BTW not new, since some of the proposed solutions are already deployed (e.g., XFF in Load-balancers).

You expressed your concern about privacy which a legitimate question to raise. This is why we have dedicated a section for it in the current version.  

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Francis Dupont
Envoyé : vendredi 9 septembre 2011 00:42
À : SM
Cc : [email-masked]
Objet : Re: [Int-area] IPv4 address sharing abuse [was RE: draft-boucadair-intarea-nat-reveal-analysis]

   

Regards

---

From: <[email-masked]>
Date: Fri, 9 Sep 2011 08:03:01 +0200

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de SM
Envoyé : jeudi 8 septembre 2011 20:48
À : Francis Dupont
Cc : [email-masked]
Objet : Re: [Int-area] IPv4 address sharing abuse [was RE: draft-boucadair-intarea-nat-reveal-analysis]

Hi Francis,

Med: Just a clarification,  draft-boucadair-intarea-nat-reveal-analysis does not argue in favor of mandating the use of a HOST_ID  or not. It only documents encountered issues, proposed solutions and their limitations. Doing so would (hopefully) help IETF making a recommendation on the next steps in this area. Examples of next steps may include:

(1) Recommend a solution?:  but individual solutions need to discuss potential impact on performance, mis-usage of the solution to reveal other "sensitive" information, etc.

(2) Add a conclusion to say: "IETF has documented the issues (RFC6269) and has analyzed solution candidates but IETF believes CGN should stay evil"?: The risk is the emergence of proprietary solutions. 

(3) Add a statement like "IPv6 will solve this?": but this does not mitigate the service brokenness to be encountered by subscribers when address sharing will be deployed at large. The issues are also valid for NAT64, etc.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 09 Sep 2011 08:46:07 +0200

Med: This is not the point. RFC4941 does not solve the issue of
   blacklisting for instance all hosts belonging to a given /64 prefix
   (e.g., all users of a hotel, IETF meeting, etc.).

=> and what you want to do if for instance someone blacklists all hosts
belonging to a give /32 prefix?

   Med: We have this text in the current version. Do you think we
   should add more?
   
=> add far more

=> it doesn't need to be persistent: it just need to have medium/long life.
So IMHO you should develop the text from the last statement and forget
any reference to the source IP address.
(or give up about the whole idea)

Regards

---

From: <[email-masked]>
Date: Fri, 9 Sep 2011 10:23:02 +0200

Re-,

I updated the text as follows:

OLD:

NEW:

   The volatility of the HOST_ID information is similar to the source IP
   address: a distinct HOST_ID may be used by the address sharing
   function when the host reboots or gets a new internal IP address.  If
   the HOST_ID is assigned with mid or long lifetime, it may be used to
   track a host.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : vendredi 9 septembre 2011 08:46
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Dan Wing; [email-masked]; [email-masked]
Objet : Re: RE : [Int-area] IPv4 address sharing abuse [was RE: draft-boucadair-intarea-nat-reveal-analysis] 

   

   
   
=> add far more

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 09 Sep 2011 10:56:10 +0200

NEW:

=> I believe you didn't catch my idea: the HOST_ID should be hard to use
to track a host: the enhance privacy is one of the rare benefits from
using a CGN so it is *not* something we should suppress.

Regards

---

From: SM <[email-masked]>
Date: Fri, 09 Sep 2011 02:28:33 -0700

Dear Med,
At 22:41 08-09-2011, [email-masked] wrote:
>The HOST_ID can enclose the origin source IPv4 address, IPv6 
>address, IPv6 prefix, vlan, random value, etc. The only requirement 
>on the HOST_ID is as mentioned in the I-D:
>
>As such the HOST_ID does not reveal other information than the 
>source IP address if there is no NAT in the path.
>
>
>IP addresses and host-specific persistent identifiers are on the 
>same level and may be considered as personal data. This is why we 
>have the following in the draft:

I'll mention the paragraph below the one you quoted:

   "Searching only for those example as an indication for the need of
    privacy is, however, insufficient given that the list above is
    constantly growing and depends very much on the context.  An
    information element may not be sensitive in one context but
    considered very sensitive in another."

Identifiers are used in different protocols.  Some of the identifiers 
in the list mentioned above are necessary for the protocol to fulfill 
its intended function.  If we are talking about IP addresses, it is 
important to take into account the context in which it is being 
used.  In the draft, the identifier is being added by an 
intermediary.  And that is where it can become problematic.

>    persistent IP addresses)."

draft-boucadair-intarea-nat-reveal-analysis discusses about 
identification and addressing abuse issues and defines a HOST_ID 
identifier.  The discussion about privacy can be summarized as an 
analogy with source IP addresses.  You are saying that the HOST_ID 
can be an issue only if it is persistent.  I suggest that you give 
some thought to context and also the consent angle.

At 23:03 08-09-2011, [email-masked] wrote:
>Med: Just a 
>clarification,  draft-boucadair-intarea-nat-reveal-analysis does not 
>argue in favor of mandating the use of a HOST_ID  or not. It only 
>documents encountered issues, proposed solutions and their 
>limitations. Doing so would (hopefully) help IETF making a

BTW, the problem statement (Section 1.1) needs some more work.  The 
problem to be solved is not stated clearly.

>recommendation on the next steps in this area. Examples of next 
>steps may include:
>
>(1) Recommend a solution?:  but individual solutions need to discuss 
>potential impact on performance, mis-usage of the solution to reveal 
>other "sensitive" information, etc.

There is a privacy mailing list.  You could ask for some feedback 
about how the proposal affects privacy.  I don't know how helpful it 
may be as that list is not very active.

>(2) Add a conclusion to say: "IETF has documented the issues 
>(RFC6269) and has analyzed solution candidates but IETF believes CGN 
>should stay evil"?: The risk is the emergence of proprietary solutions.

Although I have an opinion about CGNs, I won't say it is "evil" as 
the discussion won't have a constructive tone then.

>(3) Add a statement like "IPv6 will solve this?": but this does not 
>mitigate the service brokenness to be encountered by subscribers 
>when address sharing will be deployed at large. The issues are also 
>valid for NAT64, etc.

IPv6 is not really a solution to everything.  It would be argued that 
someone designed a technology without giving adequate consideration 
to how it will break existing services; i.e. solving a problem at one 
layer while pushing other problems to higher layers.

BTW, you discussed about traceability in RFC 6269.  This draft takes 
a different approach.  It's not that it is the "wrong" approach.  It 
injects an intractable problem into the discussion.

Regards,
-sm

---

From: Maglione Roberta <[email-masked]>
Date: Fri, 9 Sep 2011 12:49:55 +0200

Francis,
> using a CGN so it is *not* something we should suppress.

The enhance privacy that you consider *a rare benefit from the CGN* it is actually a BIG issue for a Service Provider, because we are quite often requested by the authorities to be able to track who was the user who did something and the only information that we have is the source IP address.

Being able to identify the users behind NAT, for example by using the HOST_ID proposed in this draft, is in my opinion an important problem to be solved no only for content providers but also for Service Providers.

Best regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francis Dupont
Sent: venerdì 9 settembre 2011 10.56
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Int-area] RE : IPv4 address sharing abuse [was RE: draft-boucadair-intarea-nat-reveal-analysis]

   NEW:

Regards

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 09 Sep 2011 14:02:14 +0200

The enhance privacy that you consider *a rare benefit from the CGN*
   it is actually a BIG issue for a Service Provider, because we are
   quite often requested by the authorities to be able to track who
   was the user who did something and the only information that we
   have is the source IP address.
   
=> with only the source IP address there is nothing you can do so
your argument is not about the problem analyzed in Mohammed's I-D,
but for authorities who need to understand what is a CGN
(or to make CGNs illegal... :-).

   Being able to identify the users behind NAT, for example by using
   the HOST_ID proposed in this draft, is in my opinion an important
   problem to be solved no only for content providers but also for
   Service Providers.
   
=> the HOST_ID doesn't solve anything if the authorities provide
only the source IP address in their identification requests,
and if they provide more they can provide the source port...

Regards

---

From: "George, Wesley" <[email-masked]>
Date: Tue, 13 Sep 2011 09:15:39 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francis Dupont
Sent: Friday, September 09, 2011 4:56 AM

WEG] This notion bothers me rather a lot, and I think we need to tread *very* carefully here. CGN should be by definition a limited-scope, limited lifetime item to get us over the hump of IPv6 adoption, and the less deployment of it the better. I do NOT want to set the precedent that the privacy provided by the way that CGN or HOST_ID is implemented is a desirable thing such that we are then forced to push similar functionality across the entirety of our IPv4 networks. Any privacy enhancement is purely incidental, not a design goal, and it needs to stay that way. Similarly to the way that other forms of NAT were rapidly conflated with security and privacy and have more or less completely broken end-to-end communications because they're so pervasive, if we go down this road, we are not going to like where it ends up. At best, we end up having to do more work to buff the IPv4 turd to reach the new bar set for privacy without having to use CGN, at worst, we end up having to deploy CGN everywhere to implement this privacy technique.

Let me be clear that I do support considering the privacy implications of this implementation, including any applicable laws. But that said, I absolutely do not want to highlight any benefits to doing CGN beyond simple need for address extension, nor make protocol changes to raise the bar above the current status quo for IPv4 privacy, because I don't want us to waste the effort on more duct tape for IPv4. You want privacy for source addresses? Yet one more good reason to move to IPv6 and use privacy extensions.

As to the draft itself, I agree that there is potential for a legitimate problem here, but I'm skeptical that we have enough actual time or the WG cycles to fix and deploy this pervasively enough to make a difference, especially since we'd be doing it just in order to make CGN suck less. Whether we like it or not, CGN is very likely the "IPv6 killer app" that we've all been waiting for to make IPv6 more attractive to average people.

Thanks,
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.