Subject: IPv6 addresses really are scarce after all

From: <[email-masked]>
Date: Fri, 17 Aug 2007 21:08:43 +0100

It seems that someone in ARIN land believes that IPv6 addresses are
scarce resources that need to be carefully dribbled out to customers
according to need. The following proposal has just been formally made to
change ARIN's allocation policy.

------start of copied text------

Replace the text in section 6.5.4.1 with the following text:

LIR's may assign blocks in the range of /48 to /64 to end sites.
All assignments made by LIR's should meet a minimum HD-Ratio of .25.

* /64 - Site needing only a single subnet.
* /60 - Site with 2-3 subnets initially.
* /56 - Site with 4-7 subnets initially.
* /52 - Site with 8-15 subnets initially.
* /48 - Site with 16+ subnets initially.

For end sites to whom reverse DNS will be delegated, the LIR/ISP should
consider making an assignment on a nibble (4-bit) boundary to simplify
reverse lookup delegation.

LIR's do not need to issue all 5 sizes of prefixes as long as the
HD-Ratio requirement is met.

------end of copied text------

--Michael Dillon

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Aug 2007 16:40:03 -0400

this is silly.  any site with even a single IPv4 address can get a /48
through 6to4, and this was chosen to match the architected minimum
allocation for a native prefix.

someone should tell ARIN that trying to mess with the address
architecture is out of their scope.

---

From: <[email-masked]>
Date: Fri, 17 Aug 2007 21:56:45 +0100

> this is silly.  any site with even a single IPv4 address can 
> get a /48 through 6to4, and this was chosen to match the 
> architected minimum allocation for a native prefix.
> 

And that someone is the IETF because the IETF is the someone who created
the architecture in the first place. It would not be out of place for
some of the indivduals who were at the center of creating this
architecture to produce an informational RFC with guidance to RIRs.

Since all the RIRs have relatively open policymaking processes, it is
relatively easy for people drenched in IPv4 thinking to water down the
IPv6 addressing architecture.

If someone out there can point me to an RFC reference for the IPv6
address architecture, I will pass it on.

--Michael Dillon

---

From: Bill Manning <[email-masked]>
Date: Fri, 17 Aug 2007 14:10:10 -0700

Michael Dillon sez:

"ARIN ... belives IPv6 addresses are ... resources that need to be 
[distributed] according to need."

I guess I have to agree with this sentiment.  If the ARIN community
decides there is a better way to distribute IP addresses *OTHER THAN*
need, I'd be really happy to hear what that method would be.

--bill

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 17 Aug 2007 14:32:16 -0700

> HD-Ratio requirement is met.

If you get ivp6 address space you should receive enough that you won't
have to come back, whether you're a residential customer recieving it
from your isp, an end site that part of a larger entity or a customer of
an isp, or meet the classical definition of an isp . given that point to
point links are generally numbered as /64s assigning an end site
something smaller than a /56 is likely to result in a number of
scenario's where that address space is quickly exhausted.

Repeated returns for more address space eventually result in
fragmentation in the absence of careful manangement of initial
allocation or renumbering which people have been generally loath to do.

Within  our block 2001:490:: we have as a general rule been handing out
/48s to end sites within the enterprise that require subnetting. That
give them a couple bits to further subdivide if necessary and enough
/64s that they shouldn't be coming back for more anytime soon.

It seems likely that cable mso's similar will dole out /64's to
customers one at a time, I suppose that's acceptable if not necessarily
desirable and will probably still result in the use of nat mechanisms in
end systems.

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Aug 2007 19:05:54 -0400

> desirable and will probably still result in the use of nat mechanisms in
that's COMPLETELY unacceptable.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 18 Aug 2007 08:46:25 +0900 (JST)

> change ARIN's allocation policy.

	for the world peace, as long as it does not have impact to global
	routing table (= do not leak out on cross-AS border) it is fine.

	for the ease of use for customers, it is a no-no, because they would
	like to use /48 always.  if they get /62 or something they will need
	to get more prefixes again and again, and/or the amount of addresses
	would affect the address allocation policy towards the customer network
	subnets.

	so, i would like to say "do not do this".  is it too late or still
	possible?

itojun

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 17 Aug 2007 17:01:39 -0700

> that's COMPLETELY unacceptable.

Well lot's of people still think things like "why would home users ever
subnet" but when you walk into a decent electronics superstore these
days you can buy:

terabytes of network attached storage
HD video streamers
wireless voip handsets or dual mode wifi/cellular phones
building control and security systems that plug into ethernet or hang
out on your wifi
vlan capable managed switches that cost $150

At some point you stop wanting to have all those devices on the same
network if for no other reason than to keep your multicast HD video
streams from clobbering your ip phones, and around that same point the
needs of a household of 2-6 people plus visitors start to look a lot
like those of a heavily technology enabled small business. Have two or
more wage earners that work for large enterprises and have vpn tunnels
and associated network peripherals and you have issues that can keep
consultants employeed for some time...

This is a fairly unusual problem right now, but it won't be for long.

joelja

---

From: Tony Li <[email-masked]>
Date: Fri, 17 Aug 2007 17:11:10 -0700

> that's COMPLETELY unacceptable.

Interesting.  Here we have a finite resource with clear, non-zero value
that is being allocated by duly appointed numbering authorities based on
need and then subsequently being allocated to end-users.  Where's the
issue?  If you have a beef with only getting a /64, I'm sure that the  
MSO
would be MORE than happy to give you more.  For a price.

If something is unacceptable here, its because your expectations aren't
being met.  Is it the policies that are unreasonable?

Tony

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 17 Aug 2007 20:54:22 -0400

On Fri, 17 Aug 2007 17:01:39 -0700
Joel Jaeggli <[email-masked]> wrote:

> >> customers one at a time, I suppose that's acceptable if not
> >> necessarily desirable and will probably still result in the use of
> >> nat mechanisms in end systems.
> >>   
> Well lot's of people still think things like "why would home users
> ever subnet" but when you walk into a decent electronics superstore
> these days you can buy:
> 
I'm not sure what your point is -- I took Keith's comment to mean that
home NATs with v6 were completely unacceptable.

I agree with you on the desirability of home routers, though it's going
to be an interesting challenge to build "fire and forget" boxes for the
house.  Of course, I'm the kind of guy who already has 3 (and sometimes
4) segments on my home LAN, so I suppose I really need home routers
that speak OSPF....

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Tony Li <[email-masked]>
Date: Fri, 17 Aug 2007 18:05:49 -0700

> home NATs with v6 were completely unacceptable.

/64's do NOT imply that there's NAT functionality involved, just that  
there's
a single subnet, yes?

Tony

---

From: Robin Whittle <[email-masked]>
Date: Sat, 18 Aug 2007 12:47:06 +1000

I am concerned about DFZ routers needing to have their FIBs look at
48 bits of address for every packet sent to one of the new end-user
address blocks as allocated by ARIN, AfriNIC and now RIPE.

> * /48 - Site with 16+ subnets initially.

A wide TCAM can handle these address bits in a single clock-cycle,
but the high end routers CRS-1, M120 and MX960 don't use TCAM in
their FIB.  TCAM chews too much power, is too expensive, has long
update times and has various other problems.  These high end routers
use trie-based algorithms involving lookups into gigabytes of slow,
shared, DRAM. This can only be done some number of bits at a time,
where that number may by 5 to probably 20 or maybe 24 at the
absolute maximum.

  http://www.firstpr.com.au/ip/sram-ip-forwarding/router-fib/

Consider a stream of 50 IPv6 VoIP packets a second, each bearing 20
bytes of data.  Let's say it has to go through 16 DFZ routers.  With
the new /64 allocation size, every packet chews the resources of 20
routers each having to work its way through 64 bits of address, with
 RAM lookups.  That's 128 bytes of address data to be processed,
laboriously, en-route, for a lousy 20 bytes of relatively
inconsequential VoIP call - 1/50 second.

Each VoIP call between hosts in two /64 prefixes with 16 DFZ routers
en-route involves those routers collectively working through this
many bits:

  50 * 2 * 64 * 16 = 120,400 bits!!

This sounds really inefficient, compared to IPv4 in which DFZ
routers in practice need to look at 24 bits, at most, of the
destination address of IPv4 packets.  Since only about 1.23% of the
advertised space is for prefixes of 21 bits or more:

  http://www.firstpr.com.au/ip/host-density-per-prefix/

16 to 20 bits is probably sufficient for most packets.

 - Robin

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 18 Aug 2007 12:25:16 +0900 (JST)

> change ARIN's allocation policy.

	sorry, is there a URL so that i can check the entire dicussions,
	conclusions and status?

itojun

---

From: Keith Moore <[email-masked]>
Date: Sat, 18 Aug 2007 05:02:51 -0400

Tony Li wrote:
> issue?  
The issue is that IPv6 is architected to give sufficient addresses to
end users, and by screwing with this ARIN is harming both deployability
of IPv6, manaegability of IPv6, and usability of IPv6 by applications.

Protocol design and architecture is not within ARIN's scope.
> If something is unacceptable here, its because your expectations
> aren't being met.  
no, it's because they're screwing with protocol design decisions that
have already been made, and which they aren't by any stretch of the
imagination qualified to revisit.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 18 Aug 2007 05:04:54 -0400

> /64's do NOT imply that there's NAT functionality involved, just that
yes, but it's unreasonable to expect a home user to not need to subnet. 
particularly when there are so many different media  competing for the
home network space....it would be reasonable to have a subnet for each
medium.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 18 Aug 2007 08:51:47 -0400

On Sat, 18 Aug 2007 05:04:54 -0400
Keith Moore <[email-masked]> wrote:

> 
> >> I'm not sure what your point is -- I took Keith's comment to mean
> >> that home NATs with v6 were completely unacceptable.
> >
> >
> > /64's do NOT imply that there's NAT functionality involved, just
> > that there's
> > a single subnet, yes?
> yes, but it's unreasonable to expect a home user to not need to
> subnet. particularly when there are so many different media
> competing for the home network space....it would be reasonable to
> have a subnet for each medium.
> 
> 
I originally agreed with you on that.  However, given modern switches,
I'm not nearly as convinced.

---

From: David Conrad <[email-masked]>
Date: Sat, 18 Aug 2007 09:16:00 -0700

Keith,

On Aug 18, 2007, at 2:04 AM, Keith Moore wrote:
> subnet.

You're kidding, right?

You're actually expecting folks who couldn't set up VCR timers to  
configure _subnets_?

Regards,
-drc

---

From: Keith Moore <[email-masked]>
Date: Sat, 18 Aug 2007 12:58:34 -0400

> You're actually expecting folks who couldn't set up VCR timers to
no, I'm expecting subnets to be automatically configured by the border
router.   when the  prefix assigned to the home is a /48, like it should
be,  it's not unreasonable for a home router to divide it up into fixed
sized chunks and hand out those chunks to interior routers that ask for
them.

---

From: Keith Moore <[email-masked]>
Date: Sat, 18 Aug 2007 13:02:14 -0400

> I'm not nearly as convinced.
a clever router/switch could certainly do a lot without subnetting.

one of the areas in which I think the IPv4 design failed is that it
didn't really follow the catenet model.  it was not possible to extend
the network from any point.  and this is part of what led to NATs,
because there really was a need to be able to do that.  IPv6 doesn't
quite let you do that either, but having long addresses is probably
"good enough" provided the prefixes given to supposed "end users" are
still long enough to allow a couple of additional layers of network to
be hung off of them.

---

From: Terry Gray <[email-masked]>
Date: Sat, 18 Aug 2007 11:34:34 -0700 (Pacific Daylight Time)

On Sat, 18 Aug 2007, Keith Moore wrote:

> because there really was a need to be able to do that.  

I strongly agree, and would add that:

1. Provider independent addresses are really important to a lot of 
people, especially those responsible for bunches of machines (or for
running servers).  Without them, something like NAT is guaranteed to 
persist, in order to minimize cost and disruption of renumbering, or 
being held hostage by a provider.  

2. Essentially free addresses are really important to a lot of people, 
especially anyone responsible for bunches of machines... Without them, 
something like NAT is guaranteed to persist, in order to minimize 
cost.

Sounds like the "scarcity-based" v6 allocation policies (and any 
constraints on who can get PI addresses) will guarantee IETFer's worst 
nightmare: v6 NATs forever.

-teg

---

From: David Morris <[email-masked]>
Date: Sat, 18 Aug 2007 12:51:11 -0700 (PDT)

On Sat, 18 Aug 2007, Terry Gray wrote:

>...

And the growing adoption of virtualization will contribute further to the
numbers of "machines" needing unique addressibility ...

Dave Morris

---

From: Mark Andrews <[email-masked]>
Date: Sun, 19 Aug 2007 07:25:02 +1000

> You're actually expecting folks who couldn't set up VCR timers to  

	I have friends that are using multiple subnets in IPv4
	without being aware they are.  One net is a doubly
	NAT'd wireless network. 

	It really should be no harder in IPv6.  Plug the router
	in.  It get a "upstream" address vi autoconf/dhcp.  It
	requests a prefix allocation of its down stream via
	DHCP which the edge router supplies by using a unallocated
	prefix it has or by relaying / combining the request.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Tony Li <[email-masked]>
Date: Sat, 18 Aug 2007 14:47:05 -0700

Keith,

>>>> customers one at a time, ...

> of IPv6, manaegability of IPv6, and usability of IPv6 by applications.

First, there was never an architectural goal to give end users  
'sufficient' addresses
for arbitrary values of 'sufficient'.  Second, one might reasonably  
expect 2^64
addresses to be sufficient.  It allows anyone to embed 2^32 entire  
IPv4-sized Internets
in their own house.  If you have a problem with IPv6's routing  
architecture not allowing
subnetting within the least significant 64 bits, well, that's water  
that's VERY much
under the bridge.

Third, I think you have your perpetrator's confused.  ARIN is not  
limiting end users
to /64's, that is the MSOs call.  They are retailing service and as  
you might reasonably
expect, their entry level product is just that: entry level.  As I  
mentioned before, if you
want more, fork over more sheckles.  Most MSOs would VERY much like to
sell you a service with a fraction of an IPv4 address today, but they  
really haven't
figured out how they could do so technically.  For v6, they will  
always sell a service
with a minimal amount of address, regardless of ARIN policies.  If  
they could figure
out how to make that a /128, they would.

This is just good business sense on their part: buy low, sell high.

> imagination qualified to revisit.

Exactly what decision are you claiming they violate?  Please quote  
the RFC.
I don't know which one you're on about.

Thanks,
Tony

---

From: Tony Li <[email-masked]>
Date: Sat, 18 Aug 2007 15:00:42 -0700

> a clever router/switch could certainly do a lot without subnetting.

Indeed.  If you Google around a bit for "MAC table size", I think that
you'll find it hard to find an advertised size less than 1K entries,  
and that's
for a shrink-wrapped 8 port switch.

I'll believe that entry level boxes are smaller than that, but then  
once you
have more than a handful of systems, it would not be unreasonable
to invest a teeny amount in a better switch.

Just how big is your house/////TARDIS anyway?

> still long enough to allow a couple of additional layers of network to

The only way to do what you want is to effectively have a variable
length address.  While there were a few crazy advocates of this many
years ago, they were shouted down.

Tony Li
Lead Lunatic

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 18 Aug 2007 23:10:40 +0100

Tony Li wrote:
[..]

> Most MSOs would VERY much like to
> figured out how they could do so technically.  For v6, they will always
> sell a service
> with a minimal amount of address, regardless of ARIN policies.  If they
> could figure out how to make that a /128, they would.

