Subject: RE: what problem is solved by proscribing non-64 bit prefixes?

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Tue, 30 Sep 2008 12:37:40 -0400

Mike,

Actually, you cannot just assign a /48 to each site.  The RIR H-ratio
requirements may make this infeasible.  Further, each /48 (/56 for
IANA) allocations must be registered with the RIR, which is an
administrate headache.  Finally, there is the issue of reverse lookup
registration for sites.  These are just the policy issues.

I think what Brian was trying to point up is that mapping the IPv6
sub-netting scheme to an existing IPv4 sub-netting scheme would be
easier of the number of low order bits below the prefix in an address
is the same.  For example, a IPv4 /24 with 8 low order bits below the
prefix might be mapped to a /120 IPv6 address.  Clearly, this could be
abstracted to a scheme using 2 or 4 x (32 - IPv4 prefix length) low
order bits in the IPv6 address, i.e., assign a /n, where n = 128 - 2 or
4 x (32 - IPv4 prefix length).

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 30, 2008 12:25 PM
To: [email-masked]; Dunn, Jeffrey H.
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; Sherman, Kurt
T.; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; Martin,
Cynthia E.
Subject: RE: what problem is solved by proscribing non-64 bit prefixes?

> When managing such a scheme alongside an IPv6 prefix which 
> needs to be assigned to the same set of servers, which are 
> all dual-stack, the *number* of prefixes, their *relative* 
> numbering, and the host *addresses* within the prefixes, it 
> is quickly apparent that use of only /64 prefixes makes for a 
> management nightmare, particularly if renumbering of prefixes 
> and/or servers occurs, e.g. re-balancing the VLSM arrangement 
> itself in IPv4-land.

Given that in IPv6, you can justify allocating a /48 to each
separate site, which gives you 16 bits to mirror the IPv4
subnet hierarchy, while maintaining 64 bit interface sddresses,
I don't see a technical issue here.

And I would really recommend that you upgrade all of your management
systems to fully support IPv6 instead of relying on tricks like
generating an IPv6 address by applying a transform to an existing
IPv4 address. Then you have no technical issue at all.

--Michael Dillon

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

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Tue, 30 Sep 2008 13:40:41 -0400

Pekka,

I do not agree with your statement that " If the non-64 prefixes had
not been proscribed, we wouldn't have been able to use the existing
engineering method to develop CGA/SEND specifications."  The prefix
length will always be available to the device, either as a
configuration variable or in the router advertisements.  RFC 3972 could
just as easily have used the 128 - prefix length leftmost bits of a
SHA-1 hash (160 bits).  As a result, I would call it a weakness of CGA
rather than a reason to abandon non-64 prefixes.  Further, the
inability to use CGA does not prevent the use of SEND.  RFC 3971
specifies "RSA Signature" and "Timestamp and Nonce" as options as well.

This argument also holds for the use of EUI-64 addresses in SLAAC.
There is no reason why the 128 - prefix length rightmost bits of the
EUI-64, with the additional requirement that the U/L bit would have to
be in the last rather than the first octet.

Thoughts?

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]] 
Sent: Tuesday, September 30, 2008 1:07 PM
To: Brian Dickson
Cc: Dunn, Jeffrey H.; Alexandru Petrescu; IETF IPv6 Mailing List; Ron
Bonica; [email-masked]; Pasi Eronen; Sherman, Kurt T.;
[email-masked]; [email-masked];
[email-masked]; [email-masked]; V6ops Chairs; Martin, Cynthia E.
Subject: Re: what problem is solved by proscribing non-64 bit prefixes?

On Tue, 30 Sep 2008, Brian Dickson wrote:
> Dunn, Jeffrey H. wrote:
> 
> My basic question is: What basic engineering problem is solved by
> proscribing non-64 bit prefixes?

If the non-64 prefixes had not been proscribed, we wouldn't have been 
able to use the existing engineering method to develop CGA/SEND 
specifications.  These are being leveraged in SHIM6 and potentially in 
other applications as well. Likely we couldn't even solve these 
engineering problems (at least without major drawbacks/other 
assumptions) if we couldn't have made assumptions about the 
widely-used prefix length.

That said, I personally use non-64 bit prefixes on point-to-point 
links between routers, but I have done so willingly and knowing that 
if the IETF develops anything fancy new stuff, I might not be able to 
use it or I might need to renumber.

> When managing such a scheme alongside an IPv6 prefix which needs to 
> be assigned to the same set of servers, which are all dual-stack, 
> the *number* of prefixes, their *relative* numbering, and the host 
> *addresses* within the prefixes, it is quickly apparent that use of 
> only /64 prefixes makes for a management nightmare, particularly if 
> renumbering of prefixes and/or servers occurs, e.g. re-balancing the 
> VLSM arrangement itself in IPv4-land.

I don't understand why *relative* numbering (i.e: overlapping subnet 
masks) is important in IPv6, and I'm not sure if I see the case even 
for v4.  Could you enlighten me?

I assume you refer to a scenario where on the same broadcast domain 
there are hosts which are configured with say A.B.C.0/24 length, and 
some others are configured with, say, A.B.C.D/28 prefix length.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 30 Sep 2008 19:56:47 +0200

Pekka, I also think having that 64bit boundary helped in designing CGAs. 
  They're more secure when we know IIDs must be 64bit in length.

Pekka Savola wrote:
> specifications.

If CGA addresses are a departure allowing the IID on Ethernet be 
something else than an Ethernet-derived IID (e.g. not always have fffe 
somewhere in the middle) then they (CGA IIDs) could also settle for 
less, like being 63 in length, instead of 64.  This would allow for 
further subnetting the typical /64 into two /65s, with only minimal 1bit 
decrease in security.

It may be that CGA addresses and longer-than-64bit SLAAC are not 
incompatible.

Just some thoughts.

Alex
SLAAC: IPv6 StateLess Address AutoConf

>  These are being leveraged in SHIM6 and potentially in 
> assumptions) if we couldn't have made assumptions about the widely-used 
> prefix length.
> 
> That said, I personally use non-64 bit prefixes on point-to-point links 
> between routers, but I have done so willingly and knowing that if the 
> IETF develops anything fancy new stuff, I might not be able to use it or 
> I might need to renumber.
> 
>> When managing such a scheme alongside an IPv6 prefix which needs to be 
>> assigned to the same set of servers, which are all dual-stack, the 
>> *number* of prefixes, their *relative* numbering, and the host 
> masks) is important in IPv6, and I'm not sure if I see the case even for 
> v4.  Could you enlighten me?
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: <[email-masked]>
Date: Wed, 1 Oct 2008 11:32:52 +0100

> Actually, you cannot just assign a /48 to each site.  The RIR 
> H-ratio requirements may make this infeasible.  Further, each 
> /48 (/56 for
> IANA) allocations must be registered with the RIR, which is 
> an administrate headache.  Finally, there is the issue of 
> reverse lookup registration for sites.  These are just the 
> policy issues.

I don't believe that /48 assignments have to be registered with
the RIR unless it is a situation where an ISP is assigning the
/48 to another entity. Within an enterprise, /48 assignments to
a site do not need any RIR interaction. In addition, if you
are a large organization, then the RIRs will give you a /32 ISP
allocation which should be enough forever, except for a few of
the very largest companies. Those companies should actually plan
ahead and get a bigger than /32 allocation to begin with. The 
H-ratio should only ever be an issue for ISPs since their networks
are expected to grow continuously and eventually outgrow any allocation.

However, RIR rules are set by the networking community collectively
and bad rules can be changed.

--Michael Dillon

---

From: <[email-masked]>
Date: Wed, 1 Oct 2008 11:35:12 +0100

> In a typical IPv6 ADSL household landscape...
> 
> An ADSL IPv6 operational deployment offers a /64 prefix at 
> home.  With that, I can't subnet _and_ use IPv6 stateless 
> auto-configuration.

In a typical IPv6 ADSL household landscape the ISP will assign
you a /48 with plenty of subnetting space. In some regions
there will be some ISPs who will only assign a /56 to residential
sites, but that still gives you a reasonable amount of subnetting
ability. Under RIR rules, an ISP can justify giving you a /48
if you ask them for it.

--Michael Dillon

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Oct 2008 14:55:12 +0200

[email-masked] wrote:
>> An ADSL IPv6 operational deployment offers a /64 prefix at home.
>> With that, I can't subnet _and_ use IPv6 stateless 
>> auto-configuration.
> 
> In a typical IPv6 ADSL household landscape the ISP will assign you a
> /48 with plenty of subnetting space.

Not sure, FWIW, in the IPv6 ADSL household I live in gives me a /64 and 
not /48 (see draft-despres-v6ops-6rd-ipv6-rapid-deployment-01.txt).

That's typical for me but I don't know about the other deployed IPv6 
ADSL, do they give /64 or shorter prefixes?

Alex

> In some regions there will be some ISPs who will only assign a /56 to
> residential sites, but that still gives you a reasonable amount of
> subnetting ability. Under RIR rules, an ISP can justify giving you a
> /48 if you ask them for it.
> 
> --Michael Dillon
> 
>

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Wed, 1 Oct 2008 09:04:59 -0400

More to the point, what would a individual household do with Avogadro's
number worth of IPv6 addresses (2^80 = 1.2x10^24)?  This seems
extremely wasteful.  Further, a reasonable sized ISP with a couple of
million customers would require a /28 or more just for their
residential customer base.  This sounds like a prescription for address
exhaustion.

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Wednesday, October 01, 2008 8:55 AM
To: [email-masked]
Cc: Dunn, Jeffrey H.; [email-masked]; [email-masked];
[email-masked]; [email-masked]; Sherman, Kurt
T.; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; Martin, Cynthia E.
Subject: Re: what problem is solved by proscribing non-64 bit prefixes?

Alex

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 1 Oct 2008 15:08:28 +0200 (CEST)

On Wed, 1 Oct 2008, Alexandru Petrescu wrote:

>>> With that, I can't subnet _and_ use IPv6 stateless auto-configuration.
>> 
> Not sure, FWIW, in the IPv6 ADSL household I live in gives me a /64 and not 
> /48 (see draft-despres-v6ops-6rd-ipv6-rapid-deployment-01.txt).
>
> That's typical for me but I don't know about the other deployed IPv6 ADSL, do 
> they give /64 or shorter prefixes?

The draft-despres-v6ops-6rd-ipv6-rapid-deployment-01.txt is largely 
irrelevant in this discussion, This draft describing a particular solution 
that can be implemented by the ISPs if:
1. they have complete operational control over the CPEs installed users
2. They want to implement IPv6 quickly
3. They users are using only one subnets which is the allocated /64.

In general - my recommendation when I giving tutorials about IPv6:

- /48 to /128 is delegated to end users
- /48 general case, /47 if justified for bigger networks
- /64 if one and only one network is required
- /128 if it is sure that one and only one device is going to be connected

between /48 - /64 up to you if you are cautious about address conservation:
- but use nibble boundary for easier reverse DNS delegation.

Regards,
 		Janos Mohacsi:

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Oct 2008 15:15:39 +0200

