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

To: Iljitsch van Beijnum <iljitsch at muada.com>
Subject: RE: [BEHAVE] Perils of structured host identifiers (was: Modified EUI-64 format)
From: Christian Huitema <huitema at windows.microsoft.com>
Date: Thu, 9 Jul 2009 19:55:36 +0000
Accept-language: en-US
Cc: Behave WG <behave at ietf.org>, Thaler <dthaler at windows.microsoft.com>, Dave, Xing Li <xing at cernet.edu.cn>, 6man <ipv6 at ietf.org>
Delivered-to: ipv6 at core3.amsl.com
In-reply-to: <DFE79A85-1B80-4905-9BCD-E9E1A2097ED0 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> <E4561B14EE2A3E4E9D478EBFB5416E1B0C16F6 at TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <3C634F99-C2B3-4B21-BCD8-3616037F52E2 at free.fr> <6504F50E-C15B-4233-BD5D-F917F35BB7D0 at muada.com> <6B55F0F93C3E9D45AF283313B8D342BA0437B26D at TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <DFE79A85-1B80-4905-9BCD-E9E1A2097ED0 at muada.com>
Thread-index: AQHKAJ/KuFeGOu5fCUqVXK3ZHESrp5BtnBfw
Thread-topic: [BEHAVE] Perils of structured host identifiers (was: Modified EUI-64 format)

> There are about 3.7 billion usable IPv4 addresses. Do you really want
> to make a table that big, when the IPv6 host is going to expose
> everything to every IPv6 node it talks to anyway?

Very few hosts speak to 3.7 billion peers at the same time. Those who do probably have dual stack. In most cases, the working set is much smaller. After all, the existing Nat44 keep state, and they do not explode.

-- Christian Huitema

Follow-Ups:
- Re: [BEHAVE] 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: Dave Thaler
- Re: Perils of structured host identifiers (was: Modified EUI-64 format)
  - From: Rémi Després
- Re: [BEHAVE] Perils of structured host identifiers (was: Modified EUI-64 format)
  - From: Iljitsch van Beijnum
- RE: [BEHAVE] Perils of structured host identifiers (was: Modified EUI-64 format)
  - From: Christian Huitema
- Re: [BEHAVE] Perils of structured host identifiers (was: Modified EUI-64 format)
  - From: Iljitsch van Beijnum

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

RE: [BEHAVE] 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.