When they do, they are violating the premises on which they received
their allocation. As such any ISP which is not willing to provide a /48*
to an end-user should get their IPv6 allocation revoked by the RIR.

Unfortunately it is for any RIR not very easy to check up on these
things. Though it would be great if the RIRs have an easy reporting
mechanism for these cases so that end users can report against ISPs
which are not willing to provide them with IP addresses.

ISPs should be charging based on *bandwidth usage* not on IP usage.
It is really strange that they do do that as they are paying their
transits based on traffic too, not on the amount of addresses.
Of course it is a great way to do business, but lousy for the enduser,
and it will only really cause the thing that IPv6 was supposed to avoid:
NAT or better said to be able to provide end-to-end connectivity.

Alas, as long as ISPs can get away with it, they will most likely do so.

Greets,
 Jeroen

* currently, which is why the /56 thing has come up again, which IMHO
might be a good idea as a /48 is an awful lot that I won't even use at
home, though a /48 for every end-site is fine by me as it currently is too.

---

From: "Hex Star" <[email-masked]>
Date: Sat, 18 Aug 2007 15:39:00 -0700

Jeroen...

So I guess Comcast shouldn't be allowed IPv6 then? They refuse to provide
home users a static IP unless they upgrade to their $100+ business plans
which is quite unreasonable for home use... It pisses me off but it's all
part of their TOS game in which they state that "Public servers are
prohibited unless you have a static IP" and thus they want to charge you an
arm and a leg... But this doesn't make sense when corps like SBC don't have
such rules and Comcast seems to have plenty of bandwidth based on their
PowerBoost campaigns...
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Sat, 18 Aug 2007 19:34:58 -0400

> addresses to be sufficient.  
perhaps, but one might also reasonably expect 2^0 networks to be
insufficient.
> It allows anyone to embed 2^32 entire IPv4-sized Internets
so are prefix allocations to users of less size than a /48.  but if ARIN
can't follow the specifications that everyone else uses, this should
call their competence into serious question, and maybe IANA should find
someone else to dole out IPv6 prefixes for that part of the world.
> want more, fork over more sheckles.
ARIN does not have a license to print money at the expense of the
Internet architecture.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 18 Aug 2007 19:42:17 -0400

> years ago, they were shouted down.
variable length addresses are a better idea than it appears at first
glance.  they do bring certain difficulties with them, especially when
trying to do fiber-speed switching in hardware.  it's hard to switch on
arbitrary bit boundaries and it's harder to switch in hardware using
prefixes of arbitrary length.  but there are ways to deal with these
problems.  nobody should expect core routers to pay attention to less
significant bits of a variable length address any more than they pay
attention to the less significant bits of a fixed length address, and
just because addresses are variable length doesn't mean that there
cannot be a maximum length of a prefix advertised in BGP.

overall it strikes me as a hell of a lot better than NAT.

---

From: Robin Whittle <[email-masked]>
Date: Sun, 19 Aug 2007 10:56:10 +1000

I retract what I wrote in a previous message about DFZ routers
needing to look at 64 bits of the packet's destination address.

> * /48 - Site with 16+ subnets initially.

from:

  http://lists.arin.net/pipermail/ppml/2007-August/008521.html

as referring to RIRs.

This proposal doesn't lead to any greater burden on FIBs of DFZ
routers, but I still think the /48 PI end-user assignments are
pretty hard on the routers.

Each VoIP call between hosts in two /48 prefixes with 16 DFZ routers
en-route involves those routers collectively working through this
many bits:

  50 * 2 * 48 * 16 = 76,800 bits!

  - Robin

---

From: Tony Li <[email-masked]>
Date: Sat, 18 Aug 2007 21:14:40 -0700

Keith,

> perhaps, but one might also reasonably expect 2^0 networks to be

At the risk of repeating myself, I respectfully disagree.  Given that  
you
can reasonably build a flat subnet of 1000 hosts today, it does
not seem like an unreasonable entry point.  Mom & Pop 6-pack
have one computer.  George & Jane Jetson only have 6.  Why
does the entry point have to be more than two orders of
magnitude above the common case?

> someone else to dole out IPv6 prefixes for that part of the world.

Once again, that's the MSO's doing that, not ARIN.

Tony

---

From: Tony Li <[email-masked]>
Date: Sat, 18 Aug 2007 21:21:40 -0700

> trying to do fiber-speed switching in hardware.

Poppycock.  Hardware for switching variable length addresses
first showed up about 15 YEARS ago.  This is Not Hard at all.

>   it's hard to switch on
> arbitrary bit boundaries

Hello, we've been doing that since CIDR.

> and it's harder to switch in hardware using
> prefixes of arbitrary length.

You mean addresses of variable length.  One way: when you
parse the packet, stuff the length (in bits) of the address in a
register.  Have your hardware autodecrement this register every
time it matches a bit in the lookup process.  Store any
intermediate result in a fixed, known location.  If the number of
bits remaining in the register hits zero before you match a prefix,
then promote any intermediate result to the final result.

> overall it strikes me as a hell of a lot better than NAT.

Please visit the appropriate parties with your time machine.
Immediately after the Big Ten meeting would be a fine start.

Tony

---

From: Keith Moore <[email-masked]>
Date: Sun, 19 Aug 2007 00:23:49 -0400

> At the risk of repeating myself, I respectfully disagree.  Given that you
you seem to be stuck in the 20th century. where do you get the idea that
IPv6 is only going to be used (or even, mostly going to be used) for
things that resemble desktop PCs?  desktop PCs are dinosaurs nearing
extinction, and early indications are that homes are going to have
multiple kinds of wireless networks.  bridges between dissimilar media
don't always work so well.  and given the range of some of those media,
it should not be assumed that everything within a "home" will be in the
same layer 2 segment.

IPv6 needs to last a lot longer than IPv4.  it shouldn't be constrained
to fit yesterday's notions of what's reasonable.

> Once again, that's the MSO's doing that, not ARIN.
whoever is doing it needs to stop, or be stopped.

---

From: Keith Moore <[email-masked]>
Date: Sun, 19 Aug 2007 00:26:29 -0400

> first showed up about 15 YEARS ago.  This is Not Hard at all.
sorry, I should have said addresses of arbitrary length.

---

From: Tony Li <[email-masked]>
Date: Sat, 18 Aug 2007 21:28:58 -0700

> to an end-user should get their IPv6 allocation revoked by the RIR.

Could you please site chapter and verse?  Here's what I can find:

http://www.arin.net/policy/nrpm.html#six54

6.5.4.1. Assignment address space size

End-users are assigned an end site assignment from their LIR or ISP.  
The exact size of the assignment is a local decision for the LIR or  
ISP to make, using a minimum value of a /64 (when only one subnet is  
anticipated for the end site) up to the normal maximum of /48, except  
in cases of extra large end sites where a larger assignment can be  
justified.

> ISPs should be charging based on *bandwidth usage* not on IP usage.

Sorry, ISPs charge based on providing a *service*.  Yes, that  
includes bandwidth (and generally flat bandwidth, not usage) and also  
other components (DHCP, addressing, DNS, email, web hosting, spam  
filtering, etc).

Tony

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sun, 19 Aug 2007 14:14:20 +0900 (JST)

> You're actually expecting folks who couldn't set up VCR timers to  

	ISPs ship a DSL termination box with ethernet and wifi interface to
	customers.  naturally these interfaces should be configurd as
	seaprate subnets (especially when MTU are different - like 9K MTU GbE), 
	nd they can be configured by ISPs before the box gets shipped.

itojun

---

From: David Morris <[email-masked]>
Date: Sat, 18 Aug 2007 22:19:03 -0700 (PDT)

> includes bandwidth (and generally flat bandwidth, not usage) and also

Actually, bandwidth USAGE is frequently charged for in many parts of the
world. In the US, it is common for small businesses to have flat rates or
included bytes sufficient to make the usage flat rate. Major last mile
providers also change a lot more when provisioning for static IPs and
presumed higher bandwidth consumption.

Every colocated or shared server agreement I've investigated recently has
included bandwidth charges for exceeding the included usage. That applies
in spades to folks to provide datacenter cages.

In some parts of the world, even dialup customers have bandwidth changes.
Data costs in some third world countries can be many times that of the US.

Dave Morris

---

From: Jeroen Massar <[email-masked]>
Date: Sun, 19 Aug 2007 12:08:37 +0100

Tony Li wrote:
> End-users are assigned an end site assignment from their LIR or ISP. The
> exact size of the assignment is a local decision for the LIR or ISP to
> make, using a minimum value of a /64 (when only one subnet is
> anticipated for the end site) up to the normal maximum of /48, except in
> cases of extra large end sites where a larger assignment can be justified.

Thanks for quoting exactly the correct portion as that part exactly
explains what the ISP is supposed to do. Except that the boundary here
is worse than what is being proposed, the boundary in the above case is
/64 - /48. For instance /128 is not allowed to be assigned to an
end-user. They will have to provide at least a /64, but as not "exactly
one subnet is anticipated for the end site" they will have to provide
more than that single /64.

As the proposal currently on PPML has, it tries to standardize the size
of the prefix actually given away. In IETF talk the 'rule' has always
been /128 if only one IP, /64 for a single subnet, /48 for anything else
(see the architecture RFC's). Proposed now is to add a /56 for home-user
sites, and 2 other prefix sizes (which IMHO are a bit overdone).

> Sorry, ISPs charge based on providing a *service*.  Yes, that includes
> bandwidth (and generally flat bandwidth, not usage) and also other
> components (DHCP, addressing, DNS, email, web hosting, spam filtering,
> etc).

Strange that many ISPs charge *specifically* for more IPv4 addresses.

But that is IPv4 addresses, I hope that the RIR's can make very clear to
the ISPs in question that they are getting a IPv6 /32 based on the mere
fact that they can then assign /48's to their endusers.

Someone mentioned the Comcast case, unfortunately for those users,
Comcast clearly only has the intention of using the /32 for provisioning
the CPE's, they won't be providing /48's from that block. If they where
going to do that, they really have to go back to ARIN and request
something in the vicinity of a /20, as that would actually cover the x
million customers they have.

Greets,
 Jeroen

---

From: <[email-masked]>
Date: Sun, 19 Aug 2007 22:54:45 +0100

> "ARIN ... belives IPv6 addresses are ... resources that need 
> to be [distributed] according to need."
> 
> I guess I have to agree with this sentiment.  If the ARIN 
> community decides there is a better way to distribute IP 
> addresses *OTHER THAN* need, I'd be really happy to hear what 
> that method would be.

That method would be to distribute IPv6 addresses (which are not scarce)
in accordance with the IPv6 addressing architecture which allows for
every site (building/campus/office/place-of-business/home) to get a /48
assignment. This single assignment will last 99.9999% of them as long as
IPv6 exists. It allows for ISPs/ANS-holders to receive a single /32 or
shorter prefix which will only put a single entry in the global routing
table.

A bit oversimplified, but you get the idea. There is an overall
architecture which IS DIFFERENT FROM IPv4 and which actually helps limit
the growth of the global routing table.

--Michael Dillon

---

From: <[email-masked]>
Date: Sun, 19 Aug 2007 23:14:20 +0100

> Could you please site chapter and verse?  Here's what I can find:

I quoted a formal proposal which has just been announced but which does
not yet have an official proposal number in the ARIN Policy Proposal
Archive. I believe this proposal met the deadline for discussion and
voting at the ARIN meeting in Albuquerque in October 2007.

But my point remains, it is very hard to find a definitive statement of
what the IPv6 addressing architecture is. At minimum, the IETF really
should have an RFC to give guidance to the RIRs on IPv6.

--Michael Dillon

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 20 Aug 2007 15:16:26 -0700

I do not believe that it is difficult to design fire and forget systems for the home. The problem is not design, it's the politics.

Apple has gone a long way towards doing just that, and they have brought a lot of manufacturers with them. They have approached the problem with a more feasible political approach than other attempts.

The usability issue is serious but not insurmountable. I have made my own proposal for dealing with this issue in my ID Domain Centric Administration:
http://www.ietf.org/internet-drafts/draft-hallambaker-domain-centric-00.txt

Since writing that draft I realize that an area that I need to work on further is to provide a standard means of creating self signed certs or locally issued certs for devices that do not come with an installed device certificate (this is already standard for DOCSYS cable modems).

I currently have eight machines hanging off the home network. What I am currently trying to do is to work out how to cluster three separate home networks at three different sites so that the cousins/granchldren and grandparents can all use video conferencing. This turns out to be a much harder task than it needs to be. There seems to be an omerta amongst the suppliers of videoconferencing type applications that none of them will reveal the protocols they use or the ports and if they will reveal the ports they will insist on sitting on the same port that my VOIP service uses.

But I suspect that in five years time I will have at least fifty IP addressable devices, hopefully more. For a start I want every lightswitch to be IP connected, and the burglar alarms and the individual phone handsets. Also the heating/AC systems and the hot tub. I also want my digital cameras to automatically upload pictures when I enter the house and I want all data storage on all the machines on the house to be constantly and transparently backed up both onsite and offsite (none of your daily backups rubbish, I want the data backed up while the original is written).

It is all do-able with technology we have in place today. A reviewer of my book just told my publisher that what I propose is nothing new or original. Which means that either the reviewer is wrong or we should not have any difficulty getting it on the shelves for next Xmas.

Apparently at MBA school the students are taught that markets for technology go through a series of phases. In the first phase merely delivering technology is enough, once basic functionality is delivered the market competes to provide usability, next comes reliability, eventually the market is driven by fashion. 

This happened in the auto industry. Early cars barely worked at all, every journey was an adventure. In the 1920s Ford broke the automobile patent and built a car for the common man, a car that did not need the skills of a mechanic to drive. Reliability improved gradually until the 1970s when there was a sudden realization that consumers would pay more for a car that was not designed to rust. Today most cars will go 10,000 miles between services and not need major repairs beyond a clutch plate for 50,000 or even 100,000 miles.

A lot of network technology, particularly security technology has only just emerged from the technology delivery phase. Instead of waiting ten years between phases why not just deliver it all now and give the MBA graduates a shock?

We have all the technology we need, all we need to do is to recognize that in the network of the future there can be no network administrators who spend their time doing the footling tasks that eat 90% of a network managers time today. We can't have real home networks happen until network administration is automated at the same level that the functions of the car are today.

> -----Original Message-----
> From: Steven M. Bellovin [mailto:[email-masked]] 
> Sent: Friday, August 17, 2007 8:54 PM
> To: Joel Jaeggli
> Cc: Keith Moore; [email-masked]
> Subject: Re: IPv6 addresses really are scarce after all
> 
> > wireless voip handsets or dual mode wifi/cellular phones building 
> > control and security systems that plug into ethernet or hang out on 
> > your wifi vlan capable managed switches that cost $150
> > 
> I'm not sure what your point is -- I took Keith's comment to 
> mean that home NATs with v6 were completely unacceptable.
> 
> I agree with you on the desirability of home routers, though 
> it's going to be an interesting challenge to build "fire and 
> forget" boxes for the house.  Of course, I'm the kind of guy 
> who already has 3 (and sometimes
> 4) segments on my home LAN, so I suppose I really need home 
> routers that speak OSPF....
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 20 Aug 2007 15:16:26 -0700

---

From: Thomas Narten <[email-masked]>
Date: Fri, 24 Aug 2007 17:34:36 -0400

Some background and history.

The IETF gave it's view on where the boundary for IPv6 blocks to end
sites should be (i.e., the /48 recommendation) in RFC 3177 back in the
2000-2001 time frame.

At that time, there were plenty of folk in the IETF that thought the
IETF could/should set address policy, notwithstanding fact that the
RIRs were doing that for IPv4.

RFC 3177 was a way for the IETF to make a recommendation to the RIRs,
without stepping on RIR toes (too much). Note that it is only a
recommendation, and the RFC is informational.

The fact is, the /48 boundary is _NOT_ architectural, and saying it is
doesn't make it so. I challenge anyone to find a standards track
document that relies on /48 being part of the architecture. (And you
might want to have a look at
http://tools.ietf.org/id/draft-narten-ipv6-3177bis-48boundary-02.txt
as it does mention a couple of related things.)

What the appropriate size of an assignment for an end site should be
is really more of an operational issue than architectural one. If a
site gets too little, and needs to get more later (maybe at the cost
of renumbering) that is an operational issue. And the idea that we can
give out "enough" address space to a site so that it doesn't have to
renumber (ever) is pretty silly. After all, most end sites will need
to renumber when they switch providers. Surely, we hope/expect a large
number of such provider switches to take place over a 5 or 10 year
period anyway?

The RIRs adopted the "/48 to everyone" in its initial stab at IPv6
policy back in 2002. Even at that time, there was much screaming and
gnashing of teeth from the operator community saying "wasteful",
"excessive", "really stupid", etc. So, even though all the RIRs
adopted the policy anyway, the unhappiness with /48 (as a general
recommendation) didn't go away, and was repeated often at subsequent
RIR meetings...

Then, 2-3 years ago, RIPE made some really really big IPv6 allocations
to a few ISPs. This raised eyebrows, because it raised the question
that if so much space could legitimately be given out (and it was much
much more than the operators would have been given for the same number
of IPv4 customers), it was conceivable to imagine scenarios in 50-100
years where the IPv6 free pool was signficantly used. As one Cable
Modem operator explained it to me:

      If I assign 4M /48's of IPv6 (one to each cable modem on my
      network), according to the HD-ratio I am justified to obtain
      something around a /20 of IPv6 addresses.  In other words, I am
      justified in getting 268M /48's even though I am only using 4M of
      them.  That would be enough for me to assign at least two for
      every household in the US (not just the 19M on my network).

      Now if all the cable providers (e.g., Comcast, Cox, Adelphia,
      Cablevision, Time-Warner, etc.) did the same for their networks;
      and each of the DSL companies made a similar move (SBC, Verizon,
      Quest, etc.); perhaps we could easily see the broadband market in
      the US alone obtaining some 16 /20's of IPv6 or a total of /16.
      There are only 8192 of those available in the current global
      unicast space of 2001::/3.

      Anyhow, you can see where this might lead...