Mohacsi Janos wrote:
>> Not sure, FWIW, in the IPv6 ADSL household I live in gives me a /64 
>> and not /48 (see draft-despres-v6ops-6rd-ipv6-rapid-deployment-01.txt).
>>
> irrelevant in this discussion,

Well thank you for the note :-)  That's what I live with :-)  I'll 
deviate the discussion in another thread.

> - but use nibble boundary for easier reverse DNS delegation.

I think that sounds as good, careful recommendation, except that maybe a 
/48 delegated to a household (be that a castle) is too much.

Alex

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Wed, 1 Oct 2008 09:27:46 -0400

Janos,

You raise an excellent point with respect to using nibble boundaries.
If one uses a partitioning scheme like that in RFC 3531 AND require
that partitions (sets of prefixes) be on nibble boundaries, a /32
allocation with a 64-bit prefix length contains only 8 partitions of 4
bits each.  This yields just 16 possible subnets per partition.  If one
allows a 96-bit prefix length, the number of nibble partitions jumps to
16 or, alternately, the size of the 8 partitions grows to 8 bits (256
subnets).

In addition to simplifying reverse DNS lookup, nibble boundary
partitioning makes it far easier to identify subnets belonging to the
same partition.  This reduces IP address management complexity.

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mohacsi Janos
Sent: Wednesday, October 01, 2008 9:08 AM
To: Alexandru Petrescu
Cc: Sherman, Kurt T.; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; Martin,
Cynthia E.
Subject: Re: what problem is solved by proscribing non-64 bit prefixes?

auto-configuration.
> Not sure, FWIW, in the IPv6 ADSL household I live in gives me a /64
and not 
> That's typical for me but I don't know about the other deployed IPv6
ADSL, do 

irrelevant in this discussion, This draft describing a particular
solution 

- /48 to /128 is delegated to end users
- /48 general case, /47 if justified for bigger networks
- /64 if one and only one network is required
- /128 if it is sure that one and only one device is going to be
connected

between /48 - /64 up to you if you are cautious about address
conservation:
- but use nibble boundary for easier reverse DNS delegation.

Regards,
 		Janos Mohacsi:

---

From: "TJ" <[email-masked]>
Date: Wed, 1 Oct 2008 09:54:36 -0400

While the IETF's answer is, effectively, Yes - "/48 delegated to a
household" the world (or atleast ARIN :)) believes /56's are a more
reasonable size - and I tend to agree.

WRT "a reasonable sized ISP with a couple of million customers would require
a /28 or more just for their residential customer base" (nic'ed from another
mail in this thread) ... the IETF says that is fine, they should simply
request the space.  Some have already done so.  
((This concern is exactly why ARIN recommends /56s.  Problem solved?))

/TJ
PS - fairly late reminder, the v4v6Coexistence "interim" meeting is ongoing
now'ish --> http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim 

>Alexandru Petrescu
>Sent: Wednesday, October 01, 2008 9:16 AM
>To: Mohacsi Janos
>Cc: Alexandru Petrescu; [email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked]; draft-
>[email-masked]; [email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked]
>Well thank you for the note :-)  That's what I live with :-)  I'll deviate
>the discussion in another thread.
>

---

From: "TJ" <[email-masked]>
Date: Wed, 1 Oct 2008 10:01:22 -0400

>-----Original Message-----  (SNIPPED FOR BREVITY))
>If one uses a partitioning scheme like that in RFC 3531 AND require that
>partitions (sets of prefixes) be on nibble boundaries, a /32 allocation
with
>a 64-bit prefix length contains only 8 partitions of 4 bits each.  This
>yields just 16 possible subnets per partition.  If one allows a 96-bit

Actually, a /64 always falls on a nibble boundary.
As does a /56.
Regardless of left-most, center-most or right-most allocation methodology,
future scalability concerns, etc.
No bits lost, yes?

/TJ

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Wed, 1 Oct 2008 10:08:02 -0400

TJ,

I am not sure what point you are trying to make.  I never said any bits
were "lost," just that longer prefixes make logical address
partitioning easier and more flexible.  Am I wrong?

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
TJ
Sent: Wednesday, October 01, 2008 10:01 AM
To: [email-masked]
Subject: RE: what problem is solved by proscribing non-64 bit prefixes?

>If one uses a partitioning scheme like that in RFC 3531 AND require
that
with

Actually, a /64 always falls on a nibble boundary.
As does a /56.
Regardless of left-most, center-most or right-most allocation
methodology,
future scalability concerns, etc.
No bits lost, yes?

/TJ

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Oct 2008 16:23:09 +0200

For what it's worth,

Whenever statelessly auto-configuring an IPv6 address on Ethernet the 
10th and 11th bytes are always 'fffe', hardcoded.  These are lost bits.

Alex

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 01 Oct 2008 16:36:57 +0200

> 10th and 11th bytes are always 'fffe', hardcoded.  These are lost bits.

The world has more devices than Ethernet. The Ethernet MAC -> EUI-64
trick (thus your lost fffe bits) is just a trick. Take firewire for
example which uses full EUI-64.

Greets,
 Jeroen

---

From: "TJ" <[email-masked]>
Date: Wed, 1 Oct 2008 10:39:14 -0400

Sorry if I misunderstood, I certainly wasn't trying to put words in your
mouth (or, perhaps, letters on your screen?)
It seemed like you were saying (or atleast implying) some sort of drastic
loss of addressing flexibility due to the desire to break things up on
nibble boundaries.  My bad?

Certainly, at the purely conceptual level - More bits = more flexibility.

However, I don't believe the right answer is to step into the
longer-than-64-bits side of the equation.
(Specifically - I believe we are about a decade too far into this game to
recommend crossing that boundary, and I am pretty sure this has been
discussed repeatedly during the last 15 years)

I hope that clarifies my position (and it is just that - me, speaking for
myself :) ).
/TJ

>From: Dunn, Jeffrey H. [mailto:[email-masked]]
>Sent: Wednesday, October 01, 2008 10:08 AM
>To: TJ; [email-masked]
>Cc: Dunn, Jeffrey H.; [email-masked]
were
>"lost," just that longer prefixes make logical address partitioning easier
>and more flexible.  Am I wrong?
>
>Best Regards,
>
>Jeffrey Dunn
>Info Systems Eng., Lead
>MITRE Corporation.
>(301) 448-6965 (mobile)
>
>
>From: [email-masked] [mailto:[email-masked]] On Behalf Of TJ

---

From: Tim Chown <[email-masked]>
Date: Wed, 1 Oct 2008 15:47:40 +0100

> example which uses full EUI-64.

Well, Vista uses 'random' host addresses, 64-bit ones.   If the spec
had been different way back when, these could equally have been 32 or
48 bits instead.   But it wasn't.

-- 
Tim

---

From: "TJ" <[email-masked]>
Date: Wed, 1 Oct 2008 10:41:43 -0400

Exactly - (IMHO) reserving bits to ensure more widespread compatibility,
future scalability, etc. is not a loss ... in fact, I am glad we have the
bits to (cough) lose in order to accomplish those goals!

/TJ

>Jeroen Massar
>Sent: Wednesday, October 01, 2008 10:37 AM
>To: Alexandru Petrescu
>Cc: [email-masked]; [email-masked]
>Subject: Re: the IPv6 Ethernet lost bits - fffe
>
>The world has more devices than Ethernet. The Ethernet MAC -> EUI-64 trick
>(thus your lost fffe bits) is just a trick. Take firewire for example which
>uses full EUI-64.
>
>Greets,
> Jeroen

---

From: "TJ" <[email-masked]>
Date: Wed, 1 Oct 2008 11:00:15 -0400

>48 bits instead.   But it wasn't.

That is just one of the several-to-many examples of things that have assume
a 64b IID space.
That is exactly what I mean when I say (IMHO) we are past the point of
feasibly changing this boundary.  
(Not saying we couldn't do it, just that (IMHO) the concerns/problems
outweigh the benefits)

/TJ

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 01 Oct 2008 17:03:11 +0200

Tim Chown wrote:
> Well, Vista uses 'random' host addresses, 64-bit ones.

Any stack can use that (actually Linux, XP, Vista, KAME all have it).
That is just RFC3041 and those are FULL EUI-64 addresses.

> If the spec

The specs just talk about EUI-64. Ethernet is just one thing that can be
converted to a full EUI-64 address.

Greets,
 Jeroen

---

From: "Azinger, Marla" <[email-masked]>
Date: Wed, 1 Oct 2008 11:09:27 -0400

While some folks will lead us to believe our ability to use up address space is going to decline, and thus IPv6 appears to be an infinite number to them, there are those that prefer to simply acknowledge that IPv6 has yet again, a finite number.

It doesn't hurt to be moderate (not stingy) but it could hurt to be overly generous when utilizing addresses.  If we can plan our subnet use with accurate technical aspects and assign according to what is a likely need and room for growth then there shouldn't be any issues with waste or shorting a user.

IETF needs to focus on the technical aspect of subnets and write documents that are clear for RIR's to reference.  Then RIR's can do their part and write policy that details what is a realistic need and room for growth of a user.

Cheers
Marla Azinger
Frontier Communications
ARIN AC

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dunn, Jeffrey H.
Sent: Wednesday, October 01, 2008 6:05 AM
To: Alexandru Petrescu; [email-masked]
Cc: Sherman, Kurt T.; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Martin, Cynthia E.
Subject: RE: what problem is solved by proscribing non-64 bit prefixes?

More to the point, what would a individual household do with Avogadro's number worth of IPv6 addresses (2^80 = 1.2x10^24)?  This seems extremely wasteful.  Further, a reasonable sized ISP with a couple of million customers would require a /28 or more just for their residential customer base.  This sounds like a prescription for address exhaustion.

Best Regards,

Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]]
Sent: Wednesday, October 01, 2008 8:55 AM
To: [email-masked]
Cc: Dunn, Jeffrey H.; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Sherman, Kurt T.; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Martin, Cynthia E.
Subject: Re: what problem is solved by proscribing non-64 bit prefixes?

That's typical for me but I don't know about the other deployed IPv6 ADSL, do they give /64 or shorter prefixes?

Alex

For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

---

From: "Azinger, Marla" <[email-masked]>
Date: Wed, 1 Oct 2008 10:51:58 -0400

Again, Im not sure why any focus is being put on RIR policy.  And at least within the ARIN RIR what subnet boundary delineates what has to be registered tends to be a moving target (this is not something we should be referencing).  And as far as registering subnet use, I'm not sure where it becomes a headache since most of it is 80% automated for those that do IP Address administration.  But yet, all this seems pointless to discuss since it really isn't anything technical that IETF documents need to contain.

What I do find interesting from a technical point of view and what I hope doesn't get lost in the mass of emails is this one aspect that Brian brought up and Jeffrey attempted to clarify:

