RE: Perils of structured host identifiers (was: Modified EUI-64 format)

To: Iljitsch van Beijnum <iljitsch at muada.com>
Subject: RE: Perils of structured host identifiers (was: Modified EUI-64 format)
From: Christian Huitema <huitema at windows.microsoft.com>
Date: Tue, 7 Jul 2009 18:27:20 +0000
Accept-language: en-US
Cc: Xing Li <xing at cernet.edu.cn>, 6man <ipv6 at ietf.org>, Behave WG <behave at ietf.org>, Brian E Carpenter <brian.e.carpenter at gmail.com>, Dave Thaler <dthaler at windows.microsoft.com>
Delivered-to: ipv6 at core3.amsl.com
In-reply-to: <AD3BEF45-A947-43CB-BD3F-D2089E13170D at muada.com>
List-archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-help: <mailto:ipv6-request@ietf.org?subject=help>
List-id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-post: <mailto:ipv6@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
References: <E4561B14EE2A3E4E9D478EBFB5416E1B0A2F5A at TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <18256DC3-184D-48FE-B37C-2F9867597304 at free.fr> <E4561B14EE2A3E4E9D478EBFB5416E1B0A5745 at TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <EB331E19-8164-4805-A412-4686D16C955F at free.fr> <4A4F5F9A.40202 at gmail.com> <268554C4-E415-492E-B950-4B9531F53CEA at free.fr> <6B55F0F93C3E9D45AF283313B8D342BA0436FB0A at TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <4A526C57-658D-4FFE-BE74-B78A82C40E9C at free.fr> <6B55F0F93C3E9D45AF283313B8D342BA04376CEC at TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <AD3BEF45-A947-43CB-BD3F-D2089E13170D at muada.com>
Thread-index: AQHJ/xjr/ZweYTKAF06hECKPTS3YqZBqYibg
Thread-topic: Perils of structured host identifiers (was: Modified EUI-64 format)

> I'm not seeing this.
>
> vXuser ----- routers ------ vXserver
>
> v6user -----  NAT64 ------ v4server
>
> In the first case, the addresses are visible everywhere. In the second
> case, the destination address (in one form or another) is visible
> everywhere. How is this suddenly a privacy issue?

Compare

        V4user ---- NAT44 ---- v4server
And
      V4user ---- NAT64 ---- v6server

If you embed the internal V4 address in the translated address, the v6 servers will see it, while the v4 servers don't.

-- Christian Huitema

Follow-Ups:
- Re: Perils of structured host identifiers (was: Modified EUI-64 format)
  - From: Iljitsch van Beijnum

References:
- Re: [BEHAVE] Modified EUI-64 format
  - From: Rémi Després
- Re: [BEHAVE] Modified EUI-64 format
  - From: Brian E Carpenter
- Re: [BEHAVE] Modified EUI-64 format
  - From: Rémi Després
- Perils of structured host identifiers (was: Modified EUI-64 format)
  - From: Christian Huitema
- Re: Perils of structured host identifiers (was: Modified EUI-64 format)
  - From: Rémi Després
- RE: Perils of structured host identifiers (was: Modified EUI-64 format)
  - From: Christian Huitema
- Re: Perils of structured host identifiers (was: Modified EUI-64 format)
  - From: Iljitsch van Beijnum

Prev by Date: Re: Perils of structured host identifiers (was: Modified EUI-64 format)
Next by Date: Re: Perils of structured host identifiers (was: Modified EUI-64 format)
Previous by thread: Re: Perils of structured host identifiers (was: Modified EUI-64 format)
Next by thread: Re: Perils of structured host identifiers (was: Modified EUI-64 format)
Index(es):
- Date
- Thread

RE: Perils of structured host identifiers (was: Modified EUI-64 format)

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.