This led to a bunch of discussions and policy proposals in the RIRs,
culminating with the adoption in ARIN, RIPE & APNIC of recommendations
that adjusted the HD ratio thresholds and moved away from "/48 for
everyone", making it an ISP (or LIR in RIR terminology) choice. The
community feedback was that LIRs were smart enough to make reasonable
assignments based on actual customer need.

If one does the math, giving every home user a /56 instead of a /48
provides almost two orders of magnitude more headroom in terms of
address usage. And at what cost? Surely, everyone will agree that
giving a /56 to home sites is more than enough space for the foresable
future! That's enough for 256 subnets per home site! That's an
incredible amount of address space!

(I have a really hard time reconciling the previous paragraph with the
subject of this thread.)

It is worth noting that there are no _firm_ recomendations in the
current RIR policies (in the sense of saying you must give home users
a /56) , because in discussions at ARIN and APNIC in particular, there
was pushback from the operations folk on being to prescriptive. They
argued that they are in the best position to decide reasonable
assignment sizes and wouldn't support more rigid guidelines. That
leads me to doubt that the specific propoasl that was mentioned that
started this thread will actually get much traction within ARIN, but
that is not my problem. :-)

Folk should note that a policy proposal submitted to an RIR is not
unlike an individual submission "submitted" to the IETF.  Best to
treat it as such. YMMV.

I find the fact that RFC 3177 has not been revised to reflect the
reality of today is a bit disapointing. Even in some of the messages
of this thread, I sense denial about the proper/actual role the IETF
plays in setting address policy. I see some of the same people arguing
here that /48 should not be changed, despite having made the same
arguments on RIR lists and having lost... There is water under the
bridge here folk...

The reality is that "/48 for everyone" has been overcome by events. If
you don't like that, take it to the RIRs.

And, FWIW, I was one of those that pushed for the changes.  As one who
originally supported of the /48 recommendation in RFC 3177, I think it
was a mistake. Giving a /48 to every home user by default is simply
not managing the address space prudently. Home users will do more than
fine with a /56.

Thomas

---

From: Tony Li <[email-masked]>
Date: Fri, 24 Aug 2007 14:53:02 -0700

> Anyhow, you can see where this might lead...

All practical address spaces are finite and thus must be used  
conservatively.

Tony

---

From: Lyndon Nerenberg <[email-masked]>
Date: Fri, 24 Aug 2007 15:04:42 -0700

> All practical address spaces are finite and thus must be used  

Platitudes aren't particularly useful.

How many bits wide is a practical? And why?

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Aug 2007 18:16:43 -0400

> document that relies on /48 being part of the architecture.
Well, I challenge anyone to find an IETF standards track document that
clearly separates architectural layer design from other layers of
design.  It's not like we make the distinction clear in our writing. 
That doesn't mean that it isn't meaningful to talk about such things.

The fact is, the /48 boundary was chosen in light of a variety of
technical concerns, just like any other aspect of the protocol design. 
There were several reasons why it was argued that it should be a
constant.  The RIRs are not in a position to second-guess this design
decision and certainly not to delegate it to ISPs, who represent only a
narrow range of the myriad interests affected by this decision.  If the
decision is to be revisited it needs to be done in IETF where the other
IPv6 protocol design decisions were made, and where a wider variety of
interests can be considered.
> unlike an individual submission "submitted" to the IETF.  Best to
duly noted.
> reality of today is a bit disapointing.
"reality of today" seems like an odd concept when trying to make or
revisit design decisions that will need to serve us for decades.  I keep
seeing people making the same mistake of trying to design the future
Internet to meet only the needs of the current Internet.
>  Even in some of the messages
> plays in setting address policy.
Who is to say what is proper, or what is denial?  Address policy, or at
least some aspects of it, is an inherent part of the design of IPv6.  
The RIRs have no more business changing the /48 constant than they would
have, say, reassigning PA prefixes as PI prefixes.
>  I see some of the same people arguing
Frankly I think that statement is out of order.  The RIRs need to be
taking it to IETF.

Now I'm all for prudent use of IPv6 space, and if the /48 needs to be
changed to /56 or some other value, then by all means let's have the
discussion here.  But the discussion belongs here, not elsewhere.  IPv6
is a lot of delicately crafted compromises, and it's not as if these
compromises were made independently of one another.   Changes like this
can have unintended consequences, and these need to be understood and
examined.  RIRs are not in a position to do this.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Aug 2007 18:46:09 -0400