"I think what Brian was trying to point up is that mapping the IPv6 sub-netting scheme to an existing IPv4 sub-netting scheme would be easier of the number of low order bits below the prefix in an address is the same.  For example, a IPv4 /24 with 8 low order bits below the prefix might be mapped to a /120 IPv6 address.  Clearly, this could be abstracted to a scheme using 2 or 4 x (32 - IPv4 prefix length) low order bits in the IPv6 address, i.e., assign a /n, where n = 128 - 2 or 4 x (32 - IPv4 prefix length)."

Cheers
Marla Azinger
Frontier Communications
ARIN AC

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dunn, Jeffrey H.
Sent: Tuesday, September 30, 2008 9:38 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Sherman, Kurt T.; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Martin, Cynthia E.
Subject: RE: what problem is solved by proscribing non-64 bit prefixes?

Mike,

Actually, you cannot just assign a /48 to each site.  The RIR H-ratio requirements may make this infeasible.  Further, each /48 (/56 for
IANA) allocations must be registered with the RIR, which is an administrate headache.  Finally, there is the issue of reverse lookup registration for sites.  These are just the policy issues.

I think what Brian was trying to point up is that mapping the IPv6 sub-netting scheme to an existing IPv4 sub-netting scheme would be easier of the number of low order bits below the prefix in an address is the same.  For example, a IPv4 /24 with 8 low order bits below the prefix might be mapped to a /120 IPv6 address.  Clearly, this could be abstracted to a scheme using 2 or 4 x (32 - IPv4 prefix length) low order bits in the IPv6 address, i.e., assign a /n, where n = 128 - 2 or
4 x (32 - IPv4 prefix length).

Best Regards,

Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, September 30, 2008 12:25 PM
To: [email-masked]; Dunn, Jeffrey H.
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Sherman, Kurt T.; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Martin, Cynthia E.
Subject: RE: what problem is solved by proscribing non-64 bit prefixes?

> VLSM arrangement itself in IPv4-land.

Given that in IPv6, you can justify allocating a /48 to each separate site, which gives you 16 bits to mirror the IPv4 subnet hierarchy, while maintaining 64 bit interface sddresses, I don't see a technical issue here.

And I would really recommend that you upgrade all of your management systems to fully support IPv6 instead of relying on tricks like generating an IPv6 address by applying a transform to an existing
IPv4 address. Then you have no technical issue at all.

--Michael Dillon

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Wed, 1 Oct 2008 08:59:34 -0400

Colleagues,

I am glad to see that my initial humble e-mail has sparked such debate.
Based on discussions with some of my colleagues, I feel the need to
make a few addition points concerning extended addressing.  Although I
see no engineering reason why SLAAC will not work with non-64 bit
prefixes, it most assuredly will fail if prefixes span links (using the
RFC 2460 definition of link).  This fact leads to some rather
interesting conclusions:

1. It seems rather wasteful to assign 2^64 addresses to each link.
This assignment corresponds to. 1.8x10^19 individual end systems.  Even
if this number of systems could be attached to a link, each speaker
would only be able to transmit an octet every 4679 YEARS to the router
on a gigabit link.  I see no possible application for such an
arrangement.

2.  Since each VLAN is a link, i.e., a separate Ethernet broadcast
domain, each VLAN on a physical interface must have its own prefix.  As
a result, to support the use of all possible VLAN identifiers (2^12
possibilities) each router interface with a VLAN module must be
assigned at least a /52.  For routers with multiple VLAN modules, 16
for example, this corresponds to the individual router requiring a /48.
Although this is a worst case scenario, it illustrates the possibility
of an enormous waste of address space.

As a result of these observations, I am turning the question around:
Why would anyone want to use a 64 bit interface identifier?

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Dickson
Sent: Tuesday, September 30, 2008 5:18 PM
To: Brian E Carpenter
Cc: Alexandru Petrescu; IETF IPv6 Mailing List; Pekka Savola; Ron
Bonica; [email-masked]; Pasi Eronen; Sherman, Kurt T.;
[email-masked]; [email-masked];
[email-masked]; [email-masked]; V6ops Chairs; Martin, Cynthia E.
Subject: Re: what problem is solved by proscribing non-64 bit prefixes?

Brian E Carpenter wrote:
> On 2008-10-01 08:26, Brian Dickson wrote:
> ...
>   
>> we would ideally also have corresponding IPv6 subnets that are
>> algorithmically derived from the IPv4 subnets.
>>     
>
> I used to think that was a good way to design an initial
> IPv6 addressing plan. But from helping people design a real
> addressing plan for a real campus with many years of IPv4
> history, I've reached the conclusion that it's a really bad idea.
> It's much better to design a clean IPv6 plan from the ground up,
> rather than sweeping up the messy history of the IPv4 plan.
>
>   

I think the thing to be careful of, is jumping from "this is a better
way of doing things",
to "everyone has to do it this way".

Similarly, there is both a qualitative and quantitative difference
between anecdotal things,
and statistical things.

For instance, what works for one campus will likely work for most
campuses (campii?).

However, educational institutions number in the thousands, roughly,
while SMBs and ISPs
number in the 100s of thousands or more.

And many of those non-campus entities, are unable to (easily) go that
route.

> If you design a clean IPv6 plan that way, there doesn't seem to be
> any incentive whatever to use anything other than /64 as
> subnet prefixes (except for the router-router links, as Pekka
> mentioned). There's a strong incentive in favour of /64,
> i.e. the ability to use SLAAC, privacy addresses, and CGAs.
>   

I agree. However...

Saying "I agree" doesn't mean that the original argument, (of managing
dual-stack networks
of servers which do not need, cannot use, and will never want, SLAAC,
privacy addresses,
DHCPv6, or anything other than static configurations, possibly
centrally
managed), isn't valid.

Or, basically, the counter-argument is, if you don't do a clean design,
then you probably do
need non-64 bit subnets, period.

BTW - I am not advocating not doing a clean design. I'm saying that
while dual-stack is prevalent,
the benefits of managing the duality with crude but effective
implements, outweighs the
elegance of any alternative.

Being able to deploy something (IPv6) should be the central focus, not
making the thing being
deployed more "clean".

If the choice is fugly or not at all, the fugly choice must still
prevail.

Which means we need to accommodate schemes we don't like, don't
advocate, but which are
a means to the desired end (IPv6 deployment, especially in a dual-stack
world.)

Brian Dickson

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Oct 2008 15:11:07 +0200

Dunn, Jeffrey H. wrote:
[...]
> Why would anyone want to use a 64 bit interface identifier?

I speculate that one possible reason for this was to design a SLAAC over 
Ethernet that is reliable, simple, universal and straightforward to 
implement.

In a way, I see SLAAC to have become so popular as opposed to DHCP. 
Were DHCPv6 more developed we wouldn't have this IID-64bit problem, I think.

Alex

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Wed, 1 Oct 2008 09:31:40 -0400

Alex,

While I agree that the use of an EUI-64 network identifier predicates a
64-bit prefix, I am not convinced that an EUI-64 is the best way to go.
After all, the Ethernet MAC address is only 48 bits, so we are
essentially "throwing away" 16 bits (assuming that the identifier is
globally unique).  Further, we require the use of DAD, so why not just
use a 32 bit pseudo random number generated by the device and let DAD
take care of the possibility of address duplication?

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Wednesday, October 01, 2008 9:11 AM
To: Dunn, Jeffrey H.
Cc: Brian Dickson; Brian E Carpenter; Alexandru Petrescu; IETF IPv6
Mailing List; Pekka Savola; Ron Bonica; [email-masked];
Pasi Eronen; Sherman, Kurt T.; [email-masked];
[email-masked]; [email-masked]; [email-masked]; V6ops Chairs;
Martin, Cynthia E.
Subject: Re: Why would anyone want to use a 64 bit interface
identifier? (was: what problem is solved by proscribing non-64 bit
prefixes?)

Dunn, Jeffrey H. wrote:
[...]
> Why would anyone want to use a 64 bit interface identifier?

I speculate that one possible reason for this was to design a SLAAC
over 
Ethernet that is reliable, simple, universal and straightforward to 
implement.

In a way, I see SLAAC to have become so popular as opposed to DHCP. 
Were DHCPv6 more developed we wouldn't have this IID-64bit problem, I
think.

Alex

---

From: "TJ" <[email-masked]>
Date: Wed, 1 Oct 2008 11:28:41 -0400

Couple of additional comments while the v4v6coexistence meeting is on break
:) ... 

>It doesn't hurt to be moderate (not stingy) but it could hurt to be overly
>generous when utilizing addresses.  If we can plan our subnet use with
>accurate technical aspects and assign according to what is a likely need
and
>room for growth then there shouldn't be any issues with waste or shorting a
>user.

I agree that moderation is not a bad thing, as long as we also provide for
future capabilities rather than stifling/restricting them.  That is why I
fully support the /56 "small-office / home-office" sized allocation.

>number worth of IPv6 addresses (2^80 = 1.2x10^24)?  This seems extremely
>wasteful.  

Using that logic, how many enterprises need 2^80 hosts either?  
	In fact, how many galaxies need that many hosts??

Not to be overly blunt, but from the IETF's consensus this is not quite the
right way to think about it ...
	The 64b IID space is not meant to encourage 2^64 hosts per segment.
(Good luck trying, though!)
	It is meant to serve as a relatively consistent boundary between the
network (prefix) and host (IID) parts of the address.
	So, a /48 is really 2^16 network segments, each supporting the
"appropriate" number of hosts.
		64k networks may be a bit much for the average home as well,
hence the /56s.
		256 may be a bit much FOR NOW, but the goal is to provide
for future flexibility & capability.

(BTW - This is why I don't like presenting IPv6 as a great big flat 128b
space ... rather, as 2^64 networks (give or take, admittedly some loss there
for reserved ranges, multicast, etc.) ... each of which can support the
right number of hosts for that given deployment. )

/TJ

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Wed, 1 Oct 2008 11:34:28 -0400

Tim,

That sounds more like a call to update the spec than to ignore the
additional functionality available with variable length prefixes.

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tim Chown
Sent: Wednesday, October 01, 2008 10:48 AM
To: [email-masked]
Subject: Re: the IPv6 Ethernet lost bits - fffe

-- 
Tim

---

From: "TJ" <[email-masked]>
Date: Wed, 1 Oct 2008 11:51:04 -0400

>Ethernet that is reliable, simple, universal and straightforward to

BINGO.  And those are all (IMHO) Good Things.

think.

We could debate how "popular" SLAAC is (many of those arguments, both pro
and con, are environment / deployment specific), but more relevant - some
DHCP implementations also assume a 64b IID.  Which aspect is the cart and
which is the horse could also be debated, but the real point is - again -
that this assumption has been baked-in to so many things that changing it is
(yes, still IMHO) a Bad Thing.

/TJ

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Oct 2008 18:08:58 +0200

TJ wrote:
>> over Ethernet that is reliable, simple, universal and
>> straightforward to implement.
> 

Well yes, they're Good Things.

> We could debate how "popular" SLAAC is (many of those arguments, both
> pro and con, are environment / deployment specific), but more
> relevant - some DHCP implementations also assume a 64b IID.

I think I agree.