6to4 assigns a /48 IPv6 prefix (within 2002://16) to any host or site
with a global IPv4 address.  The length of this prefix was chosen to be
the same as the size of a native prefix that was to be allocated to
sites, in order to ease coexistence of 6to4 and native IPv6 and/or
transition from 6to4 to native IPv6.  If the normal site prefix
allocation had been /56 or some other value, we would have given serious
consideration to making 6to4 prefixes be the same length.

6to4 is now widely deployed and ships with every major operating
system.  It's a bit late to change the length of its prefix.  But now
sites that deploy 6to4 will have some disincentive to move to native
IPv6 (or to delay doing so) in that their pain in transition will be
even greater than before.

The /48 prefix length is not just some knob that RIRs or ISPs can turn
at their will.    It's a constant that's embedded into 6to4 protocol
implementations in tens or hundreds of millions of computers.  That
doesn't mean that /48 can't be reexamined, but it does mean that it's
not the RIRs or ISPs business to be making that decision.

I keep getting the impression that the biggest barrier to the success of
IPv6 is that so many people have screwed with the design of IPv4 that
they think they have the right to screw with IPv6 too.

Keith

---

From: Thomas Narten <[email-masked]>
Date: Fri, 24 Aug 2007 19:38:34 -0400

> consideration to making 6to4 prefixes be the same length.

The document I cited in my previous note says (on this topic):

4.1.  RFC3056: Connection of IPv6 Domains via IPv4 Clouds

   RFC3056 [RFC 3056] describes a way of generating IPv6 addresses from
   an existing public IPv4 address. That document describes an address
   format in which the first 48 bits concatenate a well-known prefix
   with a globally unique public IPv4 address. The "SLA ID" field is
   assumed to be 16 bits, consistent with a 16-bit "subnet id" field. To
   facilitate transitioning from an RFC3056 address numbering scheme to
   one based on a prefix obtained from an ISP, an end site would be
   advised to number out of the right most bits first, using the left
   most bits only if the size of the site made that necessary.

   Similar considerations apply to other documents that allow for a
   subnet id of 16 bits, including [ULA-ADDRESSES].

> 6to4 is now widely deployed

Is it? Can you cite any data?

> and ships with every major operating system.  It's a bit late to
> change the length of its prefix.  But now sites that deploy 6to4
> will have some disincentive to move to native IPv6 (or to delay
> doing so) in that their pain in transition will be even greater than
> before.

6to4 is a transition technique that I would argue is not really
appropriate for a large site (i.e, one with _many_ subnets). A large
site almost certainly will seek a more proper IPv6 connection to an
ISP. Yet, it is only large (multi-subnet) sites that will have
problems with having used all 16 bits for subnet addressing and then
moving to something with less. And if the site really was using 16
bits of subnet addressing, I expect their ISP would give it to them.

But again, I ask, just how widely deployed is it? The people I talk to
don't seem to think it is. I really don't think there is a problem
here in practice.

> implementations in tens or hundreds of millions of computers.

Give me a break. Use leading zeros for the first 8 bits of the subnet
part and everything else still works just fine.

> That doesn't mean that /48 can't be reexamined, but it does mean
> that it's not the RIRs or ISPs business to be making that decision.

Um, Keith, it _is_ the RIR's business. This is what they do. They did
it for IPv4 and they are doing it for IPv6. If you have an issue with
this, you are at least 5 years too late.

> they think they have the right to screw with IPv6 too.

The biggest barrier to the success of IPv6 is the lack of a short-term
ROI. There just isn't a strong business case for anyone to invest in
deployment. It's really that simple.

It continues to amaze me what rationals people can come up with for
why IPv6 hasn't been more widely deployed. We need just one more
transtion technique. RIRs need to give addresses away for free (oh,
wait, they've already tried that), etc., etc.

Bottom line: when the pain of IPv4 (with increasingly scarce/costly
addresses) and NAT exceeds the pain of deploying IPv6, we'll see
deployment.

Thomas

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Aug 2007 20:11:25 -0400

> Is it? Can you cite any data?

Well, it ships with Windows, MacOS X, and Linux, and has for some time. 
Vista enables it by default if it doesn't see an RA for an IPv6 prefix.
What more evidence do you want?

Of course, widespread use can be expected to lag widespread deployment,
but lack of visible widespread use is no excuse for breaking recently
deployed code that appears to be useful.
> appropriate for a large site (i.e, one with _many_ subnets).
Because relay routers don't work as well in practice as we'd like, a
large site might find it advantageous or even necessary to support 6to4
in addition to a native prefix.  Though I think this is probably
irrelevant to the current discussion as large sites can presumably still
get /48s.
> part and everything else still works just fine.
So a router that automatically divides up that /48 according to requests
from interior routers, should also assign zeros those bits?  How many
more things does this affect?
> this, you are at least 5 years too late.
No, Thomas, this is part of the protocol design, not merely an
assignment of addresses.  We had that discussion when the /48 prefix was
chosen, and the objection was raised at the time that this was the RIR's
scope.  It wasn't true then and it isn't true now.  Just because the
RIRs might think it is their business does not make it so.

It really amazes me when people in IETF claim that we'd be stepping on
toes by objecting to things done by others that contradict our protocol
designs and/or do harm to the efficacy of our protocols.  That's not
stepping on toes, that's our job.
> deployment. It's really that simple.
That's a bit like saying that there's no strong case for hitting the
brakes on a car just because the end of the road is in view and it
appears to end at the top of a cliff.

But really there's a short-term barrier and a long-term barrier.  We
might get past the short-term barrier only to find out that IPv6 is
every bit as screwed up as IPv4 was, because people kept trying to
impose brain-damage that was adopted in IPv4, onto IPv6.

Keith

---

From: Bob Hinden <[email-masked]>
Date: Fri, 24 Aug 2007 17:22:57 -0700

Thomas,

A few additions to your description of how we got to where we are now  
email.

RFC3177, where the /48 recommendation was made, used the H ratio  
analysis to explain why a /48 was acceptable.  However the IETF did  
not make any recommendation to the RIRs that the H ratio (current  
version is now called HD ratio) should be used by the RIRs in their  
allocation process nor what specific HD ratio be used.  These choices  
were made the RIRs when they developed their IPv6 allocation policies.

In my view the potential problems you describe have more to do with  
the specific HD ratio the RIRs choose to use as opposed to the /48.   
It's my understanding the HD-ratio value that the RIRs are now using  
is much more conservative than before.  This should, as I understand  
it, avoid the overall problems you describe (e.g., cable modem, DLS,  
etc.).

While I agree that 64K subnets is a lot of subnets for a home user,  
my reluctance to formally change the /48 recommendation is that it  
will lead to much more restrictive allocation policies.  Just like  

> * /48 - Site with 16+ subnets initially.

If this is what we would expect to get by changing the RFC3177  /48  
recommendation, then in my view is not a good idea.

Bob

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 25 Aug 2007 11:36:29 +0900 (JST)

i suggest ietf.org mail server to operate in IPv6 only.

> Is it? Can you cite any data?

	- Apple MacOS X implements it.  i'm not sure which release started
	  shipping it, but if it was from 10.2, there are 22 million copies
	  around, with IPv6 enabled by default.
	- Apple AirPort Exterme implements it.

> part and everything else still works just fine.

	so if you are running 6to4 enterprise (/48) and then get some prefix
	from ISP/RIR which is like /56, you would have to renumber entire
	subnet portion to fit into 8 bits, from 16 bits.  imagine how
	painful it is, and imagine how it will constrain people from
	exiting from 6to4 addresses to real IPv6 addresses.

itojun

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 25 Aug 2007 08:57:21 +0200

Agree. I much prefer to stay with the /48. 256 subnets may be too low for
some customers, I've seen this situation already, and then it is difficult
to go back to the ISP for more, extra cost for everyone. We should go away
of the restrictive mind set that we have with IPv4.

Indeed, if we want to be more restrictive, I will much prefer to change the
HD-ration again in the existing policies.

Regards,
Jordi

> De: Bob Hinden <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Fri, 24 Aug 2007 17:22:57 -0700
> Para: Thomas Narten <[email-masked]>
> CC: <[email-masked]>
> Asunto: Re: IPv6 addresses really are scarce after all
> 
> Thomas,
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 25 Aug 2007 14:15:32 +0200

[CCing this to ARIN PPML and RIPE address-policy, but Reply-To:  
[email-masked], when replying, please pick just one list. Also, please  
read Thomas' entire original message at http://www1.ietf.org/mail- 
archive/web/ietf/current/msg47431.html ]

[You may want to skip ahead to my point about the HD ratio at the end.]

On 24-aug-2007, at 23:34, Thomas Narten wrote:

> The fact is, the /48 boundary is _NOT_ architectural,

True. However, this doesn't mean that /48 is completely arbitrary,  
either. /64 for subnets is based on the availability of 64-bit unique  
numbers in the form of MAC addresses that make it possible to have  
stateless autoconfiguration where a system always has the same  
address without the need for explicit coordination or configuration.

People often attribute the fact that IPv4 addresses didn't run out in  
2005 as predicted in the early 1990s to NAT, but there is another  
technique that is even more popular than NAT that also played in  
important rule: ethernet switching. Back when IPv6 was designed, it  
was common to have a substantial number of different subnets for  
different purposes to avoid having unnecessary large "collision  
domains". These days, you can easily throw hundreds, if not thousands  
of systems in a single subnet without performance penalties so most  
networks don't need all that many subnets. So the original goal of  
providing something a number of subnets that is large enough for  
99.9% of all IPv6 users arguably required a /48 (65536 subnets). With  
2000::/3 given out for global unicast purposes, that allows 2^45 / 
48s, which should be more than enough to give all inhabitants of the  
planet their own /48 with a few to spare.

So a /48 is both big enough for pretty much everyone, and small  
enough that we can give one to pretty much everyone. Last but not  
least, it's very useful to have a standard size, because then, if you  
go from one ISP to another, you're never in the situation where you  
need to renumber into a smaller block of address space, which is  
much, much harder than just replacing the first X bits of the address  
(where X is presumably 48). This was especially true in the presence  
of DNAME and bitlabels in the DNS. For those of you that don't know  
about this, it's rather complex and now obsolete, but around the turn  
of the century, this was a hot new mechanism to support easy  
renumbering in the DNS. (Read about it here http://www.apress.com/ 
book/supplementDownload.html?bID=10026&sID=3120 but don't say I  
didn't warn you.)

So /48 was certainly "a good idea at the time". If we were doing all  
of this today, we could probably go a bit lower than 65536 subnets,  
such as 4096, but not THAT much lower. For instance, 256 subnets (/ 
56) is still a very large number, so it assumes that people will be  
subnetting, but I'm not confident that it's enough for 99.9% of all  
future IPv6 users.

Another issue is what we give to people who aren't going to build a  
network with subnets. The old recommendation was a /64 (= 1 subnet)  
for users who don't need to subnet. But unlike with IPv4, where end- 
users often get a single IP address and turn that into a subnet with  
NAT, with IPv6 you pretty much always need TWO subnets, although one  
of them can be shared. For instance, if I want to connect a bunch of  
computers in my home to my DSL line with IPv6, I need a /64 on my  
wifi network at home, but it's not really possible to use addresses  
from that same /64 between my ADSL modem and the DSL concentrator at  
the central office. As an ISP, I could set up one /64 to talk to all  
the DSL modems connected to a central office and then delegate a /64  
to each user, but this is problematic for technical reasons  
(broadcasts/mulsticast vs NBMA) and control issues (which user does  
traffic from an address in that shared /64 come from).

So if I were designing an ISP network, I would want to give at least  
two /64s or a /63 to every customer. In practice, it's much easier to  
go up a few bits and make it a /60, where I use one /64 for the SIP- 
customer link and the customer gets to use the other 15 subnets  
however they want. This way, I avoid getting support calls from  
people who want to have an extra DMZ subnet or different subnets for  
their wired and wireless networks.

Again, as an ISP, I wouldn't want to think about how many subnets  
customers are going to use when they need more than that /60. Much  
easier to simply sell them a business account and give them a /48.  
Remember, every time a simple residential customer calls the support  
number, that costs an ISP the entire profit for that customer for a  
year. Avoiding support calls is one of the highest priorities for ISPs.

> renumber (ever) is pretty silly.

That doesn't mean it's impossible to pick sizes that are worse than  
others. And even though we have reverted back to simple use of the  
DNS with IPv6 where having the same address block size when going  
from ISP to ISP is less important, it's still beneficial to have as  
few block sizes as possible to that people don't have to go from big  
to small.

> "excessive", "really stupid", etc.

The wastefulness occurred when the IPv6 address size was set to 128  
bits. This means that every IPv6 packet has to carry 32 bytes of  
address information. Now that we've eaten that cost, there is little  
use in trying to _use_ fewer of those bits that we're paying for with  
every packet.

I can see how "/48 for everyone" could be considered too much  
(although 35184 billion of those aren't going to be used up any time  
soon) but can we at least retain "/48 for everyone who asks for one"?

>       every household in the US (not just the 19M on my network).

Yes, this is a problem that the current policies, including the  
unofficial ones (for instance that ARIN reserves a /29 when an ISP  
gets a /32) don't address.

Suppose a large ISP that operates across the US or Europe gets that / 
20. So how are they going to announce that, as a single /20? I don't  
think so. They're going to deaggregate. And they can easily do that,  
because their block is much larger than the minimum /32 block that  
people are presumably going to be filtering on.

In the degenerative case, which we can already see in IPv4, ISPs  
simply announce whatever they have as the smallest possible  
announcement. So that ISP that needs 4 million /48s = 64 /32s but  
gets a /20 = 4096 /32s COULD advertise 4096 prefixes because the RIRs  
thought they would need to aggregate, while if the RIRs assumed that  
they wouldn't aggregate, they would have gotten the space in the form  
of a number of much smaller blocks and they would only have been able  
to announce 100 or so /32s.

A much more appropriate policy would be to start with a certain  
minimum allocation, and then whenever someone comes back for more,  
give them a new block that is 2, 4 or 8 times as big as the previous  
block until a certain maximum block size is reached. For aggregation  
purposes, there is no benefit in having blocks larger than a /24,  
because by the time that a significant portion of the the IPv6 space  
ends up in the routing tables, having 2^24 routes won't be a problem.

> The

The trouble is that even more so than at the IETF, the RIR community  
as seen from the policy development process is whoever happens to  
show up. This means only a small part of all stakeholders provide input.

> Surely, everyone will agree that
> future!

If /48 is too much for home sites then /56 is too much as well.

---

From: Christian Huitema <[email-masked]>
Date: Sat, 25 Aug 2007 08:28:18 -0700

>From an architecture point of view, I believe there are only two
interesting "delegation" lengths, /48 and /64. My rationale is that
there really are two kinds of networks: big and small. 

The definition of a small network is pretty much "single subnet". Yes, I
understand very well that the average home of the future will have a
mixed wiring. Of course, my own home does have Ethernet and Wi-Fi. In
the not so distant future, it will have several Wi-Fi networks operating
on different frequencies, some form of power-line networking, and some
rooms may have their own high speed wireless wiring using UWB or some
similar technology. But I am pretty much convinced that all of these
will be organized as a single subnet.

There are multiple trends pushing for the simple subnet. Most home
networking technologies have a deeply engrained "single subnet"
assumption, and will simply refuse to establish connections out of the
subnet. Wireless technology is evolving towards "mesh", in which the
wireless segments are bridged on demand following the vagaries of radio
propagation and the movements of devices. Mesh pretty much assumes that
the IP address remains unaffected by low level topology changes, which
means a host will not change subnet because it just switched to a
different radio. Users will keep finding it easier to deploy self
forming layer 2 networks than manage the additional complexity of
subnets. 

Of course, the technology has limit today. Subnet sizes are limited by
the efficiency of the spanning tree algorithm, or by the quadratic
scaling effect of multicast operation. But these limits can be pushed.
The spanning tree algorithm can be replaced by something more efficient,
and indeed will be as the "mesh" technology evolves. Multicast overhead
can be reduced with appropriate filters. It can also be reduced if
applications switch from simplistic multicast schemes to more elaborate
technologies, e.g. distributed hash tables. These evolutions will be
naturally driven by market demand, as homes get equipped with more and
more devices, all the way to the "IPv6 light bulb".

The single subnet is well served by a /64 prefix. Devices can be built
in factory with unique /64 numbers. When there are privacy issues, hosts
can pick random 64 bit numbers and not be really worried about
collisions, at least not until there are billions of hosts in the
subnet. Of course, the home may well get several /64 prefixes, for
example because it is multi-homed. But there is no particular need to
aggregate these prefixes. Indeed, if the goal is multi-homing, the
different prefixes will come through entirely different delegation
chains.

If the granular level is /64, then what should the next level be? Well,
as far for now, /48 makes a lot of sense. It is enough for most
enterprises, allowing them to delegate /64 to each interesting subnet. I
would assert that the smaller value, /56, is too small. It is not
sufficient in most cases, and it also unduly increase the registration
load in the registries.

-- Christian Huitema

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Aug 2007 12:27:31 -0400

--On Friday, 24 August, 2007 17:34 -0400 Thomas Narten
<[email-masked]> wrote:

> The IETF gave it's view on where the boundary for IPv6 blocks
> to end sites should be (i.e., the /48 recommendation) in RFC
> 3177 back in the 2000-2001 time frame.
> 
> At that time, there were plenty of folk in the IETF that
> thought the IETF could/should set address policy,
> notwithstanding fact that the RIRs were doing that for IPv4.
> 
> RFC 3177 was a way for the IETF to make a recommendation to
> the RIRs, without stepping on RIR toes (too much). Note that
> it is only a recommendation, and the RFC is informational.
> 
> The fact is, the /48 boundary is _NOT_ architectural, and
> saying it is doesn't make it so. I challenge anyone to find a
> standards track document that relies on /48 being part of the
> architecture. (And you might want to have a look at
>...

Thomas,

Let me suggest a slightly different perspective on this.

First, the decision as to how large to make the IPv6 address
space is, and was, an architectural decision.  We could have
chosen a longer length, we could have chosen a shorter one, we
could even have made it variable length (with or without a
fixed-length or maximum-length network part).   As others have
pointed out, we could have taken explicit measures to separate
IP-level addressing from routing as a fundamental part of that
architecture.   All of those options were considered (although
some a lot more carefully than others). 

Whether it is obsolete or not, and, if it is, whether because of
hardware or security considerations, the belief that local
networks needed to have 64 bits available for MAC address
mapping were also part of that picture.   Again, certainly an
architectural decision rather than "pure policy". 

Whether it was explicit or not, assumptions about the effective
size of that address space -- how many sites or "networks" it
could serve -- were also part of those architectural decisions.
I remember a whole series of discussions about whether N bits
(for various values of N) were enough under various scenarios.
We might not have gotten those decisions right, but they were
IETF decisions and decisions made as part of determining what
IPv6 looked like.

Second, the notion that RIRs set addressing policy is one that
has not been in place forever.  Indeed, it has evolved very
slowly and mostly by assertion by the RIRs that they have that
authority --assertions that, in other contexts, might look a lot
like either filling a vacuum or turf grabs depending on one's
perspective.  While they have always (since there have been
RIRs) had broad discretion within their own regions, and it has
always been recognized some coordination discourages
forum-shopping and other bad behavior, global address policy was
historically set by IANA in conjunction with the IAB, not by the
RIRs (although I assume their advice was certainly welcomed).

Without taking any position on whether the ARIN decision is a
reasonable one, I believe that the IETF has had, and continues
to have, a role in the general design of addressing
architectures and hence in allocation strategies.  I also
believe that the RIRs have some obligation to consult the IETF
before making a major policy change and to pay careful attention
to anything rational the IETF has to say.  I also believe that
things are seriously out of joint if we need to worry about
whose toes are being stepped on before opinions are expressed.

     john

---

From: Keith Moore <[email-masked]>
Date: Sat, 25 Aug 2007 12:28:07 -0400

/64 is too small for a home network.  It might indeed turn out that it's
possible to bridge several different kinds of media on a single subnet,
but it's bad planning to assume that this will be the case and overly
constrain home users.  In addition, part of the popularity of NAT has
resulted from its allowing a consumer to simply "plug in" a new network
to an existing network.  But the popularity of NAT in IPv4 has also
greatly limited the ability of the IPv4 network to support new
applications, and increased the expense required to support others.  A
lot of the value add in IPv6 results from its having enough address bits
that NAT is no longer necessary.  But if we constrain home users to the
point that they see a benefit from NATting, we will have destroyed much
of the additional value of IPv6.

The /48 boundary was selected to balance several competing interests -
e.g. those of ISPs and registries vs. those of end-users and equipment
manufacturers.  There's a tremendous advantage in having nearly everyone
get the same allocation size.  This is not a decision that should be
revisited lightly, or by a group representing only a narrow segment of
those interests.

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Aug 2007 12:47:52 -0400

--On Saturday, 25 August, 2007 12:28 -0400 Keith Moore
<[email-masked]> wrote:

> /64 is too small for a home network.  It might indeed turn out
> that it's possible to bridge several different kinds of media
> on a single subnet, but it's bad planning to assume that this
> will be the case and overly constrain home users.  In
> addition, part of the popularity of NAT has resulted from its
> allowing a consumer to simply "plug in" a new network to an
> existing network.  But the popularity of NAT in IPv4 has also
> applications, and increased the expense required to support
> others.  A lot of the value add in IPv6 results from its
> having enough address bits that NAT is no longer necessary.
> But if we constrain home users to the point that they see a
> benefit from NATting, we will have destroyed much of the
> additional value of IPv6.

Keith,

Will all due respect, even if you assume a "home" with ten
occupants, a few hundred subnets based on functions, and enough
sensor-type devices to estimate several thousand of them per
occupant and a few thousand more per room, 2**64 is still a
_lot_ of addresses.   Now that number goes down significantly
--and I would agree with your assertion-- if we were still
assuming the use of hardware-assigned MAC addresses to populate
that space.  But we largely are not.

The use of NAT to expand address space in residential use of
IPv4 has been largely to expand one or two addresses into around
2**16.  Even those of us who run several subnets with different
security policies don't often use that much space up.  While we
clearly could in the future, and I don't like NATs much more
than you do, a /64 gives 48 bits of headroom -- over a dozen
decimal orders of magnitude if my mental arithmetic is correct
-- above any regularly-demonstrated current need.   That is a
lot of headroom, enough that the assertions above are not
obviously true, at least without a lot more rationale.

That doesn't mean I'm convinced that shifting the boundary is
either necessary or desirable.  But I don't think hyperbole
helps the discussion.

     john

---

From: Keith Moore <[email-masked]>
Date: Sat, 25 Aug 2007 13:08:42 -0400

John C Klensin wrote:
> _lot_ of addresses. 
And 2**45 prefixes under 2000:/3 is a _lot_ of prefixes.  But the sheer
number of addresses in a subnet or prefixes available to be assigned
doesn't seem to be the limiting factor in either address block
assignment or subnetting of leaf networks.  Every level of delegation
seems to eat a couple of address bits.  

What bothers me about a /64 is not the scarcity of addresses, but the
inability to subnet it.  (and that, IMHO, was a poor design choice in
IPv6, but I think it's rather late to revisit that choice, just like I
think it's late to revisit /48.)
>   Now that number goes down significantly
If we changed IPv6 so that users can have subnet prefixes longer than
/64, I must have missed it.

> 2**16.
I guess I'm of the opinion that "residential" use is highly varied, and
will become more varied in the future.  I don't want Internet protocol
design choices to constrain what people might reasonably do in a future
home or home office.  I also don't think it should be assumed that
"residential" prefixes will exclusively be used in residences.  

Keith

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Aug 2007 13:41:09 -0400

--On Saturday, 25 August, 2007 13:08 -0400 Keith Moore
<[email-masked]> wrote:

>>> /64 is too small for a home network.  It might indeed turn
>>> out that it's possible to bridge several different kinds of
>>> media on a single subnet, but it's bad planning to assume
>...
>> occupants, a few hundred subnets based on functions, and
>> enough sensor-type devices to estimate several thousand of
>> them per occupant and a few thousand more per room, 2**64 is
>> still a _lot_ of addresses. 

> And 2**45 prefixes under 2000:/3 is a _lot_ of prefixes.  But
> the sheer number of addresses in a subnet or prefixes
> available to be assigned doesn't seem to be the limiting
> factor in either address block assignment or subnetting of
> leaf networks.  Every level of delegation seems to eat a
> couple of address bits.  

Yes.  Of course.  Again, I'm not convinced that this is a good
idea, just trying to keep the discussion focused and real.

> What bothers me about a /64 is not the scarcity of addresses,
> but the inability to subnet it.  (and that, IMHO, was a poor
> design choice in IPv6, but I think it's rather late to revisit
> that choice, just like I think it's late to revisit /48.)

This gets to one of the issues I _am_ concerned about.  While I
didn't call it out explicitly in my response to Thomas, I
believe that, if the RIRs start saying "give out /64s unless
someone can prove to your satisfaction that they need a lot of
subnets" to ISPs, we have ample evidence that some, perhaps
many, ISPs serving the residential market will construe "prove
to our satisfaction" as "pay us a lot of extra money".  If that
happens, our experience with IPv4 and NATs suggests to me that
it will be a _very_ short period of time before devices hit the
consumer market that either do subnetting on longer-than-/64
prefixes, are set up to handle some other model of address
pools, or NAT (I'd predict all three and would find the middle
one interesting) along with patches to stacks that support them
as needed.  

Since we probably won't revisit the /64 subnetting choice, those
patches will be made independent of any standard or IETF advice
which suggests that there may be interoperability problems if
there is any opportunity for them.

And _that_ is bad news.  It is also news that reinforces my
response to Thomas: there really are architectural issues in
this sort of decision and no one I know of has chartered the
RIRs to make those types of architectural decisions.

      john

---

From: Keith Moore <[email-masked]>
Date: Sat, 25 Aug 2007 13:54:01 -0400

John,

It seems like we are on the same page.  I'm very concerned about the
potential of this change to snowball in to lots of other changes that
would be undesirable, or at least highly disruptive.  The /48 choice is
only one of several interlocking choices that were carefully-crafted
compromises, and if we change /48 then we risk revisiting all of those
other choices in order to maintain that sense of balance - or worse,
losing that balance.

Keith

---

From: <[email-masked]>
Date: Sun, 26 Aug 2007 11:56:56 +0100

>       Anyhow, you can see where this might lead...

Yes, towards a rethinking of whether the HD ratio is an appropriate way
to measure the size of an ISP's second allocation.

> If one does the math, giving every home user a /56 instead of 
> a /48 provides almost two orders of magnitude more headroom 
> in terms of address usage. And at what cost? Surely, everyone 
> will agree that giving a /56 to home sites is more than 
> enough space for the foresable future! That's enough for 256 
> subnets per home site! That's an incredible amount of address space!

And since it is very rare for a home site to change into a non-home site
while under the same ownership/occupancy, the rule of /56 for home users
maintains the same-size-for-all philosophy that was suggested with /48
blocks. A home user can move across town to another residence, hook up
to another ISP and be reasonably guaranteed to get another /56.

> That leads me to 
> doubt that the specific propoasl that was mentioned that 
> started this thread will actually get much traction within 
> ARIN, but that is not my problem. :-)

Nevertheless, a lot of this controversy around IPv6 addressing is not
very well informed and is often based on IPv4 architecture, not IPv6.
There is a gap in education here, and due to the scramble to deal with
the imminent runout of IPv4 addresses, people don't have time to get
properly educated. This is a scenario in which informed guidelines from
the IETF would have great value even if they cannot be prescriptive.

> I find the fact that RFC 3177 has not been revised to reflect 
> the reality of today is a bit disapointing. 

Precisely! At one time the IETF put some effort into producing IPv6
educational material but that effort seems to have faded away.

> And, FWIW, I was one of those that pushed for the changes.  
> As one who originally supported of the /48 recommendation in 
> RFC 3177, I think it was a mistake. Giving a /48 to every 
> home user by default is simply not managing the address space 
> prudently. Home users will do more than fine with a /56.

I agree. What I don't agree about is the idea that /56's should go to
small sites, i.e. that the ISP makes some judgement about how many
subnets a business might need, and then decide whether or not to give
them a /48 or a /56. Technically, the ARIN policy wording allows for
this.

--Michael Dillon

---

From: <[email-masked]>
Date: Sun, 26 Aug 2007 12:03:35 +0100

> "reality of today" seems like an odd concept when trying to 
> make or revisit design decisions that will need to serve us 
> for decades.  I keep seeing people making the same mistake of 
> trying to design the future Internet to meet only the needs 
> of the current Internet.

Just to clarify, RFC 3177 discusses characteristics of IPv6 such as NLAs
and TLAs that have been deprecated. When a reader realizes that some of
the topic matter of this RFC is obsolete/deprecated, they are no longer
able to trust anything in the document.

Thomas is saying that RFC 3177 needs to be updated because of the
deprecated bits. And if this document is to be revisited then it could
include other material to become "IPv6 Addressing Guidelines for RIRs
and ISPs".

> Frankly I think that statement is out of order.  The RIRs 
> need to be taking it to IETF.

They would if it was clear that their activities were contrary to a
published RFC. The IETF must take the first step here and clarify
things.

> Now I'm all for prudent use of IPv6 space, and if the /48 
> needs to be changed to /56 or some other value, then by all 
> means let's have the discussion here.  But the discussion 
> belongs here, not elsewhere.  IPv6 is a lot of delicately 
> crafted compromises, and it's not as if these
> can have unintended consequences, and these need to be 
> understood and examined.  RIRs are not in a position to do this.

Agreed. But the working relationship between the RIRs and the IETF is
somewhat in tatters at present. An update of RFC 3177 would be a fine
first step to repair that relationship.

--Michael Dillon

---

From: <[email-masked]>
Date: Sun, 26 Aug 2007 12:20:01 +0100

> 6to4 is a transition technique that I would argue is not 
> really appropriate for a large site (i.e, one with _many_ 
> subnets).

I.e. one with a /48 allocation from an RIR. Therefore it would appear
that 6to4 is targeted at small sites such as home users who will likely
receive a /56 from the RIR. Therefore Keith's concerns are warranted.

> Give me a break. Use leading zeros for the first 8 bits of 
> the subnet part and everything else still works just fine.

Are you sure of that? Can you point me to a draft or RFC where this is
documented?

> The biggest barrier to the success of IPv6 is the lack of a 
> short-term ROI. There just isn't a strong business case for 
> anyone to invest in deployment. It's really that simple.

In two or three years, IPv4 network growth will be severely limited. Any
business whose revenue growth is linked to IP network growth, must use
IPv6 for this beyond two to three years from now. IN order to
successfully use IPv6 for the mission critical network growth that is
the engine of business revenue, they need to have at least a year of
trials and lab testing in advance. That means there is not much more
than a year before such businesses will have missed the boat. Some may
argue that Return three years from now on Investment made today is not
short term, and that is true. However, if the investment is not made
today, the platform for short term ROI will not exist in three years
time.

That does make a strong business case and some companies are busy
working behind the scenes to prepare for the disruption caused by IPv4
runout. For some, the disruptive event will be fatal and for others it
will be very profitable. This message will soon reach the investment
community so you will soon see investment analysts asking very tough
IPv6 deployment questions, and rating stocks appropriately. That is
definitely a short term ROI scenario for IPv6.

Think back to the days when the OSI protocols were expected to be the
next big thing, replacing IPX, DECNET, Appletalk and NetBIOS. IP was for
universities and labs. In telecoms, ISDN and ATM were the wave of the
future. This is the way things were in 1993. Two years later, in 1995 we
were experiencing exponential growth of the TCP/IP Internet. I believe
that it was something like 1500% growth in that year and dozens of new
books about the Internet came on the market joining the 3 books that
were on the market in 1994.

It is almost certain that IPv4 runout will drive a similar upsurge in
IPv6, although not quite the same magnitude.

--Michael Dillon

---

From: <[email-masked]>
Date: Sun, 26 Aug 2007 12:41:43 +0100

> The definition of a small network is pretty much "single 
> subnet". Yes, I understand very well that the average home of 
> the future will have a mixed wiring. Of course, my own home 
> does have Ethernet and Wi-Fi. In the not so distant future, 
> it will have several Wi-Fi networks operating on different 
> frequencies, some form of power-line networking, and some 
> rooms may have their own high speed wireless wiring using UWB 
> or some similar technology. But I am pretty much convinced 
> that all of these will be organized as a single subnet.

You are remarkably trusting. You do all your homebanking on the same
subnet as your teenage children who are studying Hacking 101 in the
privacy of their bedroom? And when guests come over for dinner, you have
no objection to them taking their laptop to the bathroom in order to
surf for child porn over your wireless network.

The fact is that a lot of people will WANT subnets in the home. They
will want a router/firewall that will isolate each of the children's
bedrooms so that they cannot mess with your bank account or with their
brother's/sister's romantic chat sessions. Many people will want all
wireless access to go through a router. Many will have an in-law suite,
and want to seamlessly integrate their relative's existing network via a
simple router connection. And the family jewels, that Raid 5 server
cluster that holds all the family photos and videos, will be behind
another router/firewall. When the kids host a LAN party, the gamers will
connect to the family network via a router/firewall with limited
Internet access for only the necessary protocols. Subnets multiply for
architectural and security reasons.

Multiple subnets per home is *NOT* a waste of anything. It is an
invitation to dreamers and inventors to make better network things for
the home market. It is an enabler of business activity, an enabler of
competition.

--Michael Dillon

---

From: John C Klensin <[email-masked]>
Date: Sun, 26 Aug 2007 09:07:59 -0400

--On Sunday, 26 August, 2007 12:41 +0100 [email-masked]
wrote:

> You are remarkably trusting. You do all your homebanking on
> the same subnet as your teenage children who are studying
> Hacking 101 in the privacy of their bedroom? And when guests
> come over for dinner, you have no objection to them taking
> their laptop to the bathroom in order to surf for child porn
> over your wireless network.
> 
> The fact is that a lot of people will WANT subnets in the
> home. They will want a router/firewall that will isolate each
> of the children's bedrooms so that they cannot mess with your
> bank account or with their brother's/sister's romantic chat
> sessions. Many people will want all wireless access to go
> through a router. Many will have an in-law suite, and want to
> seamlessly integrate their relative's existing network via a
> simple router connection. And the family jewels, that Raid 5
> server cluster that holds all the family photos and videos,
> will be behind another router/firewall. When the kids host a
> LAN party, the gamers will connect to the family network via a
> router/firewall with limited Internet access for only the
> necessary protocols. Subnets multiply for architectural and
> security reasons.
>...

Michael,

Assume we agree on the needed functionality.  It is hard to
disagree and many of us have seen the need to isolate some
people and apparatus from others, and to assign different
capability to them, for many years.

That still leaves room to ask several questions.  I believe
those questions need to be asked, and the relevant technical
work done.  And I think one needs to do that work and then
adjust address policy to match, not change address policy
without making corresponding technical/ protocol changes.

Examples:

(1) Unless it was changed when I wasn't looking, there is a rule
in  the IPv6 architecture that says that one cannot subnet on a
prefix longer than a /64.  That rule appears to be someone
hostile to efficient use of address space at the "small network
with subnets" side of things.  Has that rule outlived its
usefulness? If so, how do we go about changing it before IPv6 is
sufficiently widely deployed to make it even more difficult and
disruptive to do so?

(2) The many examples you give seem to be to be associated with
different domains of authorization and privilege for different
groups of people and functions within the home.  My impression
of the experience and literature in the field is that almost
every time someone tries to create such a typology, they
conclude that these are much better modeled as
sometimes-overlapping domains rather than as discrete
partitions.   The subnet-based model you posit requires that
people or devices switch addresses when they change functions or
activities.  Up to a point, one can do it that way (and many of
us have, even with IPv4).  

But I suggest that trying to use subnetting as the primary and
only tool to accomplish those functions is architecturally just
wrong, _especially_ for the types of authorization-limitation
cases you list.  Wouldn't you rather have mechanisms within your
home network, possibly bound to your switches, that could
associate authorization property lists with each user or device
and then enforce those properties?   Kerberos (a very old
protocol by now) took the first steps in that direction by
associating access to server-type functions with authorization
properties rather than physical connectivity.  Perhaps it is
time to extend a model of that sort to access to network
resources --such as routing to other addresses both inside and
outside of the home network-- and to think through how it could
be scaled to effective and cost-efficient operation in a
home-sized network.

(3) It may be worth remembering that subnetting was introduced
into the IPv4 architecture partially to deal with routing
isolation and efficiency for LANs based on 10Base10 and 10Base2
Ethernet --backbone-style networks at the LAN, or groups of
LANs, level.  While some lazy few of us still have some 10Base2
in our LANs, the move toward LAN segments based on twisted-pair
cabling and fanout switch arrangements creates opportunities we
didn't have when "segment" was a physical property rather than a
logical one.  Is it time to review and update the network
architecture to reflect new opportunities in the physical one,
rather than assuming that authorization is necessarily reflected
in subnets?

(4) Which IETF WG is working on these things?  :-(

     john

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 26 Aug 2007 15:53:51 +0200

Christian Huitema writes:
> The definition of a small network is pretty much "single subnet". Yes, 
> I understand very well that the average home of the future will have 
> a mixed wiring. Of course, my own home does have Ethernet and Wi-Fi. 
> In the not so distant future, it will have several Wi-Fi networks 
> operating on different frequencies, some form of power-line 
> networking, and some rooms may have their own high speed wireless 
> wiring using UWB or some similar technology. But I am pretty much 
> convinced that all of these will be organized as a single subnet.

You mean that the faster actual subnets will not be subnets in the IETF 
sense, right?

If a number of devices have some extremely fast special network, and a 
bridge or router to connect them to the rest of the world, presumably 
they need the extra bandwidth: If their traffic were to leak onto the 
slower net, it would be more or less unusable.

But there are several ways in which the fast devices can leak traffic, 
often involving broastcast or multicast. (I have some neat audio boxes 
that multicast to group "all-devices-from-manufacturer-x", very nice, 
but I'm glad my backbone isn't 802.11.)

Either the IETF subnet has to be usable to describe these actual subnets 
(ie. people get more than a /64 automatically so it's the common case 
and random consumerboxes are built for it) or there'll eventually be 
some new subber-than-subnet concept so devices can broadcast or 
multicast traffic onto their fast subber-than-subnet without 
overwhelming the slow parts of the subnet.

Arnt

---

From: Christian Huitema <[email-masked]>
Date: Sun, 26 Aug 2007 08:16:28 -0700

> capability to them, for many years.

People want security, and the threats that Michael mention are real:
children spying on the parent's traffic, guests abusing the access to do
something illegal on the Internet. But subnets are not a particularly
efficient way of solving these threats.

Take the issue of guests abusing the privilege and engaging in illegal
action. The concrete risk is that men in black will knock at your door
and ask about said actions. Picture yourself arguing that "it obviously
wasn't me, because the packets come from the network that I provide to
my guests". The men in black will not be impressed, since you obviously
have access to all the networks in your house. Your only defense will be
to rat a specific guest, supposing of course that you are so enclined.
Subnet or no subnet will no help you do that. Access control and logs
will help, but these are not tied to subnets.

Consider then the attacks between computers on the same network. Michael
mentioned traffic snooping. But modern Wi-Fi network are protected
against that already. They negotiate different per-session keys. Even in
promiscuous mode, the Wi-Fi card does not see the unicast traffic of the
other stations in the network. In home networks, the key is derived from
an initial 4-ways handshake, secured by a pass-phrase. Most deployments
use a single pass-phrase today, so teenagers could indeed develop tools
to crack the exchange. But nothing prevents using different pass-phrases
for different group of users.

The other risk are the active attacks between connected computers.
However, as John pointed out, there is lot of demand for connectivity
between computers in the home. Many people have tried to engineer
network topologies that follow organization or authorization boundaries,
but the mostly that makes your network expensive to run without really
solving the issues. 

Also, ultimately, all forms of topology based control rely on the
security of the home router. Do you really believe that a teenager who
is clever enough to hack into Wi-Fi access protections will not also be
able to hack into the home router?

If we want actual protection, it is probably much easier to use end to
end security. And in your own house, you might consider forms of social
control, as in "OK, you hacked my computer, give me the keys of your
car..."

Frankly, I don't see users managing subnets any time soon. 

-- Christian Huitema

---

From: Keith Moore <[email-masked]>
Date: Sun, 26 Aug 2007 14:32:24 -0400

subnets have proven to a useful tool in the past, and may prove so again
in the future, even if the reasons for future use are different than
those for past and present use.  I don't see why we should constrain the
network architecture to deny use of this tool to ordinary users.

Keith

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 26 Aug 2007 15:49:46 -0700

> From: John C Klensin [mailto:[email-masked]] 
> Examples:
> 
> (1) Unless it was changed when I wasn't looking, there is a 
> rule in  the IPv6 architecture that says that one cannot 
> subnet on a prefix longer than a /64.  That rule appears to 
> be someone hostile to efficient use of address space at the 
> "small network with subnets" side of things.  Has that rule 
> outlived its usefulness? If so, how do we go about changing 
> it before IPv6 is sufficiently widely deployed to make it 
> even more difficult and disruptive to do so?

Perhaps you could define the term subnet?

I don't see how such an architectural limitation can be enforced. There is no way that the IETF can prevent an ISP issuing IPv6 customers a /128 if they choose.

The situation we have is similar to that which Octavian found himself in the aftermath of the assasination of Ceasar, he had authority but not power. It is not a hopeless position, I have often found authority to provide more real influence than formal decision making power. But understanding the difference is critical if there is to be effective influence.

> But I suggest that trying to use subnetting as the primary 
> and only tool to accomplish those functions is 
> architecturally just wrong, _especially_ for the types of 
> authorization-limitation cases you list.  Wouldn't you rather 
> have mechanisms within your home network, possibly bound to 
> your switches, that could associate authorization property 
> lists with each user or device
> and then enforce those properties?  

I agree, encoding authorization data into the network address is not a good strategy, another structural oddity is that we continue to view the Internet as a network of hosts rather than a network of services.

> (3) It may be worth remembering that subnetting was 
> introduced into the IPv4 architecture partially to deal with 
> routing isolation and efficiency for LANs based on 10Base10 
> and 10Base2 Ethernet --backbone-style networks at the LAN, or 
> groups of LANs, level.  While some lazy few of us still have 
> some 10Base2 in our LANs, the move toward LAN segments based 
> on twisted-pair cabling and fanout switch arrangements 
> creates opportunities we didn't have when "segment" was a 
> physical property rather than a logical one.  Is it time to 
> review and update the network architecture to reflect new 
> opportunities in the physical one, rather than assuming that 
> authorization is necessarily reflected in subnets?

Again, I agree, hence my request for a definition of subnet. It is a term that has been thrown around with much abandon but looks very likely to mean different things to different people at this point.

---

From: Keith Moore <[email-masked]>
Date: Sun, 26 Aug 2007 19:17:38 -0400

> I don't see how such an architectural limitation can be enforced. There is no way that the IETF can prevent an ISP issuing IPv6 customers a /128 if they choose.
Perhaps not, but such an ISP might incur significant support costs.  For
instance, an ISP that assigned a /128 might get a complaint every time a
customer tried to change his computer or network card.  That, and
several IPv6 protocols were designed with the assumption that /64 was
the maximum length of a prefix to be assigned to a net.  There aren't
any more bits in those protocols to support a longer subnet mask.

Realistically if an ISP wanted to restrict its customers to a maximum of
one IPv6 host there are probably less disruptive (therefore cheaper)
ways to do this than to try to make the customer's network prefix be a
/128.  And then the customers would just NAT, and the ISP's effort would
be wasted.  So there's little benefit to the ISP in doing this,
particularly if they can get enough addresses from their upstream
providers or registries.

More broadly, IETF can't prevent an ISP from offering a service that
claims to be Internet but doesn't follow the specified protocols.  But
since those protocols are the agreements by which interoperability is
obtained, an ISP that violates those protocols risks alienating its
customers when their applications do not work.  In practice, ISPs do
this routinely (e.g. ISPs that provide DNS servers that lie about the
RRs for a given zone), and they also get pushback for doing so. 
Customers are slow to learn but some of them do change ISPs when they
find out that they're being screwed.

As you point out, we have very little power to prevent ISPs (or
equipment vendors, or OS vendors, or users) from doing harm.  But that
doesn't mean we should say that it's okay for them to do things that we
have every reason to believe will do harm. 
> I agree, encoding authorization data into the network address is not a good strategy, another structural oddity is that we continue to view the Internet as a network of hosts rather than a network…
Well, at one level, it is a network of hosts.  The network of services
is built on top of the network of hosts.  It's just that the boundary
between the two is fuzzy.

Keith

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 27 Aug 2007 11:10:53 +0200

Hallam-Baker, Phillip writes:
> I don't see how such an architectural limitation can be enforced. 
> There is no way that the IETF can prevent an ISP issuing IPv6 
> customers a /128 if they choose.

Not directly, but there's the indirect route: a) IETF designs IPv6 
autoconfiguration. b) Linksys, D-Link, Netgear and friends make boxes 
that support autoconfiguration. c) ISP hand out /128s. d) 
Autoconfiguration doesn't work well. e) Customers call ISP support. f) 
ISP loses $$$. g) ISP starts issuing /48s instead.

I don't know the first thing about how IPv6 autoconfiguration works. It 
worked very well in my previous office. Will it work better when the 
router has a /48 at hand than a /64 or /128?

Arnt

---

From: Peter Dambier <[email-masked]>
Date: Mon, 27 Aug 2007 13:22:16 +0200

> router has a /48 at hand than a /64 or /128?

I remember working with my own little  lan:

three Site Local and one tunnel networks.

radvd or SuSE 7.1 and SuSE 8.2 did expect /64

The tunnel would either give me a /64 without local router
or a /48 if I had a local router.

Today Site Local is given up. So I changed to 192.168...
addresses with 6to4 addressing.

RFC 2462 says we normally have EUI-64 addressing that is
either a funtion of the MAC address or a random number.
With EUI-64 (64 bits) the prefix must be /64 for an
autoconfigured network segment.

The tunnel used to be a /124 network segment
overlapping my /64 with ..0 the net, ..1 the other
end of the tunnel, ..2 me and ..3 broadcast.

Theoretically ..2 would have been a router for anything
in my /64, but that never worked. So practically I
ended up with a /128

If you have a LAN with servers you need predictable
addresses for your servers. Renumbering is not an
option. Site Local does not exist any longer. 182.168..
with 6to4 addressing is the only way I see. But
that means - no autoconfiguration.

Without autoconfiguration /124 and NAT is good enough
for me. But how about my aunt with her laptop?

Kind regards
Peter and Karin

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
mail: [email-masked]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 27 Aug 2007 05:15:40 -0700

Looks to me like people are trying to use technology to effect their political goals.

I don't think that is a good idea, particularly since the process does not allow the goals to be stated or debated directly. So even if we agree on the end goals we are unlikely to end up with a mechanism that achieves them.

We went through all that with the crypto-wars. We ended up with a set of cryptography protocols that almost nobody uses.

I see no political reason to insist on a /48 as the minimum allocation. A /96 gives me more addresses than the old IPv4 space had. 

If we attempt to insist on a /x as the minimum allocation by introducing technical limitations that make it impossible to use less than a /x all we do is to make an allocation that could have been sufficient insufficient. 

> From: Arnt Gulbrandsen [mailto:[email-masked]] 
> Sent: Monday, August 27, 2007 5:11 AM
> To: [email-masked]
> Cc: [email-masked]; John C Klensin; Hallam-Baker, 
> Phillip; [email-masked]; [email-masked]
> Not directly, but there's the indirect route: a) IETF designs 
> IPv6 autoconfiguration. b) Linksys, D-Link, Netgear and 
> friends make boxes that support autoconfiguration. c) ISP 
> hand out /128s. d) Autoconfiguration doesn't work well. e) 
> Customers call ISP support. f) ISP loses $$$. g) ISP starts 
> issuing /48s instead.
> 
> I don't know the first thing about how IPv6 autoconfiguration 
> works. It worked very well in my previous office. Will it 
> work better when the router has a /48 at hand than a /64 or /128?
> 
> Arnt
>

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 27 Aug 2007 14:28:11 +0200