> Which aspect is the cart and which is the horse could also be
> debated, but the real point is - again - that this assumption has
> been baked-in to so many things that changing it is (yes, still IMHO)
> a Bad Thing.

Well of course, one wouldn't dare suggest changing such deeply 
entrenched std and implementation, bar the deployed base.

However, one can't stop oneself express the strong frustration felt 
about extending an IPv6 network.  With all the great SLAAC features and
software availability - yet it's hard to extend a common IPv6 subnet: 
one needs DHCPv6 prefix delegation be in place, or one needs to be 
allocated a shorter than /64 prefix (e.g. be allocated a /56).  These
are rare.

Thanks for the message, I'll go in listening mode :-)

Alex

---

From: "TJ" <[email-masked]>
Date: Wed, 1 Oct 2008 12:37:38 -0400

Funny, I interpreted Tim's statement to be another example of "Something
that will break if we change this" ... :)

This discussion goes back aways ...
	January 1995 --> http://tools.ietf.org/html/rfc1752#section-9
	August 2002 --> http://osdir.com/ml/ietf.ipv6/2002-08/msg00190.html
(great comments therein!)
	July 2008 -->
http://tools.ietf.org/html/draft-ietf-6man-reserved-iids-01  (things you may
step on beyond 64b)

We could also have a discussion on the inherit value in fixed length things
... like the IPv6 header itself (vs IPv4's variable length header) ... 

My question would be - 
	Are we seeking to understand why a fixed 64b boundary was created in
the first place?
		... or ...
	Are we trying to modify the standard to change this?
		(And if so - are we ready to actually face the world with
that statement, and to "operationalize" this?)

(Obviously, my opinion on this matter (some might say bias) is clear ... but
for what I believe are good, technical reasons :) )
/TJ

>Dunn, Jeffrey H.
>Sent: Wednesday, October 01, 2008 11:34 AM
>To: Tim Chown; [email-masked]
>Cc: [email-masked]
>Subject: RE: the IPv6 Ethernet lost bits - fffe
>
>Tim,
>
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim
>Chown

---

From: "TJ" <[email-masked]>
Date: Wed, 1 Oct 2008 12:42:09 -0400

My pleasure, and thanks for taking part - this is supposed to be an active
community, gathering consensus, etc.  The more the merrier!

> Well of course, one wouldn't dare suggest changing such deeply entrenched
std and implementation, bar the deployed base.

I think some are doing just that, and while I welcome the conversation I
really hope we (collectively) do not go down that path.

> "yet it's hard to extend a common IPv6 subnet"

I'm sorry, extend in what fashion?  You mean in order to have 2 (or, "n")
subnets? ... see next comment:

> "or one needs to be allocated a shorter than /64 prefix (e.g. be allocated
a /56).  These are rare"

They are?  
I must have missed that memo!  (Sorry, don't mean to be overly flippant)
Seriously, last time I checked I could get up to a /48 (or, atleast a /56)
fairly readily ... that is the whole point, and if someone is making that
difficult for you that is a different conversation!

/TJ

>Sent: Wednesday, October 01, 2008 12:09 PM
>To: TJ
>Cc: 'IETF IPv6 Mailing List'
>Subject: Re: Why would anyone want to use a 64 bit interface identifier?
>
>TJ wrote:
>>> over Ethernet that is reliable, simple, universal and straightforward
>>> to implement.
>>
>> pro and con, are environment / deployment specific), but more relevant
>> - some DHCP implementations also assume a 64b IID.
>
>I think I agree.
>
>> Which aspect is the cart and which is the horse could also be debated,
>> but the real point is - again - that this assumption has been baked-in
>> to so many things that changing it is (yes, still IMHO) a Bad Thing.
>
>Well of course, one wouldn't dare suggest changing such deeply entrenched
>std and implementation, bar the deployed base.
>
>However, one can't stop oneself express the strong frustration felt about
>extending an IPv6 network.  With all the great SLAAC features and software
>availability - yet it's hard to extend a common IPv6 subnet:
allocated
>a shorter than /64 prefix (e.g. be allocated a /56).  These are rare.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Oct 2008 18:44:12 +0200

> 	Are we trying to modify the standard to change this?

WEll I think there's a draft that led to this discussion but I don't 
think that draft tries to achieve this 64bit boundary extension.  I'm 
not sure what's the position of the draft with respect to this discussion.

> that statement, and to "operationalize" this?)

I'm more like wait and see what happens and if it goes the direction I 
like I'm ready to jump on it.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Oct 2008 18:57:00 +0200

TJ wrote:
> I'm sorry, extend in what fashion?  You mean in order to have 2 (or, 
> "n") subnets?

Yes, that, it's hard to add a new unplanned-for-initially Ethernet 
subnet to an existing subnet which is allocated a /64 prefix.

>> "or one needs to be allocated a shorter than /64 prefix (e.g. be 
>> allocated a /56).  These are rare"
> 
> They are? I must have missed that memo!  (Sorry, don't mean to be 
> overly flippant) Seriously, last time I checked I could get up to a 
> /48 (or, atleast a /56) fairly readily ... that is the whole point, 
> and if someone is making that difficult for you that is a different 
> conversation!

Well yes, I suppose if one asks an allocating organization for a /48
prefix then one may obtain it easily.  However, one must be sysadmin to 
know one can obtain that.  A more mere mortal doesn't even know such 
organizations exist, and uses whatever is available at hand.  There are 
more mere mortals than sysadmins, hence that is rare.

If I arrive to a /64 wifi hotspot in a hotel room I can't extend it with 
another subnet, on which to plug my other IPv6 wifi devices.

Also, if I plan my (fictitious) lab network with core routers and such
and prepare for 15 edge /64bit networks, I won't be able to extend them
in a few years with more edge networks without manually changing the
addressing in the core routers.

If I want to build a WiFi router (not bridge), which plugs itself into
an IPv6 wired network, autoconfigures itself, and delivers IPv6 on the
wifi part - it's hardly possible, because the IPv6 wired network on
which I plug this AP is hardly extensible.

People have already deployed many /64 Ethernet networks - they're all
hard to extend.

This is lack of extensibility, itches me,

Alex

> 
> 
> /TJ
> 
> 
>> -----Original Message----- From: Alexandru Petrescu 
>> [mailto:[email-masked]] Sent: Wednesday, October 01, 
>> 2008 12:09 PM To: TJ Cc: 'IETF IPv6 Mailing List' Subject: Re: Why 
>> would anyone want to use a 64 bit interface identifier?
>> 
>> TJ wrote:
>>>> I speculate that one possible reason for this was to design a 
>>>> SLAAC over Ethernet that is reliable, simple, universal and 
>>>> In a way, I see SLAAC to have become so popular as opposed to 
>>>> DHCP. Were DHCPv6 more developed we wouldn't have this 
>>>> IID-64bit problem, I
>>> think.
>>> 
>>> We could debate how "popular" SLAAC is (many of those arguments, 
>>> both pro and con, are environment / deployment specific), but 
>>> more relevant - some DHCP implementations also assume a 64b IID.
>> I think I agree.
>> 
>>>  been baked-in to so many things that changing it is (yes, still 
>>> IMHO) a Bad Thing.
>>  about extending an IPv6 network.  With all the great SLAAC
>> features and software availability - yet it's hard to extend a
>> common IPv6 subnet: one needs DHCPv6 prefix delegation be in place,
>> or one needs to be
> allocated
>>  This email has been scanned by the MessageLabs Email Security 
>> System. For more information please visit 
>> http://www.messagelabs.com/email 
>  IETF IPv6 working group mailing list [email-masked] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "TJ" <[email-masked]>
Date: Wed, 1 Oct 2008 13:11:48 -0400

Is there an analogy to IPv4?

The closest fit for those scenarios, off the top of my head, is to add a
layer of NAT.  If you were willing to accept the added layer of NAT for
IPv4, is there a reason you wouldn't accept an IPv6 "proxy + ULA's behind
it" deployment?  Failing that, I suppose you could do transparent bridging,
but that should almost never be the first answer :).  A more advanced option
would be DHCPv6-PD, but the level of support for that is not quite 100% yet.

One of the design goals with IPv6 is to actually give you more address space
than you currently know you need, specifically to avoid these problems ...
and if done right it could literally be as simple as your upstream (be it a
provider, or a layer higher in your org, etc.) making the route pointing at
you a /63 instead of a /64 (or /55 instead of /56, etc.) ... aggregation /
summarizability is a Good Thing also :).

>From the SysAdmin perspective, the network people allocating your space
would, ideally, have a sequential additional block they could hand you and
you'd be all set.  If they failed to (atleast attempt to) maintain that sort
of flexibility, slap them on the wrist and take a non-sequential block ...

It's actually a bit ironic, one of IPv6's strengths is it's extensibility
:).
/TJ

>Sent: Wednesday, October 01, 2008 12:57 PM
>To: TJ
>Yes, that, it's hard to add a new unplanned-for-initially Ethernet subnet
to
>an existing subnet which is allocated a /64 prefix.
>
>Well yes, I suppose if one asks an allocating organization for a /48 prefix
>then one may obtain it easily.  However, one must be sysadmin to know one
>can obtain that.  A more mere mortal doesn't even know such organizations
>exist, and uses whatever is available at hand.  There are more mere mortals
>than sysadmins, hence that is rare.
>
>Also, if I plan my (fictitious) lab network with core routers and such and
>prepare for 15 edge /64bit networks, I won't be able to extend them in a
few
>years with more edge networks without manually changing the addressing in
>the core routers.
>
>If I want to build a WiFi router (not bridge), which plugs itself into an
>IPv6 wired network, autoconfigures itself, and delivers IPv6 on the wifi
>part - it's hardly possible, because the IPv6 wired network on which I plug
>this AP is hardly extensible.
>
>People have already deployed many /64 Ethernet networks - they're all hard
>to extend.
>
>>>> both pro and con, are environment / deployment specific), but more
>>> about extending an IPv6 network.  With all the great SLAAC features
>>> and software availability - yet it's hard to extend a common IPv6
>>> subnet: one needs DHCPv6 prefix delegation be in place, or one needs
>>> to be
>> allocated
>>> _____________________________________________________________________
>>> _  This email has been scanned by the MessageLabs Email Security

---

From: "Chip Popoviciu (cpopovic)" <[email-masked]>
Date: Wed, 1 Oct 2008 13:16:49 -0400

Alex,

Thank you for providing this opportunity to settle the scope of the
draft which, yes, started these two big threads, the addcon draft. 

Our draft does not take a position on the requirements of RFC4291, does
not try to enforce a choice on addressing plans. The draft acknowledges
that in practice, people chose various prefix lengths so the draft
simply points out things to consider if one chooses /64, longer or
shorter than 64 bits long prefix. Pekka stated very nicely the spirit in
which we developed the addcon draft: "I use /126 on point-to-point links
but I am aware of the implications". The addcon draft does just that,
leaves it to the reader to make a choice, the draft simply points out
what things should be considered when a choice is made. This is a
practical, realistic perspective.