> Looks to me like people are trying to use technology to effect their 

Guilty as charged, and proud of it.

My political goal is to make computers help people in their daily life, 
and I believe that eliminating the class of users without the ability 
to subnet, leaving only one type of internet user, helps towards that 
goal. If there's only one type of network to autoconfigure, testing and 
deploying autoconfiguring devices is simpler, and autoconfiguration 
will do the right thing in a larger percentage of cases, leaving more 
people happy and making fewer people call support.

Arnt

---

From: <[email-masked]>
Date: Mon, 27 Aug 2007 21:52:48 +0100

> (2) The many examples you give seem to be to be associated 
> with different domains of authorization and privilege for 
> different groups of people and functions within the home.  My 
> impression of the experience and literature in the field is 
> that almost every time someone tries to create such a 
> typology, they conclude that these are much better modeled as 
> people or devices switch addresses when they change functions 
> or activities.  Up to a point, one can do it that way (and 
> many of us have, even with IPv4).  

The subtext here is Ethernet. People are talking about home networks
based on Ethernet and whether or not they should be segmented by
routers. In my experience Ethernet bridges and switches are not designed
with security as a goal. When they fail to transmit all incoming frames
on all interfaces, it is to prevent segment overload or broadcast
storms. There are many cases where people have found ways, sometimes
quite simple ways, to receive Ethernet frames that are not addressed to
them. Given this backdrop, I am suggesting that a homeowner may have
several reasons for inserting routers (and router/firewalls) into their
home network, thus requiring the ability to have multiple /64 IPv6
subnets. Architecture aside, this is a pragmatic response to an
information security issue.