I hope this clarifies where the draft stands. That being said, it is
clear from the various heated threads on the prefix length or the IID
length that this topic deserves discussion and consensus. This is
independent however of the practical approach of the draft in dealing
with the current recommendations/considerations and thus helping folks
making informed choices (whether in line with RFC4291 or not)  in terms
of developing addressing plans.

Thanks again Alex!

Best regards,
Ciprian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexandru Petrescu
Sent: Wednesday, October 01, 2008 12:44 PM
To: TJ
Cc: [email-masked]
Subject: Re: the IPv6 Ethernet lost bits - fffe

TJ wrote:
> Funny, I interpreted Tim's statement to be another example of 
> "Something that will break if we change this" ... :)
> 
> 
> 	August 2002 -->
http://osdir.com/ml/ietf.ipv6/2002-08/msg00190.html
> http://tools.ietf.org/html/draft-ietf-6man-reserved-iids-01  (things 
> you may step on beyond 64b)
> 
> We could also have a discussion on the inherit value in fixed length 
> things ... like the IPv6 header itself (vs IPv4's variable length
header) ...

WEll I think there's a draft that led to this discussion but I don't
think that draft tries to achieve this 64bit boundary extension.  I'm
not sure what's the position of the draft with respect to this
discussion.

> 		(And if so - are we ready to actually face the world
with that 
> statement, and to "operationalize" this?)

Alex

> 
> 
> (Obviously, my opinion on this matter (some might say bias) is clear 
> ... but for what I believe are good, technical reasons :) ) /TJ
> 
> 
>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>> Of Tim Chown

---

From: Antonio Querubin <[email-masked]>
Date: Wed, 1 Oct 2008 09:07:44 -1000 (HST)

On Tue, 30 Sep 2008, Alexandru Petrescu wrote:

> In a typical WiFi Access Point landscape...
>
> Sellers of these devices don't have a solution to program the WiFi AP
> IPv6 in the same way they'd do it for IPv4.  For IPv4, the AP receives
> an IPv4 address on the wired Ethernet and then does NAT and subnet
> further on the wireless interface.  For IPv6, although it receives a
> huge /64 IPv6 prefix on the wire it can't offer Stateless Autoconfig on
> the  wireless interface.  This begs again for IPv6 NAT.

I'd say it begs for assigning the user a /56 or /48 routed to them on the 
/64 link.

-- 
Antonio Querubin
whois:  AQ7-ARIN

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Wed, 1 Oct 2008 15:28:59 -0400

Antonio,

So are you suggesting that we replace IPv4 NAT with IPv6 routing proxy?

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]] 
Sent: Wednesday, October 01, 2008 3:08 PM
To: Alexandru Petrescu
Cc: Dunn, Jeffrey H.; IETF IPv6 Mailing List; Ron Bonica;
[email-masked]; Pasi Eronen; Sherman, Kurt T.;
[email-masked]; [email-masked];
[email-masked]; [email-masked]; V6ops Chairs;
Martin, Cynthia E.
Subject: Re: what problem is solved by proscribing non-64 bit prefixes?

> the  wireless interface.  This begs again for IPv6 NAT.

I'd say it begs for assigning the user a /56 or /48 routed to them on
the 
/64 link.

---

From: "TJ" <[email-masked]>
Date: Wed, 1 Oct 2008 15:46:15 -0400

>Cc: Sherman, Kurt T.; IETF IPv6 Mailing List; Ron Bonica;
>[email-masked]; Pasi Eronen; Martin, Cynthia E.;
draft-ietf-
>[email-masked]; [email-masked]; [email-masked];
>[email-masked]; V6ops Chairs
>> huge /64 IPv6 prefix on the wire it can't offer Stateless Autoconfig
>> on the  wireless interface.  This begs again for IPv6 NAT.
>

Exactly right! 

A /56 to the home's DHCPv6-PD capable CPE.
(Atleast) one "inside" segment (couple of switch ports, maybe an antenna or
two) for now - sporting SLAAC, maybe Stateless DHCPv6 as well?
A healthy dose of stateful IPv6 firewalling, for those so inclined.  
Oh, and probably the same IPv4/NAT/FW we all know and love.
Winner.

/TJ

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Oct 2008 09:27:37 +1300

> ability. Under RIR rules, an ISP can justify giving you a /48

Yes. We shouldn't forget that there are, objectively, 15 trillion
/48s available, so whatever religious faith people may have
in the HD ratio, there *are* plenty of /48s. The value of the
HD ratio (and the RIR practices related to it) is to avoid
wasteful use of the bits *before* the /48 boundary.

   Brian

---

From: Brian Dickson <[email-masked]>
Date: Wed, 01 Oct 2008 16:42:10 -0400

> Oh, and probably the same IPv4/NAT/FW we all know and love.

The problem, fundamentally, is one's position in a hierarchy (of IPv6
assignments or pd's).

In many markets, there is a (very) limited pool of ISPs (let along ISPs
offering IPv6 !!).

And, consequently, the ability to ask for and receive something other
than a single /64,
is limited by the availability of ISPs in the local pool who offer it.
It doesn't much matter whether
the assignment of a /64 is dynamic or static - either way it bites.

There is no guarantee that even a *single* ISP in any particular pool of
local ISPs, has enough
clue to offer this, or the ability to offer it (regardless of reason
underlying the inability).

This isn't something I, as a customer, have *direct* control over, and I
may not have an alternative (other ISP offering what I want).

And it doesn't matter *why*.

In such a situation, I am effectively "painted into a corner" (e.g. when
viewing IPv6 space as a Heat Map / Hilbert curve).

"Bits to the left of me, Bits to the right, Here I am - Stuck in the
middle again".
(Apologies to the original artist and those who don't like puns.)

The question is, what does one do in such a scenario, and/or what *can*
one do?

If the ability to do what one wants, is permitted by non-64 bit
prefixes, life is good.
DHCPv6, or more flexible versions of SLAAC, CGA, etc., are needed for this.

If only 64-bit prefixes can be used, then one gets only one 64-bit
prefix to use for everything. Good luck with that.

Basically, in the absence of the ability to subnet arbitrarily (on
non-64 bit boundaries), I'm at the mercy of my upstream.

128 bits doesn't look so wonderful in such a scenario, I would surmise.

Nobody is a winner. :-(

Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Oct 2008 09:42:57 +1300

> residential customer base.  This sounds like a prescription for address

Not in the least. Please remember that we have raised the size of the
address space to the *fourth* power; we squared it and squared it again.
Even if we'd stuck to the original plan of assigning /48s everywhere,
that means we've *squared* the size of the subnet prefix space (/24 to /48).
Unless really stupid allocation mechanisms are allowed, that is enough
for any imaginable future. And all the evidence is that the RIRs are
being extremely conservative in their practices for allocation. So
I don't see even a remote cause for concern.

On the other hand I see enormous value in allowing any size of network
on any customer's premises. It's not for this generation of engineers
and ISPs to constrain what our great-grandchildren might invent.

    Brian

---

From: Antonio Querubin <[email-masked]>
Date: Wed, 1 Oct 2008 10:45:21 -1000 (HST)

> So are you suggesting that we replace IPv4 NAT with IPv6 routing proxy?

I'm suggesting not relying on NAT as a crutch in your specific example. 
It seems too easy to just mirror IPv4 practices onto IPv6 and not look at 
how IPv6 capabilities enable other potential solutions.  In my mind it's 
almost an impediment toward broader acceptance of IPv6.  It implies 
treating IPv6 as only just 'more bits'.  We don't really do a good job of 
'selling' IPv6, and I don't mean to the end-user who doesn't know or 
should even care, but to network admins/consultants/operators, many of 
whom have NAT firmly implanted in their default toolkit.

The unfortunate reality though is that hardware manufacturers have 
non-trivial challenges in producing plug-n-play CPEs that can still work 
in the NAT-to-everything world of IPv4 and provide the same functionality 
in a non-NATed IPv6 world.  It's hard to migrate towards a cleaner network 
when the necessary tools are still hard to come by.  Can anyone name more 
than a handful of off-the-shelf CPEs that are capable of doing native IPv6 
routing and can be daisy-chained easily for say less than $150?  How about 
less than $250?  $500?  :(

Sorry for the digression.

---

From: <[email-masked]>
Date: Wed, 01 Oct 2008 16:55:49 -0400

> wasteful use of the bits *before* the /48 boundary.

More precisely:

- 1 trillion /48s in 2000::/3 with HD = 0.889

- 5.4 trillion /48s in 2000::/3 with HD = 0.94

We can comfortably support between 4 - 21 trillion /48s using only
half of the total address space.

I don't understand why people keep worrying about this.

Regards,

// Steve

---

From: Francis Dupont <[email-masked]>
Date: Wed, 01 Oct 2008 23:50:08 +0200

In your previous mail you wrote:

=> hum, unfortunately Firewire is the bad example: it uses EUI-64 for IDs,
addresses themselves are on 16 bits.

[email-masked]

PS: it was expected to get new network technologies using 64 bit long
addresses. As far as I know there is currently none.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Wed, 1 Oct 2008 23:11:29 -0400

I second Brian's points that:

1.  DHCPv6, or more flexible versions of SLAAC, CGA, etc., are needed
2. Basically, in the absence of the ability to subnet arbitrarily (on
non-64 bit boundaries), I'm at the mercy of my upstream.

Further, I would like to summarize the reasons offered on this list for
proscribing all but 64-bit prefixes:

1. That is the way the prefix is currently defined in mu favorite RFC
2. We have always done it that way
3. The decision was made 12 years ago and the explanation is in a book

None of these appear to be a compelling ENGINEERING reason to require
64-bit prefixes be the only acceptable option.

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Dickson
Sent: Wednesday, October 01, 2008 4:42 PM
To: TJ
Cc: 'IETF IPv6 Mailing List'
Subject: Re: what problem is solved by proscribing non-64 bit prefixes?

There is no guarantee that even a *single* ISP in any particular pool
of
local ISPs, has enough
clue to offer this, or the ability to offer it (regardless of reason
underlying the inability).

This isn't something I, as a customer, have *direct* control over, and
I
may not have an alternative (other ISP offering what I want).

In such a situation, I am effectively "painted into a corner" (e.g.
when
viewing IPv6 space as a Heat Map / Hilbert curve).

If the ability to do what one wants, is permitted by non-64 bit
prefixes, life is good.
DHCPv6, or more flexible versions of SLAAC, CGA, etc., are needed for
this.

Nobody is a winner. :-(

Brian

---

From: "Christopher Morrow" <[email-masked]>
Date: Thu, 2 Oct 2008 00:25:27 -0400

> non-64 bit boundaries), I'm at the mercy of my upstream.

3rd.

> 64-bit prefixes be the only acceptable option.

I believe part of the reason was that cidr was 'hard' and the
percieved burden on operations folks to do subnetting not on bit
boundaries drove the current /32, /48, /64 decisions. I think most
operations folks have a grasp of the basics, we can really just move
along and let people do what they will with their networks, eh?

As to the dhcp or auto-conf discussion, there are situations where
autoconf is not sufficient, dhcp is part of operations today, it's
going to continue to be going forward. Disappearing dhcpv6 is really
not going to help uptake in enterprise situations, forcing folks to
manage 2 completely disparate methods of addressing on their deployed
systems is only going to keep people from deploying the 'new' and
'adds pain' way.

-Chris

---

From: Mark Andrews <[email-masked]>
Date: Thu, 02 Oct 2008 17:33:32 +1000

> more mere mortals than sysadmins, hence that is rare.

	CPE equipement will just make PD requests upstream and
	will accept PD requests from down stream.

	You plug you router in and it just requests a /64 prefix.
	If something downstream requests a /64 prefix you it would
	then request an additional /64 prefix.  The router would
	just remember which prefixes were handed out and route traffic
	accordingly.

	A ISP for example would hand out up to 256 prefixes this way
	if their policy was for /56.

	A hotel would have /48 to hand out prefixes to customers from.
	If they have more than 65k rooms they request a bigger prefix.

	If you do it correctly the same router will get the same prefix
	repeatedly as the prefix ids in the PD requests won't change.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 01 Oct 2008 17:35:53 +0200

> take care of the possibility of address duplication?

Because in EUI-64 there should not be any clashes. (you know, like MAC
addresses they never run out ;)

What you also seem to be forgetting is this thing called
'statelessness'. And that you might want to IPv6-enable your carpet.

Also, at 2 DAD clashes most stacks stop trying and give up, tada your
whole carpet is now inaccessible...

(Might I nastily suggest that people start reading up on the history on
certain choices in the IPv6 architecture? Christian Huitema's IPv6* book
is really interesting and so is IPng* by Bradner and Mankin for even
older history).

Greets,
 Jeroen

* = http://www.amazon.com/IPv6-New-Internet-Protocol-2nd/dp/0138505055
http://www.amazon.com/IPNG-Internet-Protocol-Next-Generation/dp/B000OOKP2A
(just picking Amazon as it was the first hit in google, nothing else...)

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Wed, 1 Oct 2008 23:04:07 -0400

Brian,

Your point about raising the size of the address space to the fourth
power is not quite correct.  If we constrain the network prefix to be
64-bits, then, assuming that the longest routable IPv4 prefix is 24, we
have only raised the prefix size by the power 2.67.  Now assume that
we start handing out /28 prefixes to ISPs for their residential
customers (who are now all behind a NAT), we have now only raised the
number of subnets to the 1.17. My argument is that it is not the number
of unique end system addresses that is the issue, rather the number of
subnets.

As to your observation concerning this generation's engineers, I whole
heartedly second your suggestion.

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Wednesday, October 01, 2008 4:43 PM
To: Dunn, Jeffrey H.
Cc: Alexandru Petrescu; [email-masked]; Sherman, Kurt T.;
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; Martin, Cynthia E.
Subject: Re: what problem is solved by proscribing non-64 bit prefixes?

Not in the least. Please remember that we have raised the size of the
address space to the *fourth* power; we squared it and squared it
again.
Even if we'd stuck to the original plan of assigning /48s everywhere,
that means we've *squared* the size of the subnet prefix space (/24 to
/48).
Unless really stupid allocation mechanisms are allowed, that is enough
for any imaginable future. And all the evidence is that the RIRs are
being extremely conservative in their practices for allocation. So
I don't see even a remote cause for concern.

    Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 2 Oct 2008 10:47:42 +0300 (EEST)

> on a gigabit link.  I see no possible application for such an

The point is not to able able to put 2^64 hosts on a link, it's being 
able to put *enough* nodes on the link, with *near-zero* address 
collision probability, so that you'll never need to renumber the link 
to have more address space if the address space was not sufficient 
after the number of connected hosts grow.  An added bonus is an 
ability to design new protocols and mechanisms that are able to 
leverage those bits in the address with reasonable expectation of said 
technology being usable in the wild.

> of an enormous waste of address space.

You're not reserving a block of 2^12 IPv4 prefixes (or addresses in 
degenerate case) for each VLAN-capable router interface today, so I 
fail to see how this argument would apply to IPv6.

---

From: "TJ" <[email-masked]>
Date: Thu, 2 Oct 2008 08:24:20 -0400

Funny, "On the other hand I see enormous value in allowing any size of network on any customer's premises. It's not for this generation of engineers and ISPs to constrain what our great-grandchildren might invent" is something I see as an argument for sticking with /64s.  You never know what may be developed that needs all those host bits (or, atleast - needs more than we expect ... think things like per-sessions IP addresses and such 'craziness' :)  )