> and then enforce those properties? 

This would be nice, but I believe this needs more work and not just in
the IETF. Also, I believe that the IETF should tackle the basic
requirements for a home and/or business IPv6 Internet gateway first, and
then go on to the more advanced security issues.

> (4) Which IETF WG is working on these things?  :-(

Or failing that, which area does it belong in?

--Michael Dillon

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 27 Aug 2007 16:08:14 -0500

Thus spake <[email-masked]>
> In my experience Ethernet bridges and switches are not
> designed with security as a goal. When they fail to transmit
> all incoming frames on all interfaces, it is to prevent segment
> overload or broadcast storms. There are many cases where
> people have found ways, sometimes quite simple ways, to
> receive Ethernet frames that are not addressed to them.
> Given this backdrop, I am suggesting that a homeowner
> may have several reasons for inserting routers (and router /
> firewalls) into their home network, thus requiring the ability
> to have multiple /64 IPv6 subnets. Architecture aside, this
> is a pragmatic response to an information security issue.

Basically, because some people are too dense to use IPsec or SSL for traffic 
they don't want observed, you want to greatly complicate the average home 
network's design?  That they should be more scared of, say, their spouse 
sniffing their credit card numbers at home than the NSA and FBI tapping 
their email and web browsing at the CO?

Sorry, but that's the wrong response to the wrong problem.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: "Davis, Terry L" <[email-masked]>
Date: Mon, 27 Aug 2007 07:04:14 -0700

Michael

Agree.

And don't forget that your:
- power company
- communication/entertainment provider/s
- alarm/monitoring company
- local government
- EMS

All have at least discussions in progress that would give each
home/apartment a subnet (albeit possibly/probably on different networks)
for there use as a home service provider.

Take care
Terry

> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, August 26, 2007 4:42 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [ppml] IPv6 addresses really are scarce after all
> 
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy
> Mailing List ([email-masked]).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
Member
> Services
> Help Desk at [email-masked] if you experience any issues.

---

From: Thomas Narten <[email-masked]>
Date: Tue, 28 Aug 2007 16:09:14 -0400

Hi Bob.

> it, avoid the overall problems you describe (e.g., cable modem, DLS,  

Looking back at some old notes, I believe that changing the HD ratio
thresholds gave us roughly one order of magnitude's worth of
additional headroom. Moving the end site boundary from /48 to /56
gives us roughly two additional orders of magnitude savings. So, while
one can certainly argue about just how much is "enough" (since
projections 50-100 (or more!) years into the future are pretty iffy),
I think that both changes were important to make.

> the one that started this thread:

IMO, this concern is overblown. And to be clear, I've heard this
concern for years -- especially here in the IETF -- and it was one of
the reasons why the 3177 recommendations were what they were. But
having attended RIR meetings on and off for the last 5 years, and
having talked with folk that go there, most of them very clearly
understand that we have lots of IPv6 addresses and that the intention
is that users get them. I do not hear serious talk about being
restrictive in giving out subnets.

What I do hear is that giving out /48 to everyone is simply
profligately wasteful. And unjustified. And repeats the early mistakes
of IPv4 where people didn't think about managing resources prudently.

We shouldn't be surprised that a "one size fits all" approach (where
home users get the same amount of space by default as an IBM or
Microsoft) doesn't seem to make a lot of sense to some people.

> recommendation, then in my view is not a good idea.

It should be noted that the policy proposal being quoted here was
submitted even though RFC3177 is on the books. And that some RIRs have
already adopted the change to /56. So, no, changing RFC 3177 isn't
(IMO) going to open the door (any wider) to such proposals. 

At the same time the continuing existance of RFC 3177 is not going to
stop RIRs from adopting policies that they think make sense. Leaving
3177 on the books as it currently stands, strikes me as a form of
denial. It doesn't document existing practice, and at a minimum, we
should acknowledge that.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 28 Aug 2007 16:13:28 -0400

Hi John.

> IETF decisions and decisions made as part of determining what

Agreed.

But I think there was a lot more discussion about this in the very
early days, when 128 bits was chosen, and when stateless address
autoconfiguration assumed that the Interface Identifier part of an
address was 48 bits, leaving 64+16 bits for routing.

Then, we made the decision to make Interface Identifiers 64 bits,
shrinking the routing part to 64 bits.

I agree completely that the /64 boundary was/is architectural. For
better or for worse, stateless address autoconfiguration (as currently
specifies) only works on links that have a /64 assigned to them.

But the /48 boundary is not. We had a long discussion about that in
the IPv6 WG, and our specs were carefully cleansed to make sure there
were no real dependencies on such a boundary. Think Randy Bush saying
"your reinventing IPv4 classful addressing" about a thousand
times. :-)

Indeed, even though the official IETF party line is that links have to
have 64 bits of subnet addressing assigned to them, a number of
operators screamed loudly that for internal point-to-point links, that
was horribly wasteful and they weren't going to stand for it. So,
products do indeed support prefixes of arbitrary length (e.g., /126s
and the like), and some operators choose to use them. This is one of
those situations where the IETF specs seem to say one thing, but the
reality is different. And we pretend not to notice too much.

> RIRs (although I assume their advice was certainly welcomed).

Understood. But I think the reality today is that we have the world we
live in and serious suggestions to overturn the current world order
better have a strong and compelling motivation.

I'm sure you've also noticed, but IANA's recent position seems to be
more like "IANA doesn't make policy, IANA does what the community asks
of it".

> whose toes are being stepped on before opinions are expressed.

I think that has mostly been happening, though it could always be done
better.  The proposed changes to the HD ratio and /48 boundary were
certainly discussed in the IPv6 WG when they took place. And there are
folk that participate in both the IETF and the RIR communities.

Thomas

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Aug 2007 16:38:26 -0400

> of IPv4 where people didn't think about managing resources prudently.
The people at the RIRs might genuinely feel this way, but I suggest that
they're not really in a position to evaluate whether this is wasteful. 

When making decisions like this, where there's a tradeoff to be made
between competing concerns, everybody tends to optimize for the
concern(s) with which he is most familiar.  Because the RIRs have borne
much of the burden of conserving IPv4 addresses, it's hardly surprising
that the RIRs would be concerned about the ability to conserve IPv6
addresses. 

OTOH, I am more sympathetic with the application and user side of
things, so I want to preserve flexibility in that area.  Assumptions of
the form "256 subnets will always be enough" strike me as extremely
shortsighted, especially because it implicitly assumes a single level of
delegation inside the home.  What we should know by now is that the
fundamental constraint on use of addresses typically isn't 2**<number of
bits available> but rather, the number of levels of delegation.  That's
why arguments of the form "2**32 addresses will always be enough" didn't
turn out to be valid.  The argument is no more valid if you substitute a
different exponent, unless you evaluate that number in terms of
delegation levels.

Basically I view the IPv6 address as a variable length address, with an
upper limit of 128 bits, and the "unused" bits in the portion between
the length of the subnet mask assigned to the customer and the 64 bit
boundary.  Really a variable length address is what we need, but we have
a large fixed length address as a design compromise that gives us
addresses at fixed offsets relative to the beginning of the packet.  To
take away 8 bits of that headroom really does limit the flexibility of
what users can do with that address, and is a fundamental change to that
design decision.
> Microsoft) doesn't seem to make a lot of sense to some people.
No, it shouldn't be surprising.  But then again, people who weren't
there or aren't engineers themselves rarely understand the nature of the
delicate compromises that go into such decisions.  We don't do a good
job of documenting them either.  But this might in part be due to our
processes - we have to get rough consensus on the decisions we make, but
we don't have to get rough consensus on the reasons for those decisions
(or document them).  If we burdened ourselves with documenting our
decision-making criteria, we might be able to better fend off late
second-guessing.  But we'd delay our own output even further, and none
of us wants to do that.

> already adopted the change to /56.
Maybe what we need is an RFC explaining the reason for /48, or maybe
just a note saying that we don't feel like the RIRs are in a position to
second-guess IETF design decisions.  Seems like that would be a good
thing to say in general.  Even if this decision is not so bad (and who
knows what unintended consequences it will bring in the distant
future?), it sets a dangerous precedent for the RIRs to be
second-guessing IETF recommendations.
>  So, no, changing RFC 3177 isn't
Pretending that the RIRs decision makes sense, when we had very good
reasons for choosing /48, strikes me as a much more severe kind of denial.

I cannot say this strongly enough.  Our job is not to document existing
practice.  Our job is to make recommendations as to what we think will
work best.  Anytime someone in IETF insists that we should align our
decision with somebody's notion of "existing practice" independently of
whether or not that practice is sound, the suggestion should be
immediately considered out of order and ignored.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Aug 2007 16:54:46 -0400

> But the /48 boundary is not.
Strongly disagree.  The /48 boundary was a fairly direct consequence of
the /64 boundary and of the decision to align DNS address lookups on
4-bit boundaries.  There might not be any strong protocol dependence for
the choice of /48, but the need to balance the needs of users for
flexibility against the need to conserve address space made /48 a fairly
obvious choice after the issues were considered.  And no, it's not
something that we should wire into our protocols any more than necessary
- as we might find out in the future that the boundary needs to be moved
one way or the other.  That doesn't mean that it can be changed at the
RIRs' whim.