Thanks!
/TJ

>Sent: Wednesday, October 01, 2008 11:04 PM
>To: Brian E Carpenter
>[email-masked]; [email-masked]; Sherman, Kurt T.; draft-ietf-
>[email-masked]; [email-masked]; [email-masked];
>[email-masked]; [email-masked]; Martin, Cynthia E.
>Your point about raising the size of the address space to the fourth power
>is not quite correct.  If we constrain the network prefix to be 64-bits,
>then, assuming that the longest routable IPv4 prefix is 24, we have only
>raised the prefix size by the power 2.67.  Now assume that we start handing
>out /28 prefixes to ISPs for their residential customers (who are now all
>behind a NAT), we have now only raised the number of subnets to the 1.17. My
>argument is that it is not the number of unique end system addresses that is
>the issue, rather the number of subnets.
>
>[email-masked]; [email-masked]; [email-masked]; v6ops-
>[email-masked]; Martin, Cynthia E.
>Even if we'd stuck to the original plan of assigning /48s everywhere, that
>means we've *squared* the size of the subnet prefix space (/24 to /48).
>Unless really stupid allocation mechanisms are allowed, that is enough for
>any imaginable future. And all the evidence is that the RIRs are being
>extremely conservative in their practices for allocation. So I don't see
>even a remote cause for concern.
>
>On the other hand I see enormous value in allowing any size of network on
>any customer's premises. It's not for this generation of engineers and ISPs
>to constrain what our great-grandchildren might invent.
>
>    Brian

---

From: "TJ" <[email-masked]>
Date: Thu, 2 Oct 2008 08:37:32 -0400

I also tend to not favor "that's the way we have always done it" type of
arguments.

In this case, however, I just see it in an operational and pragmatic
perspective - 
1) I fail to see the need for more subnet bits, based on current deployment
plans calling for /48s or /56s per client
2) I certainly see an operational pain point for all current vendors,
providers and environments that currently support/provide/use IPv6
3) Nothing stops you from breaking the RFC and doing arbitrary bit length
subnets now, as long as you are willing to endure the pain involved

Additionally, if longer prefixes are normalized, what would prevent
providers from adjusting their allocations accordingly and the end-users
gaining nothing?
(i.e. - instead of assigning /56s to support /64s, they would simply assign
/108s to support /112s or somesuch.)
((or, at the very least, they could switch from assigning /56s to /64s and
thus -requiring- (versus "enabling") you to do this type of subnetting))

/TJ

>Sent: Wednesday, October 01, 2008 11:11 PM
>To: Brian Dickson; TJ
>Cc: IETF IPv6 Mailing List; Dunn, Jeffrey H.;
>[email-masked]; Martin, Cynthia E.
>1.  DHCPv6, or more flexible versions of SLAAC, CGA, etc., are needed 2.
>1. That is the way the prefix is currently defined in mu favorite RFC 2. We
>have always done it that way 3. The decision was made 12 years ago and the
>explanation is in a book
>
64-bit
>prefixes be the only acceptable option.
>
>Best Regards,
>
>Jeffrey Dunn
>Info Systems Eng., Lead
>MITRE Corporation.
>(301) 448-6965 (mobile)
>
>
>And, consequently, the ability to ask for and receive something other than
a
>single /64, is limited by the availability of ISPs in the local pool who
>offer it.
>local ISPs, has enough clue to offer this, or the ability to offer it
>(regardless of reason underlying the inability).
>
may
>not have an alternative (other ISP offering what I want).
>
>"Bits to the left of me, Bits to the right, Here I am - Stuck in the middle
>again".
>The question is, what does one do in such a scenario, and/or what *can* one
>do?
>
>If the ability to do what one wants, is permitted by non-64 bit prefixes,
>life is good.
>If only 64-bit prefixes can be used, then one gets only one 64-bit prefix
to
>use for everything. Good luck with that.
>

---

From: "TJ" <[email-masked]>
Date: Thu, 2 Oct 2008 09:28:50 -0400

>From: Brian Dickson [mailto:[email-masked]]

Agreed, but that is not what we are talking about :).

a
may
>And it doesn't matter *why*.

I guess I just fail to see why 
	1) the provider isn't giving you more ... they *really* should ...
try to get them clued in
     	2) something like "Proxy w/ ULAs behind it" fails this scenario.  
		... it is almost directly analogous to the current IPv4+NAT
situation that you would in.

Failing those, you are free to break the /64 boundary if you really must -
routers will still route, etc.
	... you are just signing up for pain - manual configuration, etc.
 		... "sub-optimal", to say the least.

>The question is, what does one do in such a scenario, and/or what *can* one

See above :).

>DHCPv6, or more flexible versions of SLAAC, CGA, etc., are needed for this.

For some values of "good", perhaps.

to

---

From: "TJ" <[email-masked]>
Date: Thu, 2 Oct 2008 09:57:45 -0400

Stray thought - would it help alleviate this situation if the RIRs published
the allocation policies recommending the /56 as the general rule?

I would much rather support that movement (even though it would be a more
disparate effort, 5 RIRs to work with/through) than breaking the 64b
boundary as some here seem to desire (a desire codified in
http://tools.ietf.org/html/draft-dickson-v6man-new-autoconf-00, for those
interested).

For example, for those of us in the ARIN region:
"Simply" modify 6.5.4.1 from the NRPM (http://www.arin.net/policy/nrpm.html)
... :
    * /64 when it is known that one and only one subnet is needed
    * /56 for small sites, those expected to need only a few subnets over
the next 5 years.
    * /48 for larger sites
To place a preference on the /56s, or to de-pref the /64s ... or something?

/TJ

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Thu, 2 Oct 2008 12:00:22 -0400

TJ,

I understand that you do not see the need to a prefix longer than 64
bits; however, my customer has an application for extended address.  As
a result, there is an engineering need.

I am not sure that I see any pain for current providers or
environments.  Those who are deploying 64 bit prefixes and want to
stick with them are free to do so.  As to vendor pain, going down the
road of minimizing vendor pain leads us back to every vendor selling a
proprietary networking protocol.

As to breaking the RFC, although no one can stop me, it increases my
pain, which I have an incentive to avoid.

 With regards to ISPs handing out smaller prefixes, I believe that
should remain between the ISP and customer.  Personally, I could care
less if my ISP handed me a /112.  That still leaves 16 bits or 65535
end systems, which is more than enough for my home.  Businesses needing
more space would negotiate a larger allocation and, like IPv4
addresses, probably have to pay for it.

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
TJ
Sent: Thursday, October 02, 2008 8:38 AM
To: [email-masked]
Subject: RE: what problem is solved by proscribing non-64 bit prefixes?

I also tend to not favor "that's the way we have always done it" type
of
arguments.

In this case, however, I just see it in an operational and pragmatic
perspective - 
1) I fail to see the need for more subnet bits, based on current
deployment
plans calling for /48s or /56s per client
2) I certainly see an operational pain point for all current vendors,
providers and environments that currently support/provide/use IPv6
3) Nothing stops you from breaking the RFC and doing arbitrary bit
length
subnets now, as long as you are willing to endure the pain involved

Additionally, if longer prefixes are normalized, what would prevent
providers from adjusting their allocations accordingly and the
end-users
gaining nothing?
(i.e. - instead of assigning /56s to support /64s, they would simply
assign
/108s to support /112s or somesuch.)
((or, at the very least, they could switch from assigning /56s to /64s
and
thus -requiring- (versus "enabling") you to do this type of
subnetting))

/TJ

>1.  DHCPv6, or more flexible versions of SLAAC, CGA, etc., are needed
2.
>1. That is the way the prefix is currently defined in mu favorite RFC
2. We
64-bit
>From: [email-masked] [mailto:[email-masked]] On Behalf
Of
>And, consequently, the ability to ask for and receive something other
than
a
of
I
may
>"Bits to the left of me, Bits to the right, Here I am - Stuck in the
middle
>If the ability to do what one wants, is permitted by non-64 bit
prefixes,
this.
>If only 64-bit prefixes can be used, then one gets only one 64-bit
prefix
to

---

From: "TJ" <[email-masked]>
Date: Thu, 2 Oct 2008 12:42:50 -0400

And I understand clients having needs, as well.  
First, I would encourage the client to try and get (as feasible) a large
block ... add bits to the left instead of the right.
	(I realize that if this was feasible, we might not be having this
conversation now ... but had to say it regardless)
Secondly, I would ask if other options been pursued ... if you can share 

Your client's need is why I referenced the (expired) draft -->
http://tools.ietf.org/html/draft-dickson-v6man-new-autoconf-00 
	... there may be more appropriate drafts out there, this is just the
first probably-relevant one I found ...
-If- there is consensus that this need is prevalent, make a standard and see
-if- you can get vendor buy-in.
	I personally think those are two very big "ifs", but I have
certainly been wrong atleast once or thrice in the past :).
	Again, these conversations all took place 10-15 years ago and all of
those needs, decisions, etc. fed into the current standard.
		... not saying things can't change, obviously(!), but unless
new reasons have arisen I remain skeptical.

"As to vendor pain, going down the road of minimizing vendor pain leads us
back to every vendor selling a proprietary networking protocol"
I think the opposite is true ... isn't that part of the standardization
process; to reduce those proprietary situations and providing a consistent,
level playing field?  Everything over IP is the path of least resistance
today for a good reason.  The operational pain comes into play in that once
something longer is standardized, it will likely be used by providers and
thus limit future client capabilities based on current client needs -
something IPv6 is expressly trying to avoid.

FWIW, I would be quite distraught if my ISP tried to give me only 16 host
bits / 64k worth of addresses.
Anything less than 64 host bits now, or even 48 host bits as one draft has
proposed, breaks autoconf.  
	That is bad right out of the shoot.

Oh, and yes - I said only 64k IPs.  
I know of lots of ongoing development in "dense node" applications, and I
want myself and my clients to be ready to take advantage of those in the not
too distant future.  Which is (just) part of the justification for the
64bits in the first place; but I am not saying these desires outweigh your
client's current need.

... great conversation so far, now I am back to work ... 
/TJ

>Sent: Thursday, October 02, 2008 12:00 PM
>To: TJ; [email-masked]
>I understand that you do not see the need to a prefix longer than 64 bits;
>however, my customer has an application for extended address.  As a result,
>there is an engineering need.
>
>I am not sure that I see any pain for current providers or environments.
>Those who are deploying 64 bit prefixes and want to stick with them are
free
>to do so.  As to vendor pain, going down the road of minimizing vendor pain
>leads us back to every vendor selling a proprietary networking protocol.
>
>As to breaking the RFC, although no one can stop me, it increases my pain,
>which I have an incentive to avoid.
>
> With regards to ISPs handing out smaller prefixes, I believe that should
>remain between the ISP and customer.  Personally, I could care less if my
>ISP handed me a /112.  That still leaves 16 bits or 65535 end systems,
which
>is more than enough for my home.  Businesses needing more space would
>negotiate a larger allocation and, like IPv4 addresses, probably have to
pay
>for it.
>/108s to support /112s or somesuch.) ((or, at the very least, they could
>switch from assigning /56s to /64s and thus -requiring- (versus "enabling")
>you to do this type of
>subnetting))
>
>
>/TJ
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Oct 2008 14:08:24 +1300

> pain, which I have an incentive to avoid.

Then your remedy is to write a draft aimed at the 6man WG with the goal
of updating RFC 4291 accordingly, and asking the WG to consider it.

    Brian

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Thu, 2 Oct 2008 07:12:51 -0400

Pekka,

My comments are inline.

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]] 
Sent: Thursday, October 02, 2008 3:48 AM
To: Dunn, Jeffrey H.
Cc: Brian Dickson; Brian E Carpenter; Alexandru Petrescu; IETF IPv6
Mailing List; Ron Bonica; [email-masked]; Pasi Eronen;
Sherman, Kurt T.; [email-masked];
[email-masked]; [email-masked]; [email-masked]; V6ops Chairs;
Martin, Cynthia E.
Subject: RE: what problem is solved by proscribing non-64 bit prefixes?

>> would only be able to transmit an octet every 4679 YEARS to the
router
v> on a gigabit link.  I see no possible application for such an

>technology being usable in the wild.

While I agree with your assertions concerning flexibility and
robustness, I do not agree that 2^64 is the minimum number of nodes
that should be supported on a link.  Consider current IPv4 deployments.
I doubt anyone have configured a single router interface with any
prefix shorter than /8 (24 bits for hosts).  As a result, it would seem
to me to be a reasonable and conservative to assume that one might want
to use an IPv6 /96 (32 bits for hosts).  Regardless of that, I see no
reason to constraint folks from using other numbers of bits, both more
and less than 64.  The bottom line is that I do not understand why
folks feel the need to constrain network architects and administrators
to use only 64 bit prefixes.

>fail to see how this argument would apply to IPv6.

That is because you did not read the initial paragraph, which points
out that SLAAC requires a one-to-one mapping of prefixes to links,
e.g., Ethernet broadcast domains.  In addition, OSPFv3 also forbids
prefixes from spanning interfaces.  As a result, 2^13 prefixes could be
required if one wanted to be sure that all 2^13 VLAN identifiers were
available to a given physical interface.  This fits in with your
statement about the ability to design new protocols and mechanisms to
leverage address bits.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 2 Oct 2008 14:32:24 +0300 (EEST)

> to use only 64 bit prefixes.

Back then, folks felt that mapping an Ethernet MAC address 
(one-to-one) was a good idea.  That requires 48 bits.  Initially, the 
interface identifier part was 48 bits (RFC1884), but that was thought 
inadequate and it was expanded to 64, probably because other media 
needed more than 48 and bits were there.  I don't think this design 
decision is worth revisiting.

But no one will force you to use this numbering in your own network if 
you don't want to.  It just might be that some protocols don't work 
quite as well.

> statement about the ability to design new protocols and mechanisms to

I read it, and read it again.  Again, I ask, how do you solve this 
problem with IPv4?  I'm not seeing it.  IPv4 has (AFAIK) the same 
constraints except that IPv6 has link-local addresses and you actually 
don't need any prefix at all unless you attach hosts to the link.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 02 Oct 2008 14:49:41 +0200

Pekka, hi,

Pekka Savola wrote:
> Back then, folks felt that mapping an Ethernet MAC address (one-to-one) 
> was a good idea.  That requires 48 bits.  Initially, the interface 
> identifier part was 48 bits (RFC1884), but that was thought inadequate 
> and it was expanded to 64, probably because other media needed more than 
> 48 and bits were there.  I don't think this design decision is worth 
> revisiting.

I'm aware of several IEEE link layers and none uses 64bit addresses. 
IEEE tries to have them all 48bit.  Even non-IEEE (like USB) tries to be 
48bit.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 02 Oct 2008 14:55:39 +0200

Dunn, Jeffrey H. wrote:
> Pekka,
> 
> My comments are inline.
> 
> Best Regards,
> 
> Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 
> 448-6965 (mobile)
> 
> -----Original Message----- From: Pekka Savola 
> [mailto:[email-masked]] Sent: Thursday, October 02, 2008 3:48 AM 
> To: Dunn, Jeffrey H. Cc: Brian Dickson; Brian E Carpenter; Alexandru 
> Petrescu; IETF IPv6 Mailing List; Ron Bonica; 
>>> On Wed, 1 Oct 2008, Dunn, Jeffrey H. wrote: 1. It seems rather 
>>> wasteful to assign 2^64 addresses to each link. This assignment 
>>> corresponds to. 1.8x10^19 individual end systems.
> Even
>>> if this number of systems could be attached to a link, each 
>>> speaker would only be able to transmit an octet every 4679 YEARS 
>>> to the
> router v> on a gigabit link.  I see no possible application for such 
> an
>>> arrangement.
> 
>> The point is not to able able to put 2^64 hosts on a link, it's 
>> being able to put *enough* nodes on the link, with *near-zero* 
>> address collision probability, so that you'll never need to 
>> renumber the link to have more address space if the address space 
>> was not sufficient after the number of connected hosts grow.  An 
>> added bonus is an ability to design new protocols and mechanisms 
>> that are able to leverage those bits in the address with reasonable
>>  expectation of said
> 
> that should be supported on a link.  Consider current IPv4 
> deployments. I doubt anyone have configured a single router interface
>  with any prefix shorter than /8 (24 bits for hosts).

I think along the same lines.

I doubt any Ethernet subnet can support anywhere up to 2^64 hosts in the
same subnet.  Ethernet subnet is the scope of a Ethernet-broadcasted MAC
message.

Even considering a rack of 10 64port Hubs, all in the same subnet, each
port connected to 1000 endnodes it's still a much smaller number than 2^64.

Just a note,

Alex

> As a result, it would seem to me to be a reasonable and conservative
> to assume that one might want to use an IPv6 /96 (32 bits for hosts).
> Regardless of that, I see no reason to constraint folks from using
> other numbers of bits, both more and less than 64.  The bottom line
> is that I do not understand why folks feel the need to constrain
> network architects and administrators to use only 64 bit prefixes.
> 
>>> 2.  Since each VLAN is a link, i.e., a separate Ethernet 
>>> broadcast domain, each VLAN on a physical interface must have its
>>>  own prefix.
> As
>>> a result, to support the use of all possible VLAN identifiers 
>>> (2^12 possibilities) each router interface with a VLAN module 
>>> must be assigned at least a /52.  For routers with multiple VLAN 
>>> modules, 16 for example, this corresponds to the individual 
>>> router requiring a
> /48.
>>  degenerate case) for each VLAN-capable router interface today, so 
>> I fail to see how this argument would apply to IPv6.
> 
> prefixes from spanning interfaces.  As a result, 2^13 prefixes could 
> be required if one wanted to be sure that all 2^13 VLAN identifiers 
> were available to a given physical interface.  This fits in with your
>  statement about the ability to design new protocols and mechanisms 
> to leverage address bits.
>