(Really I wish we hadn't wired /64 into our protocols.   But that's
water under the bridge.)
>  We had a long discussion about that in
He was certainly right in the sense that leaving flexibility in the
protocol specs and implementations leaves wiggle room for later.  On the
other hand, what the RIRs are now showing us is that such flexibility
gives others room to change fundamental design decisions without due
consideration to the factors that produced the original compromise. 
Maybe fixed boundaries would have been better after all.  (I don't
really believe this, I just think that trust in the RIRs to make these
decisions is misplaced.)
> reality is different. And we pretend not to notice too much.
I do wish we had some sort of feedback mechanism for observing when
people don't implement our specifications and why.  Such feedback
shouldn't compel us to change our specifications to reflect "reality",
but it might give us cause to change them in some way or other - either
to provide a better way of doing what people need, or maybe to explain
why a particular extension or practice is undesirable even though it
appears (from a limited perspective) to be useful.
> better have a strong and compelling motivation.
Again, our job is not to wire (somebody's notion of) "the reality today"
into protocol designs that need to serve us long into the future. 
Trying to make our protocols reflect current practice is like chasing
one's own tail - rather pointless.
> certainly discussed in the IPv6 WG when they took place. 
Perhaps, but I don't see any evidence of IETF-wide consensus on this. 
And it's not like it doesn't affect all of us.

Keith

---

From: <[email-masked]>
Date: Tue, 28 Aug 2007 22:00:56 +0100

> We shouldn't be surprised that a "one size fits all" approach 
> (where home users get the same amount of space by default as an IBM or

I think this is a wrong comparison. The intent is to give a /48 to a
site where a site is either a private home or a building or an office or
a campus. In each case, the site is relatively compact physically and is
under a single administrative control. In a residential apartment
building, each apartment is a site. In an industrial complex, each unit
is a site. And so on.

The fact that some companies may choose to service all their sites via a
private network (or VPN) gatewayed through one (or a few) main site(s)
does not substantially change this. If a bank closes a branch and
somebody turns it into a restaurant, that restaurant will get a /48. The
bank could have gotten a /48 for the branch if they wanted to use
generic IPv6 Internet access as the underlying service for their VPN. 

Consider the scenario where one bank merges with another bank. If both
banks have structured their newtork with /48 assignments from local
ISPs, the network merger is much simpler. They can even keep the IPv6
address assignments and ISP connectivity running. If they choose to hang
all their sites off a central gateway you are likely to find that one
bank assigned a /64 per branch and another assigned a /62, or maybe a
/120. Merging those two networks will be as messy as in the IPv4 world.

> At the same time the continuing existance of RFC 3177 is not 
> going to stop RIRs from adopting policies that they think 
> make sense. Leaving
> 3177 on the books as it currently stands, strikes me as a 
> form of denial. It doesn't document existing practice, and at 
> a minimum, we should acknowledge that.

I believe that 3177 was intended to be guidance for RIRs and other
network architects. Given that the IETF is moving IPv6 into maintenance
mode, this RFC sorely needs to be updated to reflect the final design.

If you also want to have an informational RFC to document existing
practice, that is reasonable as a separate document, but it should not
simply document what the RIRs did in the first half of 2007. Instead it
should discuss the pros and cons of varying the HD ratio and,
implementing a separate assignment size for home users, and the choice
of /56 as that assignment size. Remember, the RIRs might rescind those
policies or dream up something new by the time 2008 rolls around.

--Michael Dillon

---

From: <[email-masked]>
Date: Tue, 28 Aug 2007 22:09:40 +0100

> But the /48 boundary is not. We had a long discussion about 
> that in the IPv6 WG, and our specs were carefully cleansed to 
> make sure there were no real dependencies on such a boundary. 
> Think Randy Bush saying "your reinventing IPv4 classful 
> addressing" about a thousand times. :-)

It is a very bad thing when the IETF bows to demands from the ISP
industry to hobble the network architecture for other businesses and
consumers. Thankfully, the IETF did not do that and the
one-size-fits-all architecture of a /48 for all, remains intact. The
fact that some RIRs allow ISPs to assign a different one-size-fits-all
to consumer sites, really doesn't change this fundamental architecture.

> Indeed, even though the official IETF party line is that 
> links have to have 64 bits of subnet addressing assigned to 
> them, a number of operators screamed loudly that for internal 
> point-to-point links, that was horribly wasteful and they 
> weren't going to stand for it. So, products do indeed support 
> prefixes of arbitrary length (e.g., /126s and the like), and 
> some operators choose to use them. This is one of those 
> situations where the IETF specs seem to say one thing, but 
> the reality is different. And we pretend not to notice too much.

It is good that the IETF responded to demands from the ISP industry for
features which are needed in that industry. It is not good if the IETF
lets the ISP industry make architectural decisions for other businesses.

> And there are folk that participate in both the IETF and the RIR
communities.

That's fine as long as they aren't trying to get the RIRs to override
IETF architectural decisions. The RIRs are not a proper forum for that
kind of thing because the needed technical review is simply not possible
in the RIRs.

--Michael Dillon

---

From: David Kessens <[email-masked]>
Date: Tue, 28 Aug 2007 15:06:04 -0700

Thomas,

> Microsoft) doesn't seem to make a lot of sense to some people.

US  	2001:49c0::/32  	2001:49c0::/32  	IBM-IPV6-01
US  	2001:4898::/32  	2001:4898::/32		MICROSOFT-IPV6-BLK

If there really is a "one size fits all" policy, 
where can I get my personal IPv6 /32 allocation ?

David Kessens
---

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 Aug 2007 18:35:40 -0400

--On Tuesday, 28 August, 2007 15:06 -0700 David Kessens
<[email-masked]> wrote:

>> (where home users get the same amount of space by default as
>> an IBM or Microsoft) doesn't seem to make a lot of sense to
>> some people.
> 

Conversely, if /48 is sufficient for any plausible enterprise,
is ARIN being appropriately conservative about addresses here?

Even extrapolation from the new ARIN table 

> * /48 - Site with 16+ subnets initially.

would give 
  /44 - 32 subnets plus
  /40 - 64 subnets plus
  /36 - 128 subnets plus
  /32 - 256 subnets plus

Well, maybe I/we believe that is plausible and maybe we don't,
but it seems to me that it is a significant change in policy and
that a "subnets needed" model is, at that scale, a significant
change from policies based simply on HD-ratios (which don't
consider the number of subnets in an allocation at all as far as
I can tell).

    john

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 28 Aug 2007 15:44:01 -0700

> is ARIN being appropriately conservative about addresses here?

Are you saying that from where you sit those organizations don't meet
the requirements for an initial allocation as an LIR?

---

From: Thomas Narten <[email-masked]>
Date: Tue, 28 Aug 2007 19:26:03 -0400

> the requirements for an initial allocation as an LIR?

This is the key point. And as David well knew when he posted his note,
LIRs are not end sites and are treated _very_ differently. A /32 is
the default minimum size an LIR gets. For those not familiar with the
terminology, an LIR is what we usually think of as a ISP or provider,
where the organization provides internet connectivity for a number of
other organizations.

As a data point, ARIN (in the last year) adopted a IPv6 PI for end sites
doing multihoming policy. Such end sites get a /48.

Thomas

---

From: David Kessens <[email-masked]>
Date: Tue, 28 Aug 2007 16:41:18 -0700

Thomas,

On Tue, Aug 28, 2007 at 07:26:03PM -0400, Thomas Narten wrote:
> the default minimum size an LIR gets. 

What you are saying here is that there is no "one size fits all policy".

> For those not familiar with the

The definition of LIR is different in different Regional Registries. I
can think of at least one region where there is no connection between
being an LIR and providing connectivity to other organizations.

> doing multihoming policy. Such end sites get a /48.

The policy says something different:

"The minimum size of the assignment is /48. Organizations requesting a
 larger assignment must provide documentation justifying the need for
 additional subnets."

(from "6.5.8.2. Initial assignment size":
 http://www.arin.net/policy/nrpm.html#six582)

Again, no "one size fits all" policy. 

David Kessens
---

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 28 Aug 2007 16:43:14 -0700

> where the organization provides internet connectivity for a number of

Many large organizations and most if not all isps are in a position to
qualify as IPv6 LIR's.

6.5.1.1. Initial allocation criteria

To qualify for an initial allocation of IPv6 address space, an
organization must:

   1. be an LIR;
   2. not be an end site;
   3. plan to provide IPv6 connectivity to organizations to which it
will assign IPv6 address space, by advertising that connectivity through
its single aggregated address allocation; and
   4. be an existing, known ISP in the ARIN region or have a plan for
making at least 200 /48 assignments to other organizations within five
years.

> doing multihoming policy. Such end sites get a /48.

or larger...

6.5.8.1. Criteria

To qualify for a direct assignment, an organization must:

   1. not be an IPv6 LIR; and
   2. qualify for an IPv4 assignment or allocation from ARIN under the
IPv4 policy currently in effect.

6.5.8.2. Initial assignment size

Organizations that meet the direct assignment criteria are eligible to
receive a direct assignment. The minimum size of the assignment is /48.
Organizations requesting a larger assignment must provide documentation
justifying the need for additional subnets.

These assignments shall be made from a distinctly identified prefix and
shall be made with a reservation for growth of at least a /44.
6.5.8.3. Subsequent assignment size

Additional assignments may be made when the need for additional subnets
is justified. When possible, assignments will be made from an adjacent
address block.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 28 Aug 2007 18:33:22 -0700

There are two sets of issues here.
 
One is that routing tables take up space, so even if you allocate in /64 units you are going to end up running out of silicon before you run out of address space.
 
Another is this fetish with stateless allocation of network addresses etc. It might have been a workable proposal when it was made but is almost certainly irrelevant to any real world IPv6 network that is actually deployed and managed as such.
 
In the real world network devices are going to have to authenticate to the network before they are allowed to ship packets about. So eliminating the need to maintain state in DHCP is irrelevant, the network authentication layer is going to require rather more than 8 bytes of state, a MAC address and a session key at the least. So recording the IP address suffix that was assigned is not gong to be an issue.
 
Folk can debate whether or not default deny will happen and there will be strong policy enforcement at every layer in the network as I propose. But 802.1x is a fact of life for many corporate users today. If home users are going to run wireless networks of any size they are going to need to go the same route.
 
Nor do I see the reason to obsess about keeping the DHCP table stateless. Its not like a network with 64K hosts is going to be hanging off a single DHCP server anyway. 
 
Given that we have the space issuing a /64 and allowing folk to simply map EUI64 addresses via some sort of cryptographic one way function (e.g. encrypt with a 64 bit block cipher and a common network key) makes sense. But then insisting on allocation of extra bits for subnetting strikes me as applying 1980s networking approaches in an environment where they no longer make sense, something some people seem to be against.

I think that we will find that there are 2 sets of user. Most users will never subnet at all and be entirely happy with a /64.
 
Folk who are using 'subnets' are most likely to be doing so in order to implement security mechanisms that encode network authorization data into the IP address. This is already quite common in the enterprise security world. Here 16 bits is not likely to be enough, 32 is more like it. Anyone playing this game is nopt going to be using the EUI64 mapping trick either.

I don't find the idea that everyone needs a /48 is likely to apply to either group. And if people find they need more than one /64 they can always get more. Its not like they have to be contiguous.

________________________________

From: Thomas Narten [mailto:[email-masked]]
Sent: Tue 28/08/2007 4:13 PM
To: John C Klensin
Cc: [email-masked]
Subject: Re: IPv6 addresses really are scarce after all

Hi John.

Agreed.

Thomas

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Aug 2007 23:21:01 -0400

Hallam-Baker, Phillip wrote:
>  
> I don't find the idea that everyone needs a /48 is likely to apply to
> either group. And if people find they need more than one /64 they can
> always get more. Its not like they have to be contiguous.
It really sounds like you want IETF to provide mechanisms to enable ISPs
to artificially increase prices for users.

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Aug 2007 03:05:51 -0400

--On Tuesday, 28 August, 2007 16:43 -0700 Joel Jaeggli
<[email-masked]> wrote:

>> This is the key point. And as David well knew when he posted
>> his note, LIRs are not end sites and are treated _very_
>> differently. A /32 is the default minimum size an LIR gets.
>> For those not familiar with the terminology, an LIR is what
>> we usually think of as a ISP or provider, where the
>> organization provides internet connectivity for a number of
>> other organizations.
> 
> Many large organizations and most if not all isps are in a
> position to qualify as IPv6 LIR's.
> 
>    3. plan to provide IPv6 connectivity to organizations to
> which it will assign IPv6 address space, by advertising that
> connectivity through its single aggregated address allocation;
> and
>    4. be an existing, known ISP in the ARIN region or have a
> plan for making at least 200 /48 assignments to other
> organizations within five years.

The traditional meaning of LIP is someone who is in a business
equivalent to that of an ISP and an ISP assigning moderately
long-lived (not single address for a for a single connection)
address pool to others.  E.g., someone providing dial-up access
to unrelated (except by the transfer of money) others may well
be an ISP, but has historically not been considered to be an
LIR.    To say that IBM or Microsoft (to use your example) are
really big organizations with multiple locations are LIRs as a
consequence of the fact of their size (and/or power) turns the
terminology, and concept of an LIP acting as a registry and
making suballocation on its ear.   

The statement above is consistent with that analysis so,
whatever ARIN is doing, they haven't gone into the Humpty Dumpty
business (in which words mean whatever they claim they do at the
moment) yet.

>> As a data point, ARIN (in the last year) adopted a IPv6 PI
>> for end sites doing multihoming policy. Such end sites get a
>> /48.
> 
> or larger...
> 
> 6.5.8.1. Criteria
> 

again, consistent.  Note the "not".

>    2. qualify for an IPv4 assignment or allocation from ARIN
> under the IPv4 policy currently in effect.

In other words, to get IPv6 PI space, I must already qualify for
IPv4 PI space.  That seems reasonable on the basis of history.
But, as IPv4 space gets very tight (as predicted), it could be
construed as a mechanism by which incumbent ISPs and other
organizations who already have large blocks of legacy IPv4 space
keep new entrants, especially any who have business and/or
network models that are be IPv6-only, from playing.   I think
there are technical terms for that sort of strategy.
 
> Organizations that meet the direct assignment criteria are
> eligible to receive a direct assignment. The minimum size of
> the assignment is /48. Organizations requesting a larger
> assignment must provide documentation justifying the need for
> additional subnets.

This gets us to /48, not /32.  It also says that, under some
circumstances, an organization can go to ARIN directly for space
rather than an LIR or getting PA space from an ISP.  Having that
allocation size be the same size that (i) IETF considers normal
and (ii) ARIN encourages LIPs to give out to entities who need a
large handful of subnets, rather than one the basis of HD
ratios, seem strange to me given the claims that IPv6
multihoming does not require PI space and separate routing.
Indeed, such a policy seems to me to be more of a threat to
routing table size than encouraging ISPs to give out /48s (that
they will aggregate into their large, LIP, blocks, for routing
purposes) all the time, but that is probably a separate issue.

In addition, again using your example, unless IBM or Microsoft
has deployed IPv6-working and connected hosts on the order of
80% of a /36 (or at least 80% of a /44 or some intermediate
number), they have justified a /32 (if at all) on the basis of
promises and network designed, not actual use.  While their
production (?) IPv6 deployment may have gotten very large when
none of us were looking, that would otherwise be a fairly large
chunk for an initial allocations from a body that was trying to
conserve space.

> These assignments shall be made from a distinctly identified
> prefix and shall be made with a reservation for growth of at
> least a /44. 6.5.8.3. Subsequent assignment size

So, if I have a plan about 16 subnets, I get a /48 from my ISP.
If I can justify that much space on the basis of HD ratio, not
just number of subnets, I can go to ARIN, claim multihoming and
whine, plead, or, if I'm large enough, beat my chest, I can get
a PI /48 with a reservation of the rest of the /44 (or larger)
instead.   Maybe that is ok, except (i) IPv6 is not supposed to
require PI space on the basis of multihoming and (ii) that
criterion has nothing to do with whether one is an LIR.

> Additional assignments may be made when the need for
> additional subnets is justified. When possible, assignments
> will be made from an adjacent address block.

But now we are back to a "subnet count" criterion.   I don't
know what ARIN intends, but a plausible reading of this is that
I have to justify a PI /48 on the basis of HD ratio (and, of
course, already having IPv4 PI space or being able to get it).
Of course, the other possibility is that this really is about
subnets.  I.e., we don't care any more about _host_ density or
efficient use of address space and designing networks to ensure
a maximum number of hosts per subnet.   On that model, all I
need to justify a /32 is a nice drawing or two that explains how
many subnets I need on the basis of physical locations, a
cross-product of authorization domains and so on.   Of course,
for that story to be believed, I also have to hold an
equivalently large block of IPv4 PI space (no non-incumbents
need apply... see above).  But I didn't think that was where we
were headed.

     john

---

From: "Roger Jørgensen" <[email-masked]>
Date: Wed, 29 Aug 2007 10:55:58 +0200

On 8/29/07, Hallam-Baker, Phillip <[email-masked]> wrote:
<snip>
> I think that we will find that there are 2 sets of user. Most users will
> never subnet at all and be entirely happy with a /64.

just ONE /64 will almost never be enough. The reason are quite simple,
almost all types of connection require some sort of "link" toward the end-
site. This link need some sort of link-addresses and you cant get that
and the LAN out of the same /64, I'm quite sure that will lead to issues.

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Wed, 29 Aug 2007 11:04:40 -0400

Note, while I think it's useful to have an educational discussion
about IPv6 addressing policy on the IETF list, it's also a tad
frustrating how selective/partial context quoting leads the discussion
veering off in all kinds of random directions...

I'd encourage folk to read the entire IPv6 policy to get a more
complete picture. It's not that long. ARIN's is at:
http://www.arin.net/policy/nrpm.html#ipv6.

> multihoming does not require PI space and separate routing.

That claim/myth seems remarkably difficult to quash. Let me say it
clearly: IPv6 has no magic multi-homing solution, and the multihoming
approachs that IPv6 offers are essentially equivalent to those
available in IPv4.

Note that in the RIR community, this has been obvious for some time,
and is one of the reasons why the policies being developed there have
a lot of similarities to IPv4 policies (but they still do have
important differences).

> purposes) all the time, but that is probably a separate issue.

Yes, and the debate was quite contentious and played out over a number
of years. But eventually the "be very scared" arguments were drowned
out by the "IPv4 hasn't collapsed yet, and we need parity with IPv4,
when it comes to PI addressing".

> promises and network designed, not actual use.

Sorry, the 80% utilization metric is specific to IPv4. IPv6 doesn't
use this same utilization formula to measure the actual "utilization"
of a chunk of address space, it uses the HD-ratio metric.

And, since this is also very different in IPv6, let me point out that
what is counted is subnets, not hosts. Quoting from the ARIN document:

    6.2.7. Utilization
    
    In IPv6, "utilization" is only measured in terms of the bits to the
    left of the /56 boundary. In other words, utilization refers to the
    assignment of /56s to end sites, and not the number of addresses
    assigned within individual /56s at those end sites.
    
    Throughout this document, the term utilization refers to the
    allocation of /56s to end sites, and not the number of addresses
    assigned within individual /56s within those end sites.

And, for those of you worried about end users being given a /64 (or
worse), from a registry perspective, it is 100% acceptable to give
every end site a /56. That is what the above wording means, and that
is what the RIRs expect LIRs to do. If LIRs/ISPs choose to give end
sites less space than that, there really is no significant benefit to
them doing so. Indeed, I would expect that if an ISP stingily gave out
only /64s, it would find that there are other ISPs that are more than
happy to offer /56s. Thus there would be some marketting disadvantages
to being stingy and they have some discincentive to being overly
stingy.

> While their production (?) IPv6 deployment may have gotten very
> large when none of us were looking, that would otherwise be a fairly
> large chunk for an initial allocations from a body that was trying
> to conserve space.

The RIRs are not trying to "conserve" in the same sense as for
IPv4. The balance has clearly shifted to being less conservative in
terms of ultilization and also trying harder to avoid fragmentation of
the address space resulting from growth.

Quoting again from the ARIN document:

    6.3.4. Aggregation
    
    Wherever possible, address space should be distributed in a
    hierarchical manner, according to the topology of network
    infrastructure. This is necessary to permit the aggregation of
    routing information by ISPs, and to limit the expansion of
    Internet routing tables.
    
    This goal is particularly important in IPv6 addressing, where the
    size of the total address pool creates significant implications
    for both internal and external routing.
    
    IPv6 address policies should seek to avoid fragmentation of
    address ranges.
    
    Further, RIRs should apply practices that maximize the potential
    for subsequent allocations to be made contiguous with past
    allocations currently held. However, there can be no guarantee of
    contiguous allocation.
    
    6.3.5. Conservation
    
    Although IPv6 provides an extremely large pool of address space,
    address policies should avoid unnecessarily wasteful
    practices. Requests for address space should be supported by
    appropriate documentation and stockpiling of unused addresses
    should be avoided.

> criterion has nothing to do with whether one is an LIR.

There is that myth again. :-(

> need apply... see above).  But I didn't think that was where we

Your mixing things a bit here. The first part of the text refers to
the PI for end sites policy. The /32 applies to LIRs, a different
category of address assignment.

Thomas

---

From: <[email-masked]>
Date: Wed, 29 Aug 2007 22:23:34 +0100

> I'd encourage folk to read the entire IPv6 policy to get a 
> more complete picture. 

> And, for those of you worried about end users being given a 
> /64 (or worse), from a registry perspective, it is 100% 
> acceptable to give every end site a /56. That is what the 
> above wording means, and that is what the RIRs expect LIRs to 
> do.

That is *NOT* what the quoted wording means. You should read the entire
IPv6 policy to get a more complete picture. In your quoted text, /56 is
used as the base unit of measure because another area of policy suggests
that it is OK to assign a /56 to a small site. The /56 was added at the
request of IPS who have large numbers of consumer subscribers (cable
ISPs) since they preaddress their infrastructure for every home the
cable passes. Using a /48 would chew up /32s at an enormous rate
compared to ISPs using telecom circuits. In the same section where the
various sizes are discussed, it also states that it is acceptable to
assign every end site a /48. Nowhere does it state that a /56 is
acceptable for anything but the smallest sites (private homes).

> The RIRs are not trying to "conserve" in the same sense as 
> for IPv4. 

The RIRs are also not trying to "not conserve". In fact the RIRs are
merely responding to external requests for policy changes. After much
discussion, some policy changes meet rough consensus after which they
get a bit of wordsmithing (sometimes sloppily done) and enshrined in
policy. The RIRs lurch from one direction to another like a brain
damaged drunkard. A better quality of engagement from the IETF in the
form of an RFC with "IPv6 Guidance for RIRs" would greatly improve the
situation.

--Michael Dillon

---

From: Tony Finch <[email-masked]>
Date: Thu, 30 Aug 2007 11:22:04 +0100

> doing multihoming policy. Such end sites get a /48.

I thought that routes in the IPv6 DFZ were not supposed to be more
specific than /32.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 30 Aug 2007 12:42:32 +0200

> I thought that routes in the IPv6 DFZ were not supposed to be more

Actually nobody really knows how to handle IPv6 route filtering.  
Although IANA/RIR documents have suggested that filtering at /32 can  
be done, in practice this hasn't been true for years:

http://www.bgpexpert.com/article.php?article=80

---

From: Thomas Narten <[email-masked]>
Date: Thu, 30 Aug 2007 08:15:20 -0400

> I thought that routes in the IPv6 DFZ were not supposed to be more

Yes, another of the great myths. That somehow all IPv6 addresses would
be PAs, only ISPs would have them, and everyone would route on the
default ISP allocations (/32). Great idea in theory (if all you care
about is keeping route tables small), unworkable in practice if you
look at the demands of the real world (i.e., the last 15 years of
IPv4).

Take a look at draft-narten-radir-problem-statement-00.txt, as it
talks quite a bit about the realities that lead to lots of routing
table entries. The pressures to deaggregate /32s in IPv6 are
fundamentally the same as the pressures that lead to deaggration in
IPv4.

Thomas

---

From: <[email-masked]>
Date: Fri, 31 Aug 2007 16:31:50 +0100

> them per occupant and a few thousand more per room, 2**64 is still a
> _lot_ of addresses.  

This is hyperbole. All IPv6 subnets have the same minimum number of
addresses (2**64) regardless of where they are used.

>  But I don't think hyperbole 
> helps the discussion.

I agree. In any case, it doesn't make sense to discuss IPv6 in terms of
hostcounts. It makes more sense to discuss numbers of subnets or numbers
of aggregation levels.

If a private home with two occupants and one PC, builds out an in-law
suite for one mother-in-law with one PC, then it still makes sense to
have at least two subnets in that private home, i.e. at least one level
of aggregation. Hostcount is irrelevant. Note that if both mother-in-law
and homeowner install 4 or five home media devices, the subnetted
architecture will work better than a /64 per home scenario.

Now that we have shown subnetting is useful in a private home, it is
clear that a /64 per home is not enough.

It still leaves open the question of whether a /48 is too much, i.e. too
many subnets and/or too many levels of aggregation. If a /48 is not too
much, then the IETF should issue guidance that states that. If some
prefix length between /48 and /64 is OK under certain circumstances then
the IETF should issue guidance which states that. I still have not seen
any clear indication that there is a negative technical impact of
assigning a /56 per home. To date, the only clear technical issue I have
seen mentioned for subnet prefixes longer than /48 is that if they are
not on a 4-bit hex nibble boundary, it makes IPv6 PTR delegation more
complex.

--Michael Dillon

---

From: Keith Moore <[email-masked]>
Date: Fri, 31 Aug 2007 12:21:56 -0400

One of the things that I find myself wondering is whether "home" users
will need to establish VPNs to allow remote devices to access things in
their "homes".  And especially whether those remote devices will be
single devices or whether they will be on remote subnets.  This would
imply a need for more delegation levels within a "home" network.

Architecturally speaking, I don't like VPNs. I'd much rather that hosts
and apps be able to have addresses that are anywhere in the network and
be able to access hosts and networks elsewhere using authentication not
tied to source address.  But until we find better ways of protecting
networks and hosts, I don't think we should throw away use of the VPN as
a tool for authenticating remote devices to home networks.  Which again,
means not overly constraining the number of delegation levels available
to home networks.

> assigning a /56 per home. 
I think that's the wrong way to ask the question.  Rather than asking
"is there any reason that we know of today to not restrict the
flexibility of a home network?" ask "is there any reason why this
flexibility might be needed?"

Keith

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 1 Sep 2007 01:05:36 +0200

On 31-aug-2007, at 17:31, <[email-masked]>  
<[email-masked]> wrote:

> I still have not seen

Then you haven't been paying attention, I've been saying /56 is the  
wrong size for some time now.

> To date, the only clear technical issue I have

Then you have to delegate 2, 4 or 8 zones rather than 1, big deal.