---

From: <[email-masked]>
Date: Fri, 3 Oct 2008 10:58:52 +0100

> IEEE tries to have them all 48bit.  Even non-IEEE (like USB) 
> tries to be 48bit.

Have you ever heard of EUI-64?
<http://standards.ieee.org/regauth/oui/tutorials/EUI64.html>

One notable IEEE protocol which uses EUI-64 is Firewire (IEEE 1394). For
more info see RFC 3146.

--Michael Dillon

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 03 Oct 2008 12:19:35 +0200

> <http://standards.ieee.org/regauth/oui/tutorials/EUI64.html>

Well yes, good pointer.

> One notable IEEE protocol which uses EUI-64 is Firewire (IEEE 1394). For

Thanks for this pointer too.  I must ack I've not experimented IPv6 nor 
IPv4 over Firewire.  Are there some implementations of IPv6 over Firewire?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 03 Oct 2008 22:04:21 +0200

Michael, allow me following up my own email.  Re the question about 
implementations of IPv6 over Firewire, I wanted to refine it.

I think some implementations of IPv6 over Firewire may still waste these 
fffe bits, still questioning the point of 64-bit EUI-64 (instead of say 
48bit).

(googling some earlier discussion on web [*]):
> $ ifconfig fw0
              ^^^
> fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 2030
>         inet6 fe80::21c:b3ff:fe7c:d17a%fw0 prefixlen 64 scopeid 0x5
                             ^^^^^
>         lladdr 00:1c:b3:ff:fe:7c:d1:7a
                           ^^^^^
The refined question would thus be: would there be some IPv6 over 
Firewire implementation which wouldn't waste these fffe bits?

(sorry for the questioning style of mails, I'm just humbly trying to see
  whether I'm completely off with these fffe lost bits).

Alex
[*] http://lists.apple.com/archives/ipv6-dev/2007/Dec/msg00001.html

Alexandru Petrescu wrote:
>>> IEEE tries to have them all 48bit.  Even non-IEEE (like USB) tries to 
>>> be 48bit.
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Oct 2008 12:41:31 +1300

> fffe bits, still questioning the point of 64-bit EUI-64 (instead of say

The reason this decision was taken in 1995 or thereabouts was because
some participants made a very strong case that on a multi-decade timescale,
EUI-64 would probably replace 48 bit IDs. Firewire was the leading
edge example quoted back then. Now my crystal ball doesn't seem to be
working very well when set to year 2050, but do you want to risk
enormous operational problems then, if current hardware is all shipped
using EUI-64, and all dentists offices are running SLAAC? We are not
taking short term tactical decisions here.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 4 Oct 2008 10:48:31 +0930

On Wed, 1 Oct 2008 10:45:21 -1000 (HST)
Antonio Querubin <[email-masked]> wrote:

> how IPv6 capabilities enable other potential solutions.

This is the exact mental trap a lot of people seem to fall into.

IPv6 is similar to IPv4, but I'd argue that it's even more
similar to Novell's IPX and Apple's Appletalk than it is to IPv4.
IPv6 seems to me to have many of the features of IPv4, IPX, Appletalk
and other protocols before it that have proven to be useful. That means
if you have some operational experience with these other protocols, you
can also think about where and how they were better than IPv4,
and also see if you can apply that thinking to IPv6, for features of
them that have been carried through to IPv6.

When I think about fixed length subnets and whether they're useful or
not, I think back to my pre-IPv4 days of working with Novell's IPX with
it's fixed length 48 bit node addresses, and in particular, how much
easier and simpler it was having fixed length subnets everywhere
on the network, including on point-to-point WAN links. We didn't have a
choice about whether we "wasted" node address bits or not because
it was part of the protocol spec, but it never caused any problems
either - for point-to-point links we never said, "I wish we weren't
forced into wasting those other 47 bits."

Ethernet addressing also "wastes" bits for operational convenience -
who's ever going to put 2^46 hosts on an ethernet segment! It's the
original "plug and play" networking technology, and those design
decisions were made in early 80s. The paper "48-bit Absolute Internet
and Ethernet Host Numbers" describes the considerations behind this
decison.

IPv6 should be at least as easy to use as Ethernet, IPX and Appletalk
are or were. If it isn't then I think we've failed. 64 bit fixed length
subnets is one of the ways this goal can be achieved.

I'd really encourage people who don't have any knowledge of or
experience with any other layer 3 protocols other than IPv4 to have a
look into how those other protocols were different and how they worked.

Regards,
Mark.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Oct 2008 18:20:26 -0700

It is not a recommendation, as long as the "e.g." part is in the text. 
And it already is, so no problem. (But Tony's and Fred's suggested edits 
certainly deserve to be taken into account.)

Jari

Brian E Carpenter wrote:
> Marla,
>
> In what sense is "(e.g. on a basis of /48)" a recommendation?
>
>    Brian
>
> On 2008-10-01 04:09, Azinger, Marla wrote:
>   
>> My point with all of this is that I don't see it proper for IETF documents to reflect or suggest anything other than a technical boundary.  Neither /48 or /56 are technical boundaries and they shouldn't be put in an IETF document as a recommendation just because its the "flavor" of an RIR for the current year or because it just sounds good.
>>
>> I am asking all of you to stick to factual technical aspects.  The minute a subnet is written into an IETF document as a "recommendation" it limits RIR policy in the future due to ignorance.  RIR communities historically have taken the word "recommendation" as a warning sign that if you go more or less specific with a subnet you would venture into a technical issue.  And then it turns into a painful game of trying to change RIR policy or IETF documentation once reality hits that the "recommended" subnet had no technical significance, or more experience was gained and what was thought to be technically true turns out not to be.
>>
>> What the world needs are documents that point out factual boundaries.  And if there aren't any then point that out as well.  But the last thing we need is another IETF document that inserted selected subnet sizes without technical significance.  This very reason is why the ARIN RIR is messed up and has /32 as the Allocation size due to an IETF document that "recommended" /32 without any technical basis.
>>
>> I caution any use of a specific subnet size unless its pointing out a known technical barrier.
>>
>> Thank you
>> Marla Azinger
>> Frontier Communications
>> ARIN AC
>>
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
>> Sent: Tuesday, September 30, 2008 4:02 AM
>> To: Brian E Carpenter
>> Cc: IETF IPv6 Mailing List; Ron Bonica; Pasi Eronen; [email-masked]; [email-masked]; V6ops Chairs
>> Subject: Re: v6ops-addcon and longer than 64 bit prefixes
>>
>> If the registries are using /56, why recommend what they have tried and found wanting?
>>
>> On Sep 28, 2008, at 5:35 PM, Brian E Carpenter wrote:
>>
>>     
>>> /56 is a choice currently used by the registries. That doesn't
>>> invalidate using /48, if you consider that to be a more interesting
>>> allocation unit to consider. So I don't see a problem with "(e.g. on a
>>> basis of /48)".
>>>
>>>    Brian
>>>
>>> On 2008-09-29 09:55, Turchanyi Geza wrote:
>>>       
>>>> Colleagues,
>>>>
>>>> Ooops,
>>>>
>>>> HD is calculated for prefixes, but on the basis of /56
>>>>
>>>> (since November 2007)
>>>>
>>>> Please see
>>>>
>>>> http://www.ripe.net/ripe/docs/ripe-421.html#utilisation
>>>>
>>>> Best,
>>>>
>>>> Geza
>>>>
>>>>
>>>>
>>>> On Fri, Sep 26, 2008 at 8:21 AM, Fred Baker <[email-masked]> wrote:
>>>>         
>>>>> nit on the nit...
>>>>>
>>>>> HD is calculated for prefixes (e.g. on a basis of /48), instead of
>>>>> *being*
>>>>> based on endpoint addresses as IPv4 is.
>>>>>
>>>>> (the second part needed a verb)
>>>>>
>>>>> On Sep 25, 2008, at 12:51 PM, Tony Hain wrote:
>>>>>
>>>>>           
>>>>>> Wording nit in 2.4.2
>>>>>> Current:
>>>>>> HD is calculated for sites (e.g. on a basis of /48), instead of
>>>>>> based on addresses like with IPv4 should read:
>>>>>> HD is calculated for prefixes (e.g. on a basis of /48), instead of
>>>>>> based on endpoint addresses like with IPv4
>>>>>>
>>>>>>
>>>>>> It is not clear that the 6bone space discussion is appropriate for
>>>>>> this document, and restating what is effectively a policy will
>>>>>> cause a problem in the future. Removing the last sentence of 2. and
>>>>>> all of 2.3 will not impact the intent of this document. Given that
>>>>>> the stated target audience is network managers that have not
>>>>>> figured out an IPv6 addressing plan, confusing them with a
>>>>>> discussion about ancient history is not helpful.
>>>>>>
>>>>>> Tony
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>>> Behalf Of Jari Arkko
>>>>>>> Sent: Thursday, September 25, 2008 12:02 AM
>>>>>>> To: IETF IPv6 Mailing List
>>>>>>> Cc: [email-masked]; V6ops Chairs; Pasi
>>>>>>> Eronen; Ron Bonica
>>>>>>> Subject: v6ops-addcon and longer than 64 bit prefixes
>>>>>>>
>>>>>>> Folks,
>>>>>>>
>>>>>>> Draft-ietf-v6ops-addcon was in IESG review and there was a lot of
>>>>>>> discussion about the recommendations an earlier version of the
>>>>>>> draft had about prefix lengths longer than 64 bits. The draft has
>>>>>>> now been revised to what we believe is reasonably consistent with
>>>>>>> reality and existing
>>>>>>> IPv6 address architecture RFCs. However, it would be good to give
>>>>>>> the 6MAN WG a chance to review the text.
>>>>>>>
>>>>>>> Please take a look at the document and the given two sections in
>>>>>>> particular:
>>>>>>>
>>>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-addcon-10
>>>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-addcon-10#section-3.1
>>>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-addcon-10#appendix-B
>>>>>>>
>>>>>>> If there is no objection the draft will be approved. Please
>>>>>>> comment by September 30th.
>>>>>>>
>>>>>>> Jari
>>>>>>>
>>>>>>> ------------------------------------------------------------------
>>>>>>> -- IETF IPv6 working group mailing list [email-masked]
>>>>>> -------------------------------------------------------------------
>>>>>> - IETF IPv6 working group mailing list [email-masked] Administrative

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Oct 2008 18:41:20 -0700

Alex,

> An ADSL IPv6 operational deployment offers a /64 prefix at home.

The DSL Forum recommendations for IPv6 are being worked on. I believe 
they are based on the concept of prefix delegation and prefixes shorter 
than 64 bits.

I.e., my hope is that in the future you will not be getting a /64 from 
your DSL provider.

Jari