Re: IPv6 end user addressing

[Mikael Abrahamsson]

On Fri, 5 Aug 2011, Brian Mengel wrote:


In reviewing IPv6 end user allocation policies, I can find little
agreement on what prefix length is appropriate for residential end
users.  /64 and /56 seem to be the favorite candidates, with /56 being
slightly preferred.


Not slightly preferred, very much preferred. /56 is future proof and works 
for "everybody". /64 is short sighted and doesn't allow for multiple 
networks in the home.



I am most curious as to why a /60 prefix is not considered when trying
to address this problem.  It provides 16 /64 subnetworks, which seems
like an adequate amount for an end user.


Why save on addresses, you can just get more IPv6 addresses if you need 
them. /56 is allowed per user from all the RIRs afaik.



Does anyone have opinions on the BCP for end user addressing in IPv6?


Yes, there are plenty of people with opinions.

This has been hashed over and over and over again, please check the 
archives for lots of discussions on pros an cons. If you want to do it 
right, go for /56, it works.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: IPv6 end user addressing

[Valdis . Kletnieks]

On Fri, 05 Aug 2011 12:17:48 EDT, Brian Mengel said:
> In reviewing IPv6 end user allocation policies, I can find little
> agreement on what prefix length is appropriate for residential end
> users.  /64 and /56 seem to be the favorite candidates, with /56 being
> slightly preferred.
> 
> I am most curious as to why a /60 prefix is not considered when trying
> to address this problem.  It provides 16 /64 subnetworks, which seems
> like an adequate amount for an end user.

Basically, the thinking was a /56 is still "cheap" as far as allocating space,
so if you need more than a /64, might as well go to /56 and avoid the mess if a
user needs a 17th subnet.  This isn't IPv4, where you have to actually worry
about burning through your IP allocation doling it out to customers.  Even a
single /32 will service a *lot* of /56's, and I don't think *anybody* is big
enough to actually burn through a /24 allocation (feel free to prove me wrong..
;)



pgpCmriK9WxRR.pgp
Description: PGP signature

Re: IPv6 end user addressing

[Brielle Bruns]

On 8/5/11 10:38 AM, valdis.kletni...@vt.edu wrote:

and I don't think*anybody*  is big
enough to actually burn through a /24 allocation (feel free to prove me wrong..
;)


Never doubt the ability of certain Asian countries to burn through IP 
space at blistering speed when their citizens can't even directly access 
the internet without going through a massive firewall and proxy system.  :)


--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: IPv6 end user addressing

[Owen DeLong]

/56 is definitely preferable to /64, but, /48 really is a better choice.

/56 is very limiting for autonomous hierarchical deployments.

It's not about number of subnets. It's about the ability to provide some 
flexibility
in the breadth and depth of bit fields used for creating hierarchical topologies
automatically.

Owen

On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote:

> In reviewing IPv6 end user allocation policies, I can find little
> agreement on what prefix length is appropriate for residential end
> users.  /64 and /56 seem to be the favorite candidates, with /56 being
> slightly preferred.
> 
> I am most curious as to why a /60 prefix is not considered when trying
> to address this problem.  It provides 16 /64 subnetworks, which seems
> like an adequate amount for an end user.
> 
> Does anyone have opinions on the BCP for end user addressing in IPv6?



smime.p7s
Description: S/MIME cryptographic signature

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 5, 2011, at 9:29 AM, Mikael Abrahamsson wrote:

> On Fri, 5 Aug 2011, Brian Mengel wrote:
> 
>> In reviewing IPv6 end user allocation policies, I can find little
>> agreement on what prefix length is appropriate for residential end
>> users.  /64 and /56 seem to be the favorite candidates, with /56 being
>> slightly preferred.
> 
> Not slightly preferred, very much preferred. /56 is future proof and works 
> for "everybody". /64 is short sighted and doesn't allow for multiple networks 
> in the home.
> 
I would say /56 is slightly preferred and that /48 is very much preferred.

>> I am most curious as to why a /60 prefix is not considered when trying
>> to address this problem.  It provides 16 /64 subnetworks, which seems
>> like an adequate amount for an end user.
> 
> Why save on addresses, you can just get more IPv6 addresses if you need them. 
> /56 is allowed per user from all the RIRs afaik.
> 

All RIRs allow /48s actually. Some policies measure in increments of /56, BUT, 
even those policies
consider issuing a customer a /48 to be a valid use of 256 /56s for measurement 
purposes.

>> Does anyone have opinions on the BCP for end user addressing in IPv6?
> 
> Yes, there are plenty of people with opinions.
> 
> This has been hashed over and over and over again, please check the archives 
> for lots of discussions on pros an cons. If you want to do it right, go for 
> /56, it works.
> 

If you really want to do it right, go for /48… It works better.

Owen



smime.p7s
Description: S/MIME cryptographic signature

Re: IPv6 end user addressing

[Valdis . Kletnieks]

On Fri, 05 Aug 2011 10:56:25 MDT, Brielle Bruns said:
> On 8/5/11 10:38 AM, valdis.kletni...@vt.edu wrote:
> > and I don't think*anybody*  is big
> > enough to actually burn through a /24 allocation (feel free to prove me 
> > wrong..
> > ;)
> 
> Never doubt the ability of certain Asian countries to burn through IP 
> space at blistering speed when their citizens can't even directly access 
> the internet without going through a massive firewall and proxy system.  :)

Those cases are probably best handled as a /16 delegation from a regional RIR
to a national RIR or similar. And they can just ULA themselves a /16 for inside
the country if they really feel the need ;)

And yes, I know a single /24 won't quite cover all of Comcast's customers if
they give them all a /48.  They're welcome to prove me wrong by turning up
enough customers on IPv6 to need a second /24. ;)



pgpsWKwr4QNpn.pgp
Description: PGP signature

Re: IPv6 end user addressing

[Doug Barton]

On 08/05/2011 09:17, Brian Mengel wrote:
> In reviewing IPv6 end user allocation policies, I can find little
> agreement on what prefix length is appropriate for residential end
> users.  /64 and /56 seem to be the favorite candidates, with /56 being
> slightly preferred.
> 
> I am most curious as to why a /60 prefix is not considered when trying
> to address this problem.  It provides 16 /64 subnetworks, which seems
> like an adequate amount for an end user.
> 
> Does anyone have opinions on the BCP for end user addressing in IPv6?

You've had a lot of good opinions already, but here's one more vote for
/56 being the absolute minimum.

That said, the strategy I've suggested in the past is to reserve for
each customer the largest block that your RIR will recognize as
reasonable (note, that's reasonable, not theoretically justifiable) for
end user assignment. Then if down the road it turns out that you need
more space and for some unimaginable reason you can't get more from the
RIR you can go back and start bifurcating the blocks you've reserved.

For example, if you reserve a /48 per customer but actually use the
first /56 out of it, you are safe if _you_ need the other /56 for some
reason, or if the customer needs to expand into the full /48.


hth,

Doug

-- 

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

RE: IPv6 end user addressing

[Frank Bulk]

Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be
zeroing in on a /56 for production.  Though some ISPs are using /64 for
their trials.

Frank

-Original Message-
From: Owen DeLong [mailto:o...@delong.com] 
Sent: Friday, August 05, 2011 12:21 PM
To: Brian Mengel
Cc: nanog@nanog.org
Subject: Re: IPv6 end user addressing

/56 is definitely preferable to /64, but, /48 really is a better choice.

/56 is very limiting for autonomous hierarchical deployments.

It's not about number of subnets. It's about the ability to provide some
flexibility
in the breadth and depth of bit fields used for creating hierarchical
topologies
automatically.

Owen

On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote:

> In reviewing IPv6 end user allocation policies, I can find little
> agreement on what prefix length is appropriate for residential end
> users.  /64 and /56 seem to be the favorite candidates, with /56 being
> slightly preferred.
> 
> I am most curious as to why a /60 prefix is not considered when trying
> to address this problem.  It provides 16 /64 subnetworks, which seems
> like an adequate amount for an end user.
> 
> Does anyone have opinions on the BCP for end user addressing in IPv6?

Re: IPv6 end user addressing

[Sascha Lenz]

Hi,


> Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be
> zeroing in on a /56 for production.  Though some ISPs are using /64 for
> their trials.


IIRC, there's RfC6177 - covering almost exactly what the original poster asked 
for.
Not sure if it was mentioned already.

/48 is what IPv6 was designed for, /48 per customer (or even per customer-site 
some might say) is supported by the RIR policies,
and there are close to zero reasons not to use a /48. It also eases your 
administration
processes and also operational things.

Of course, if you only have John Average residential customers or whatever, use 
a /56 or /60.
It's your choice. You know your customers best. We're not in a classful world 
again :-)
But do your math, there is no address shortage, handing out a /48 to every type 
of customer
as a single assignment size should be the sane choice. 
You waste precious time thinking too much about it.

At least don't make your life miserable by experimenting with too many 
different assignment sizes,
or advocate /64s or something, that's considered a design fault which will come 
back to you some day.
Read the RfCs and RIR policy discussions in the archives some years ago. 

-- 
Mit freundlichen Grüßen / Kind Regards

Sascha Lenz [SLZ-RIPE]
Senior System- & Network Architect

Re: IPv6 end user addressing

[Owen DeLong]

I'm not the only person who prefers /48 and hopefully most ISPs will eventually
come around and realize that /56s don't really benefit anyone vs. /48s.

Hurricane Electric has been handing out /48s upon request to our customers and
users of our IPv6 tunnel services. We do not anticipate changing that policy.

Owen

On Aug 5, 2011, at 3:56 PM, Frank Bulk wrote:

> Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be
> zeroing in on a /56 for production.  Though some ISPs are using /64 for
> their trials.
> 
> Frank
> 
> -Original Message-
> From: Owen DeLong [mailto:o...@delong.com] 
> Sent: Friday, August 05, 2011 12:21 PM
> To: Brian Mengel
> Cc: nanog@nanog.org
> Subject: Re: IPv6 end user addressing
> 
> /56 is definitely preferable to /64, but, /48 really is a better choice.
> 
> /56 is very limiting for autonomous hierarchical deployments.
> 
> It's not about number of subnets. It's about the ability to provide some
> flexibility
> in the breadth and depth of bit fields used for creating hierarchical
> topologies
> automatically.
> 
> Owen
> 
> On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote:
> 
>> In reviewing IPv6 end user allocation policies, I can find little
>> agreement on what prefix length is appropriate for residential end
>> users.  /64 and /56 seem to be the favorite candidates, with /56 being
>> slightly preferred.
>> 
>> I am most curious as to why a /60 prefix is not considered when trying
>> to address this problem.  It provides 16 /64 subnetworks, which seems
>> like an adequate amount for an end user.
>> 
>> Does anyone have opinions on the BCP for end user addressing in IPv6?
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 6, 2011, at 12:47 AM, Sascha Lenz wrote:

> Hi,
> 
> 
>> Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be
>> zeroing in on a /56 for production.  Though some ISPs are using /64 for
>> their trials.
> 
> 
> IIRC, there's RfC6177 - covering almost exactly what the original poster 
> asked for.
> Not sure if it was mentioned already.
> 
RFC6177 sort of appears to recommend /56 if you don't look at it too closely.

What it really says is essentially "The IETF throws its hands up in the air and
refuses to make any recommendations in this arena leaving the entire thing
to RIRs and service providers where we probably should have put it in the
first place."

> /48 is what IPv6 was designed for, /48 per customer (or even per 
> customer-site some might say) is supported by the RIR policies,
> and there are close to zero reasons not to use a /48. It also eases your 
> administration
> processes and also operational things.
> 
AMEN, Brother! ;-)

> Of course, if you only have John Average residential customers or whatever, 
> use a /56 or /60.
> It's your choice. You know your customers best. We're not in a classful world 
> again :-)
> But do your math, there is no address shortage, handing out a /48 to every 
> type of customer
> as a single assignment size should be the sane choice. 
> You waste precious time thinking too much about it.
> 
Yep. Even if you only have John Average residential customer. Residential 
customers today are
not going to be the same as residential customers in 5, 15, or 25 years. Giving 
them /48s will save
you (and them) a lot of heartache down the road. (and yes, I mean a /48 per end 
site structure or
per tenant in a multi-tenant structure).

> At least don't make your life miserable by experimenting with too many 
> different assignment sizes,
> or advocate /64s or something, that's considered a design fault which will 
> come back to you some day.
> Read the RfCs and RIR policy discussions in the archives some years ago. 
> 

Also, please don't make your life miserable by trying to align things on odd 
bit boundaries. Stick
to nibbles.

Owen



smime.p7s
Description: S/MIME cryptographic signature

Re: IPv6 end user addressing

[Jeff Wheeler]

On Sat, Aug 6, 2011 at 5:21 AM, Owen DeLong  wrote:
>> At least don't make your life miserable by experimenting with too many 
>> different assignment sizes,
>> or advocate /64s or something, that's considered a design fault which will 
>> come back to you some day.
>> Read the RfCs and RIR policy discussions in the archives some years ago.

Note that in this thread, you advocate three things that are a little
tough to make work together:
* hierarchical addressing plan / routing
* nibble-aligned addressing plan
* minimum /48 per customer

If I were, for example, a hosting company with IPv6 terminated at the
layer-3 ToR switch, I would then use a /40 per rack of typical
"dedicated servers."  If you then want some bits to be a POP-locator
field for your hierarchical routing scheme, you are already forced to
request more than a /32.  The number of customers per layer-3 device
for typical end-user access networks was around the same into the
late-1990s/early-2000s, as ISPs had racks of Portmasters or whatever
box of choice for terminating dial-up.

Densities have changed, but this doesn't necessarily win you an
advantage when combining those three properties.  This is especially
true if you consider that density may change in a difficult-to-predict
manner in the future -- a BRAS box with a couple thousand customers
today might have three times as many in a couple of years (IPv6 is
supposed to help us avoid renumbering or injecting additional routes
into our network, right?)  As an access provider, if I shared your
view, I would be reserving a /36 or /32 per BRAS box.  If I then want
some additional bits for hierarchical routing ... I'm going to need a
pretty large address block for perhaps a pretty small number of
customers.  After all, my scheme, applying your logic, dictates that I
should use a /32 or perhaps a /28 per each POP or city (I need to plan
for several BRAS each), even if I don't have a lot of customers today!

I think /56 is more sensible than /48, given the above, for most
end-users.  Either way, the users will be gaining a lot more
flexibility than they have with IPv4 today, where they probably get
just one IP address and have to pay a fee for any extras.  Giving the
typical end-user 8 fewer bits worth of address space allows the ISP
network more flexibility for hierarchical routing before they have to
go to their RIR and figure out how to justify an out-sized allocation.

Also, if folks would stop thinking that every subnet should be a /64,
they will see that end-users, makers of set-top-gateways, or whatever,
can certainly address a whole lot of devices in a whole lot of subnets
even if the user is only given a /64.  Do we think DHCPv6 won't be the
most common way of assigning addresses on SOHO LANs, and that SLAAC
will be essential?  I, for one, think that some ISPs will be sick and
twisted enough to hand out /128s so they can continue charging for
more IP addresses; but certainly the makers of IPv6-enabled devices
will foresee that end-user LANs might not be /64 and include the
necessary functionality to work correctly with smaller subnets.

Before you beat me to it, yes, we seem to have completely opposing
views on this subject.  I will change my mind when I can go to the RIR
and get a IPv6 /24 for a small ISP with a few POPs and a few tens of
thousands of customers.  Should RIR policy permit that sort of thing?

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: IPv6 end user addressing

[Mukom Akong Tamon]

On Fri, Aug 5, 2011 at 11:18 PM, Doug Barton  wrote:
> For example, if you reserve a /48 per customer but actually use the
> first /56 out of it, you are safe if _you_ need the other /56 for some
> reason, or if the customer needs to expand into the full /48.

+1. Be generous in planning and then assign what makes operational
sense. Be sure to make sure that as you dole out smaller than blocks
to customers that requested from your RIR, you preserve your ability
to give a client a second block from the same aggregatable range.



-- 
Mukom Akong Tamon
___
"A man owns nothing, not land or money, only his character, the
loyalty & courage in his heart" - Commander Chakotay - StarTrek
Voyager


[In Search of Excellence & Perfection] - http://perfexcellence.org
[Moments of TechXcellence] - http://techexcellence.net
[ICT Business Integration] - http://ibiztech.wordpress.com
[Leadership Lessons from Movies] - http://thbs.wordpress.com

Re: IPv6 end user addressing

[Cameron Byrne]

On Aug 6, 2011 2:11 AM, "Owen DeLong"  wrote:
>
> I'm not the only person who prefers /48 and hopefully most ISPs will
eventually
> come around and realize that /56s don't really benefit anyone vs. /48s.
>
> Hurricane Electric has been handing out /48s upon request to our customers
and
> users of our IPv6 tunnel services. We do not anticipate changing that
policy.
>
> Owen
>

A lot of good that /48 will do while HE rides out their on going peering war
and customers are missing a wide swath of the ipv6 routing table.

Cb

> On Aug 5, 2011, at 3:56 PM, Frank Bulk wrote:
>
> > Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be
> > zeroing in on a /56 for production.  Though some ISPs are using /64 for
> > their trials.
> >
> > Frank
> >
> > -Original Message-
> > From: Owen DeLong [mailto:o...@delong.com]
> > Sent: Friday, August 05, 2011 12:21 PM
> > To: Brian Mengel
> > Cc: nanog@nanog.org
> > Subject: Re: IPv6 end user addressing
> >
> > /56 is definitely preferable to /64, but, /48 really is a better choice.
> >
> > /56 is very limiting for autonomous hierarchical deployments.
> >
> > It's not about number of subnets. It's about the ability to provide some
> > flexibility
> > in the breadth and depth of bit fields used for creating hierarchical
> > topologies
> > automatically.
> >
> > Owen
> >
> > On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote:
> >
> >> In reviewing IPv6 end user allocation policies, I can find little
> >> agreement on what prefix length is appropriate for residential end
> >> users.  /64 and /56 seem to be the favorite candidates, with /56 being
> >> slightly preferred.
> >>
> >> I am most curious as to why a /60 prefix is not considered when trying
> >> to address this problem.  It provides 16 /64 subnetworks, which seems
> >> like an adequate amount for an end user.
> >>
> >> Does anyone have opinions on the BCP for end user addressing in IPv6?
> >
>

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 6, 2011, at 3:15 AM, Jeff Wheeler wrote:

> On Sat, Aug 6, 2011 at 5:21 AM, Owen DeLong  wrote:
>>> At least don't make your life miserable by experimenting with too many 
>>> different assignment sizes,
>>> or advocate /64s or something, that's considered a design fault which will 
>>> come back to you some day.
>>> Read the RfCs and RIR policy discussions in the archives some years ago.
> 
> Note that in this thread, you advocate three things that are a little
> tough to make work together:
> * hierarchical addressing plan / routing
> * nibble-aligned addressing plan
> * minimum /48 per customer
> 
Hasn't been hard so far.

> If I were, for example, a hosting company with IPv6 terminated at the
> layer-3 ToR switch, I would then use a /40 per rack of typical
> "dedicated servers."  If you then want some bits to be a POP-locator
> field for your hierarchical routing scheme, you are already forced to
> request more than a /32.  The number of customers per layer-3 device
> for typical end-user access networks was around the same into the
> late-1990s/early-2000s, as ISPs had racks of Portmasters or whatever
> box of choice for terminating dial-up.
> 

I think we were talking about access customers. I don't see giving /48s
to individual dedicated servers as I don't see them having hierarchy
behind them. I would think that a /48 per TOR switch would be
reasonable in that case.

However, requesting more than a /32 is perfectly reasonable. In
the ARIN region, policy 2011-3.

> Densities have changed, but this doesn't necessarily win you an
> advantage when combining those three properties.  This is especially
> true if you consider that density may change in a difficult-to-predict
> manner in the future -- a BRAS box with a couple thousand customers
> today might have three times as many in a couple of years (IPv6 is
> supposed to help us avoid renumbering or injecting additional routes
> into our network, right?)  As an access provider, if I shared your
> view, I would be reserving a /36 or /32 per BRAS box.  If I then want
> some additional bits for hierarchical routing ... I'm going to need a
> pretty large address block for perhaps a pretty small number of
> customers.  After all, my scheme, applying your logic, dictates that I
> should use a /32 or perhaps a /28 per each POP or city (I need to plan
> for several BRAS each), even if I don't have a lot of customers today!
> 
Correct… I think a /36 per BRAS seems about right, but if you want
to put more than 3072 customers on a single BRAS and expect
technology to eventually support that, sure, go for a /32 per BRAS.
If you want to isolate your routing down to per BRAS (most providers
I'm aware of that have multiple BRAS have it set up so any customer
in a given POP may connect to any BRAS and they carry the
customer prefixes within the POP's routing table), then, I think a
/36 per BRAS is probably OK (up to 3072 customers at 75%
utilization, 4096 max), but, if you really think you will have 6,000
customer BRAS units, then, yes, a /32 would be correct.

However, I would be more likely to assign hierarchy per POP
instead. Figure out how many customers are likely in my
largest POP and allocate based on /48 per customer+growth
in that POP. For example, if my largest POP would serve 2,000
customer end-sites, I'd be looking at a /36 per POP. If the largest
POP served 3,073 customer end-sites or even 49,000 customer
end-sites, I'd plan on a /32 per POP.

Basically take the number of customer end-sites in your largest
POP, divide by 0.75 (keep 25% headroom minimum) and then
round up to the nearest nibble.

If you really think you will have more than 786,432 customer
sites served from your largest POP, then, I suppose a /28 per
POP is a reasonable request. That seems like pretty unlikely
density, even in 20 years. I realize that customer density in
urban areas does tend to increase, but, assuming a maximum
50% market penetration, serving a city the size of Philadelphia
out of a single POP still seems unlikely to me.

> I think /56 is more sensible than /48, given the above, for most
> end-users.  Either way, the users will be gaining a lot more
> flexibility than they have with IPv4 today, where they probably get
> just one IP address and have to pay a fee for any extras.  Giving the
> typical end-user 8 fewer bits worth of address space allows the ISP
> network more flexibility for hierarchical routing before they have to
> go to their RIR and figure out how to justify an out-sized allocation.
> 
Why? You point out that giving out /48s would require larger IPv6
allocations than /32, but, you don't give any reason to think this is
bad.

Let's look at the math. Let's assume a moderately large provider
expects to serve 45,000 customer end-sites out of their largest
POP (does anyone actually expect numbers this large in a
single POP)?

Now, let's say you have 50 POPs across your service region
and expect to triple in size over the next 5 years. That's 150
total 

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 6, 2011, at 3:40 AM, Mukom Akong Tamon wrote:

> On Fri, Aug 5, 2011 at 11:18 PM, Doug Barton  wrote:
>> For example, if you reserve a /48 per customer but actually use the
>> first /56 out of it, you are safe if _you_ need the other /56 for some
>> reason, or if the customer needs to expand into the full /48.
> 
> +1. Be generous in planning and then assign what makes operational
> sense. Be sure to make sure that as you dole out smaller than blocks
> to customers that requested from your RIR, you preserve your ability
> to give a client a second block from the same aggregatable range.
> 

The way to address this better is to use allocation by bisection to your
customers rather than giving them /56s.

If you give a site a /48, it is very unlikely they will ever need an additional
prefix for that site. Of course if you're talking about a customer that is
using a single connection to you to feed multiple sites, that's a different
issue and will require additional planning.

For anyone that already understands allocation by bisection, you can
skip the rest of this message.

What I mean by allocation by bisection is simply issuing prefixes such
that each issued prefix has the largest possible contiguous aligned
space available for expansion. Let's assume 2001:db8::/32 as our
starting point and that we are assigning /48s to 50 end sites from it.
(I'm skipping the whole hierarchy to fit inside a /32 and keep the example
simple).

We'd assign 2001:db8::/48 for our own infrastructure and support machines.
The first customer would get 2001:db8:8000::/48.
The next customer would get 2001:db8:4000::/48, then 2001:db8:c000::/48.
In the next round, we'd assign 2001:db8:2000::/48, 2001:db8:6000::/48,
2001:db8:a000::/48 and 2001:db8:e000::/48
This would be followed by …1000::/48, …3000::/48, …5000::/48, …7000::/48,
…9000::/48, …b000::/48, …d000::/48, and …f000::/48.

At this point, we've assigned 15 customers, and each of them could be
expanded from /48 to /36 without invading any of our existing assignments.

Continuing, we would assign the next 16 customers as:

2001:db8:0800::/48, 2001:db8:1800::/48, 2001:db8:2800::/48,
2001:db8:3800::/48, 2001:db8:4800::/48, 2001:db8:5800::/48,
2001:db8:6800::/48, 2001:db8:7800::/48, 2001:db8:8800::/48,
2001:db8:9800::/48, 2001:db8:a800::/48, 2001:db8:b800::/48,
2001:db8:c800::/48, 2001:db8:d800::/48, 2001:dbu:e800::/48,
2001:db8:f800::/48

That brings us to 31 customers all of whom have room to expand
their /48 up to a /37 (though I wouldn't recommend doing /37s
as they are not nibble-aligned, so, outside of exceptional circumstances,
you would be unlikely to expand in place beyond /40 at this point.)

The next 32 customers would fill in the 2001:db8:?400::/48 ranges
and the 2001:db8:?c00::/48 ranges. This limits those customers
now to /38s.

Owen




smime.p7s
Description: S/MIME cryptographic signature

Re: IPv6 end user addressing

[Joel Jaeggli]

On Aug 5, 2011, at 3:56 PM, Frank Bulk wrote:

> Let's clarify -- /48 is much preferred by Owen,

It's is also supported by RIR policy, and the RFC series. It would unfair to 
characterize owen as the only holder of that preference.

> but most ISPs seem to be
> zeroing in on a /56 for production.  Though some ISPs are using /64 for
> their trials.
> 
> Frank
> 
> -Original Message-
> From: Owen DeLong [mailto:o...@delong.com] 
> Sent: Friday, August 05, 2011 12:21 PM
> To: Brian Mengel
> Cc: nanog@nanog.org
> Subject: Re: IPv6 end user addressing
> 
> /56 is definitely preferable to /64, but, /48 really is a better choice.
> 
> /56 is very limiting for autonomous hierarchical deployments.
> 
> It's not about number of subnets. It's about the ability to provide some
> flexibility
> in the breadth and depth of bit fields used for creating hierarchical
> topologies
> automatically.
> 
> Owen
> 
> On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote:
> 
>> In reviewing IPv6 end user allocation policies, I can find little
>> agreement on what prefix length is appropriate for residential end
>> users.  /64 and /56 seem to be the favorite candidates, with /56 being
>> slightly preferred.
>> 
>> I am most curious as to why a /60 prefix is not considered when trying
>> to address this problem.  It provides 16 /64 subnetworks, which seems
>> like an adequate amount for an end user.
>> 
>> Does anyone have opinions on the BCP for end user addressing in IPv6?
> 
> 
> 

Re: IPv6 end user addressing

[William Herrin]

On Fri, Aug 5, 2011 at 12:17 PM, Brian Mengel  wrote:
> In reviewing IPv6 end user allocation policies, I can find little
> agreement on what prefix length is appropriate for residential end
> users.  /64 and /56 seem to be the favorite candidates, with /56 being
> slightly preferred.

Hi Brian,

/64 is *strongly* discouraged. I'd go so far as to say that when we
look back 3 years from now, anybody who assigned /64's to end user
networks will be considered short-sighted bordering on foolish. Assign
a /128 if you know the downstream is exactly 1 host (not a LAN, not a
PC with virtual machines, exactly one computer) or else assign at
least a /60.


> I am most curious as to why a /60 prefix is not considered when trying
> to address this problem.  It provides 16 /64 subnetworks, which seems
> like an adequate amount for an end user.

Every time someone needs more than the standard assignment, you have
to make a custom assignment with the manpower cost to make it and
maintain it. This will happen often with /64, occasionally with /60
and rarely with /56.

On the flip side, /56 allows for 16M end-users in your /32 ISP
allocation. After which you can trivially get as many additional /32's
as you want. Is there any reason you want to super-optimize to get
268M end-users squashed in that /32?

Regards,
Bill Herrin

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv6 end user addressing

[Jimmy Hess]

On Sat, Aug 6, 2011 at 1:28 PM, William Herrin  wrote:

> On Fri, Aug 5, 2011 at 12:17 PM, Brian Mengel  wrote:
>


> On the flip side, /56 allows for 16M end-users in your /32 ISP
> allocation. After which you can trivially get as many additional /32's
> as you want. Is there any reason you want to super-optimize to get
> 268M end-users squashed in that /32?
>

Arguably,  if you only have one /32,  and you ever get  65,536 customers
each with a /48,  getting as many /32s as you need should be no problem,
also.

But you might want to give them /56s,   so you have more bits  to logically
divide those customers by  region,  or   some other criteria  to enable
more efficient aggregation.

That's the problem with the RIR's choice of  issuing  only  /32s  from which
/48s are to be assigned.
The customer has  80 bits to work with  in organizing their hosts.

But the ISP has only 16 bits  in a /32  to work with.

--
-JH

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 6, 2011, at 11:44 AM, Jimmy Hess wrote:

> On Sat, Aug 6, 2011 at 1:28 PM, William Herrin  wrote:
> 
>> On Fri, Aug 5, 2011 at 12:17 PM, Brian Mengel  wrote:
>> 
> 
> 
>> On the flip side, /56 allows for 16M end-users in your /32 ISP
>> allocation. After which you can trivially get as many additional /32's
>> as you want. Is there any reason you want to super-optimize to get
>> 268M end-users squashed in that /32?
>> 
> 
> Arguably,  if you only have one /32,  and you ever get  65,536 customers
> each with a /48,  getting as many /32s as you need should be no problem,
> also.
> 
> But you might want to give them /56s,   so you have more bits  to logically
> divide those customers by  region,  or   some other criteria  to enable
> more efficient aggregation.
> 
Policy supports you getting those bits left of the /32 instead now.

Look at ARIN 2011-3 which was adopted and ratified by the board and
is awaiting implementation by staff.

If you like this idea, support APNIC prop 98, too, please.

> That's the problem with the RIR's choice of  issuing  only  /32s  from which
> /48s are to be assigned.
> The customer has  80 bits to work with  in organizing their hosts.
> 

The /32 is only the default minimum for an ISP. A small ISP can probably work
with 16 bits. Larger ISPs were always expected to get more than a /32.

> But the ISP has only 16 bits  in a /32  to work with.
> 

Only if they're very small or not very intelligent in their RIR application.

Owen



smime.p7s
Description: S/MIME cryptographic signature

Re: IPv6 end user addressing

[Jeff Wheeler]

On Sat, Aug 6, 2011 at 12:36 PM, Owen DeLong  wrote:
> On Aug 6, 2011, at 3:15 AM, Jeff Wheeler wrote:
>> Note that in this thread, you advocate three things that are a little
>> tough to make work together:
>> * hierarchical addressing plan / routing
>> * nibble-aligned addressing plan
>> * minimum /48 per customer
>>
> Hasn't been hard so far.

Well, you aren't actually doing this on your network today.  If you
practiced what you are preaching, you would not be carrying aggregate
routes to your tunnel broker gateways across your whole backbone.
Perhaps you also wouldn't use one allocation on the tunnel broker
gateway for /64s and another, a /37 in the case of Ashburn for
example, for users who self-provision a /48 from it.  Also, of course,
your default assignment plan is /64, not /48, even though there are
typically around, what, 10k tunnels active network-wide?

To be clear, you don't do any of the three things you advocate above
where Hurricane Electric's tunnel broker service is concerned.

> I think we were talking about access customers. I don't see giving /48s
> to individual dedicated servers as I don't see them having hierarchy
> behind them. I would think that a /48 per TOR switch would be
> reasonable in that case.

I wish there was more discussion about IPv6 addressing plans in
hosting environments on this list.  I think that, rarely, customers
will decide to tunnel from their home or office to their "dedicated
server," co-lo rack, etc.  My addressing policies provide for this
type of customer to receive a /56 upon request without breaking my
hierarchical addressing scheme.  If they need more than that, the
layer-3 aggregator has to inject an additional route into the POP
area.  If a whole bunch of customers on one aggregator ask for /56,
then the aggregator needs an extra /48 (which might really mean
growing its existing /48 to a shorter route.)

> However, requesting more than a /32 is perfectly reasonable. In
> the ARIN region, policy 2011-3.

My read of that policy, and please correct me if I misunderstand, is
that it recognizes only a two-level hierarchy.  This would mean that
an ISP could use some bits to represent a geographic region, a POP, or
an aggregation router / address pool, but it does not grant them
justification to reserve bits for all these purposes.

> density, even in 20 years. I realize that customer density in
> urban areas does tend to increase, but, assuming a maximum
> 50% market penetration, serving a city the size of Philadelphia
> out of a single POP still seems unlikely to me.

AT&T serves some entire states out of a single POP, as far as layer-3
termination is concerned.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 6, 2011, at 1:14 PM, Jeff Wheeler wrote:

> On Sat, Aug 6, 2011 at 12:36 PM, Owen DeLong  wrote:
>> On Aug 6, 2011, at 3:15 AM, Jeff Wheeler wrote:
>>> Note that in this thread, you advocate three things that are a little
>>> tough to make work together:
>>> * hierarchical addressing plan / routing
>>> * nibble-aligned addressing plan
>>> * minimum /48 per customer
>>> 
>> Hasn't been hard so far.
> 
> Well, you aren't actually doing this on your network today.  If you
> practiced what you are preaching, you would not be carrying aggregate
> routes to your tunnel broker gateways across your whole backbone.

Yes we would.

> Perhaps you also wouldn't use one allocation on the tunnel broker
> gateway for /64s and another, a /37 in the case of Ashburn for
> example, for users who self-provision a /48 from it.  Also, of course,
> your default assignment plan is /64, not /48, even though there are
> typically around, what, 10k tunnels active network-wide?
> 

Those are artifacts of a small allocation (/32) from a prior RIR policy.
The fact that those things haven't worked out so well for us was one of
the motivations behind developing policy 2011-3.

> To be clear, you don't do any of the three things you advocate above
> where Hurricane Electric's tunnel broker service is concerned.
> 

Yes we do.

We give a minimum /48 per customer with the small exception that
customers who only want one subnet get a /64.

We will be implementing a nibble-aligned addressing plan as soon as
we can get enough space from the RIR. That's pending implementation
of 2011-3.

We do have a hierarchical addressing plan. I said nothing about routing,
but, we certainly could implement hierarchical routing if we arrived at a
point where it was advantageous because we have designed for it.

>> I think we were talking about access customers. I don't see giving /48s
>> to individual dedicated servers as I don't see them having hierarchy
>> behind them. I would think that a /48 per TOR switch would be
>> reasonable in that case.
> 
> I wish there was more discussion about IPv6 addressing plans in
> hosting environments on this list.  I think that, rarely, customers
> will decide to tunnel from their home or office to their "dedicated
> server," co-lo rack, etc.  My addressing policies provide for this
> type of customer to receive a /56 upon request without breaking my
> hierarchical addressing scheme.  If they need more than that, the
> layer-3 aggregator has to inject an additional route into the POP
> area.  If a whole bunch of customers on one aggregator ask for /56,
> then the aggregator needs an extra /48 (which might really mean
> growing its existing /48 to a shorter route.)
> 

Sounds like a mess. We'll stick with /48s for people that need more
than a /64.

>> However, requesting more than a /32 is perfectly reasonable. In
>> the ARIN region, policy 2011-3.
> 
> My read of that policy, and please correct me if I misunderstand, is
> that it recognizes only a two-level hierarchy.  This would mean that
> an ISP could use some bits to represent a geographic region, a POP, or
> an aggregation router / address pool, but it does not grant them
> justification to reserve bits for all these purposes.
> 

While that's theoretically true, the combination of 25% minfree ,
nibble boundaries, and equal sized allocations for all POPs based
on your largest one allows for that in practical terms in most
circumstances.

>> density, even in 20 years. I realize that customer density in
>> urban areas does tend to increase, but, assuming a maximum
>> 50% market penetration, serving a city the size of Philadelphia
>> out of a single POP still seems unlikely to me.
> 
> AT&T serves some entire states out of a single POP, as far as layer-3
> termination is concerned.
> 

Are any of the states with populations larger than Philadelphia among
them?

Owen



smime.p7s
Description: S/MIME cryptographic signature

Re: IPv6 end user addressing

[Joel Jaeggli]

On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote:

> In reviewing IPv6 end user allocation policies, I can find little
> agreement on what prefix length is appropriate for residential end
> users.  /64 and /56 seem to be the favorite candidates, with /56 being
> slightly preferred.
> 
> I am most curious as to why a /60 prefix is not considered when trying
> to address this problem.  It provides 16 /64 subnetworks, which seems
> like an adequate amount for an end user.
> 
> Does anyone have opinions on the BCP for end user addressing in IPv6?

When you have a device that delegates, e.g. a cpe taking it's assigned prefix, 
and delegating a fraction of it to a downstream device, you need enough bits 
that you can make them out, possibly more than once. if you want that to happen 
automatically you want enough bits that user-intervention is never (for small 
values of never) required in to subnet when connecting devices together...

the homenet wg is exploring how devices in the home might address the issue of 
topology discovery in conjunction with delegation, which realistically home 
networks are going to have to do...

https://www.ietf.org/mailman/listinfo/homenet

Re: IPv6 end user addressing

[Jeff Wheeler]

On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong  wrote:
>> Well, you aren't actually doing this on your network today.  If you
>> practiced what you are preaching, you would not be carrying aggregate
>> routes to your tunnel broker gateways across your whole backbone.
>
> Yes we would.

No, if you actually had a hierarchical addressing scheme, you would
issue tunnel broker customer /64s from the same aggregate prefix that
is used for their /48s.  You'd then summarize at your ABRs so the
entire POP need only inject one route for customer addressing into the
backbone.  Of course, this is not what you do today, and not because
of limited RIR allocation policies -- but because you simply did not
design your network with such route aggregation in mind.

> Those are artifacts of a small allocation (/32) from a prior RIR policy.
> The fact that those things haven't worked out so well for us was one of
> the motivations behind developing policy 2011-3.

There was nothing stopping you from using one /48 out of the /37s you
use to issue customer /48 networks for issuing the default /64 blocks
your tunnel broker hands out.

> We give a minimum /48 per customer with the small exception that
> customers who only want one subnet get a /64.

You assign a /64 by default.  Yes, customers can click a button and
get themselves a /48 instantly, but let's tell the truth when talking
about your current defaults -- customers are assigned a /64, not a
/48.

> We do have a hierarchical addressing plan. I said nothing about routing,
> but, we certainly could implement hierarchical routing if we arrived at a
> point where it was advantageous because we have designed for it.

How have you designed for it?  You already missed easy opportunities
to inject fewer routes into your backbone, simply by using different
aggregate prefixes for customer /64s vs /48s.

>>> However, requesting more than a /32 is perfectly reasonable. In
>>> the ARIN region, policy 2011-3.
>>
>> My read of that policy, and please correct me if I misunderstand, is
>> that it recognizes only a two-level hierarchy.  This would mean that
>> an ISP could use some bits to represent a geographic region, a POP, or
>> an aggregation router / address pool, but it does not grant them
>> justification to reserve bits for all these purposes.
>>
>
> While that's theoretically true, the combination of 25% minfree ,
> nibble boundaries, and equal sized allocations for all POPs based
> on your largest one allows for that in practical terms in most
> circumstances.

I don't think it does allow for that.  I think it requires you to have
at least one "POP prefix" 75% full before you can get any additional
space from the RIR, where 75% full means routed to customers, not
reserved for aggregation router pools.  This is not a hierarchy, it is
simply a scheme to permit ISPs to bank on having at least one level of
summarization in their addressing and routing scheme.

2011-3 does not provide for an additional level to summarize on the
aggregation routers themselves.  It should, but my read is that the
authors have a very different opinion about what "hierarchical"
addressing means than I do.  It should provide for route aggregation
on both the ABR and the aggregation router itself.

>> AT&T serves some entire states out of a single POP, as far as layer-3
>> termination is concerned.
>>
>
> Are any of the states with populations larger than Philadelphia among
> them?

Yes, for example, Indiana.  Pretty much every state in the former
Ameritech service territory.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

RE: IPv6 end user addressing

[Jonathon Exley]

This has probably been said before, but it makes me uncomfortable to think of 
everybody in the world being given /48 subnets by default.
All of a sudden that wide expanse of 2^128 IP addresses shrinks to 2^48 sites. 
Sure that's still 65535 times more than 2^32 IPv4 addresses, but wouldn't it be 
wise to apply some conservatism now to allow the IPv6 address space to last for 
many more years? 
After all, there are only 4 bits of IP version field so the basic packet format 
won't last forever.

Jonathon 

This email and attachments: are confidential; may be protected by
privilege and copyright; if received in error may not be used,copied,
or kept; are not guaranteed to be virus-free; may not express the
views of Kordia(R); do not designate an information system; and do not
give rise to any liability for Kordia(R).

Re: IPv6 end user addressing

[Joel Jaeggli]

On Aug 7, 2011, at 3:09 PM, Jonathon Exley wrote:

> This has probably been said before, but it makes me uncomfortable to think of 
> everybody in the world being given /48 subnets by default.
> All of a sudden that wide expanse of 2^128 IP addresses shrinks to 2^48 
> sites. Sure that's still 65535 times more than 2^32 IPv4 addresses, but 
> wouldn't it be wise to apply some conservatism now to allow the IPv6 address 
> space to last for many more years? 

2000::/3 is 1/8th of the address range. There are other things worth conserving 
 not just /48s like the ability aggregate your whole assignment. 3.5 * 10^13 is 
a lot of /48s, but it's likely not enough so we'll get to crack the seal on 
4000::/3 eventually and so on.

> After all, there are only 4 bits of IP version field so the basic packet 
> format won't last forever.
> 
> Jonathon 
> 
> This email and attachments: are confidential; may be protected by
> privilege and copyright; if received in error may not be used,copied,
> or kept; are not guaranteed to be virus-free; may not express the
> views of Kordia(R); do not designate an information system; and do not
> give rise to any liability for Kordia(R).
> 
> 
> 
> 

Re: IPv6 end user addressing

[David Conrad]

Jonathon,

On Aug 7, 2011, at 12:09 PM, Jonathon Exley wrote:
> This has probably been said before,

Once or twice :-)

> but it makes me uncomfortable to think of everybody in the world being given 
> /48 subnets by default.

This isn't where the worry should be.  Do the math.  Right now, we're 
allocating something like 300,000,000 IPv4 addresses per year with a reasonable 
(handwave) percentage being used as NAT endpoints.  If you cross your eyes 
sufficiently, that can look a bit like 300,000,000 networks being added per 
year.  Translate that to IPv6 and /48s:

There are 35,184,372,088,832 /48s in the format specifier currently defined for 
"global unicast".  For the sake of argument, let's increase the the 'network 
addition' rate by 3 orders of magnitude to 300,000,000,000 per year.  At that 
rate, which is equivalent to allocating 42 /48s per person on the planet per 
year, the current format specifier will last about 100 years. And there are 7 
more format specifiers.

> but wouldn't it be wise to apply some conservatism now to allow the IPv6 
> address space to last for many more years? 

The area to be more conservative is, perhaps unsurprisingly, in the network 
bureaucratic layer.  I believe current allocation policy states an ISP gets a 
minimum of a /32 (allowing them to assign 65536 /48s), but "if justified" an 
ISP can get more.  There have been allocations of all sorts of shorter 
prefixes, e.g., /19s, /18s, and even (much) shorter.  An ISP that has received 
a /19 has the ability to allocate half a billion /48s. And of course, there are 
the same number of /19s, /18s, and even (much) shorter prefixes in IPv6 as 
there are in IPv4...

> After all, there are only 4 bits of IP version field so the basic packet 
> format won't last forever.

True.  There is no finite resource poor policy making can't make scarce.

Regards,
-drc

Re: IPv6 end user addressing

[Mark Andrews]

In message 
, Jeff Wheeler writes:
> On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong  wrote:
> >> Well, you aren't actually doing this on your network today. =A0If you
> >> practiced what you are preaching, you would not be carrying aggregate
> >> routes to your tunnel broker gateways across your whole backbone.
> >
> > Yes we would.
> 
> No, if you actually had a hierarchical addressing scheme, you would
> issue tunnel broker customer /64s from the same aggregate prefix that
> is used for their /48s.  You'd then summarize at your ABRs so the
> entire POP need only inject one route for customer addressing into the
> backbone.  Of course, this is not what you do today, and not because
> of limited RIR allocation policies -- but because you simply did not
> design your network with such route aggregation in mind.
> 
> > Those are artifacts of a small allocation (/32) from a prior RIR policy.
> > The fact that those things haven't worked out so well for us was one of
> > the motivations behind developing policy 2011-3.
> 
> There was nothing stopping you from using one /48 out of the /37s you
> use to issue customer /48 networks for issuing the default /64 blocks
> your tunnel broker hands out.

So you want HE to force all their clients to renumber.

> > We give a minimum /48 per customer with the small exception that
> > customers who only want one subnet get a /64.
> 
> You assign a /64 by default.  Yes, customers can click a button and
> get themselves a /48 instantly, but let's tell the truth when talking
> about your current defaults -- customers are assigned a /64, not a
> /48.

The client can request a /48 or /64 as the initial allocation.
 
> > We do have a hierarchical addressing plan. I said nothing about routing,
> > but, we certainly could implement hierarchical routing if we arrived at a
> > point where it was advantageous because we have designed for it.
> 
> How have you designed for it?  You already missed easy opportunities
> to inject fewer routes into your backbone, simply by using different
> aggregate prefixes for customer /64s vs /48s.
> 
> >>> However, requesting more than a /32 is perfectly reasonable. In
> >>> the ARIN region, policy 2011-3.
> >>
> >> My read of that policy, and please correct me if I misunderstand, is
> >> that it recognizes only a two-level hierarchy. =A0This would mean that
> >> an ISP could use some bits to represent a geographic region, a POP, or
> >> an aggregation router / address pool, but it does not grant them
> >> justification to reserve bits for all these purposes.
> >>
> >
> > While that's theoretically true, the combination of 25% minfree ,
> > nibble boundaries, and equal sized allocations for all POPs based
> > on your largest one allows for that in practical terms in most
> > circumstances.
> 
> I don't think it does allow for that.  I think it requires you to have
> at least one "POP prefix" 75% full before you can get any additional
> space from the RIR, where 75% full means routed to customers, not
> reserved for aggregation router pools.  This is not a hierarchy, it is
> simply a scheme to permit ISPs to bank on having at least one level of
> summarization in their addressing and routing scheme.
> 
> 2011-3 does not provide for an additional level to summarize on the
> aggregation routers themselves.  It should, but my read is that the
> authors have a very different opinion about what "hierarchical"
> addressing means than I do.  It should provide for route aggregation
> on both the ABR and the aggregation router itself.
> 
> >> AT&T serves some entire states out of a single POP, as far as layer-3
> >> termination is concerned.
> >>
> >
> > Are any of the states with populations larger than Philadelphia among
> > them?
> 
> Yes, for example, Indiana.  Pretty much every state in the former
> Ameritech service territory.
> 
> --=20
> Jeff S Wheeler 
> Sr Network Operator=A0 /=A0 Innovative Network Concepts
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPv6 end user addressing

[Jeff Wheeler]

On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews  wrote:
> So you want HE to force all their clients to renumber.

No.  I am simply pointing out that Owen exaggerated when he stated
that he implements the following three practices together on his own
networks:
* hierarchical addressing
* nibble-aligned addressing
* /48 per access customer

You can simply read the last few messages in this thread to learn that
his recommendations on this list are not even practical for his
network today, because as Owen himself says, they are not yet able to
obtain additional RIR allocations.  HE certainly operates a useful,
high-profile tunnel-broker service which is IMO a very great asset to
the Internet at-large; but if you spend a few minutes looking at the
publicly available statistics on this service, they average only
around 10,000 active tunnels across all their tunnel termination boxes
combined.  They have not implemented the policies recommended by Owen
because, as he states, a /32 is not enough.

Do I think the position he advocates will cause the eventual
exhaustion of IPv6?  Well, let's do an exercise:

There has been some rather simplistic arithmetic posted today, 300m
new subnets per year, etc. with zero consideration of address/subnet
utilization efficiency within ISP networks and individual aggregation
router pools.  That is foolish.  We can all pull out a calculator and
figure that 2000::/3 has space for 35 trillion /48 networks.  That
isn't how they will be assigned or routed.

The effect of 2011-3 is that an out-sized ISP like AT&T has every
justification for deciding to allocate 24 bits worth of subnet ID for
their "largest POP," say, one that happens to terminate layer-3
services for all customers in an entire state.  They then have policy
support for allocating the same sized subnet for every other POP, no
matter how small.  After all, the RIR policy permits them to obtain
additional allocations as soon as one POP subnet has become full.

So now you have a huge ISP with a few huge POPs, and a lot of small
ones, justified in assigning the same size aggregate prefix, suitable
for 2^24 subnets, to all those small POPs as well.  How many layer-3
POPs might this huge ISP have?  Any number.  It could be every central
office with some kind of layer-3 customer aggregation router.  It
could even be every road-side hut for FTTH services.  Perhaps they
will decide to address ten thousand POPs this way.

Now the nibble-aligned language in the policy permits them to round up
from 10,000 POPs to 16 bits worth of address space for "POP ID."  So
AT&T is quite justified in requesting:
48 (customer subnet length) - 24 (largest POP subnet ID size) - 16
(POP ID) == a /8 subnet for themselves.

Now you can see how this policy, and addressing scheme, is utterly
brain-dead.  It really does put you (and me, and everyone else) in
real danger of exhausting the IPv6 address space.  All it takes is a
few out-sized ISPs, with one large POP each and a bunch of smaller
ones, applying for the maximum amount of address space permitted them
under 2011-3.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: IPv6 end user addressing

[Randy Carpenter]

 
> >> AT&T serves some entire states out of a single POP, as far as
> >> layer-3
> >> termination is concerned.
> >>
> >
> > Are any of the states with populations larger than Philadelphia
> > among
> > them?
> 
> Yes, for example, Indiana.  Pretty much every state in the former
> Ameritech service territory.
> 

Does AT&T seriously serve the entire state of Indiana from a single POP??? 
Sounds crazy to me.

I have a few customers in Indiana that are small ILECs and they each have 
multiple (2-3) POPs even though they have no more than about 1,000 customers.

-Randy

Re: IPv6 end user addressing

[Valdis . Kletnieks]

On Sun, 07 Aug 2011 20:47:48 EDT, Randy Carpenter said:
> Does AT&T seriously serve the entire state of Indiana from a single POP???
> Sounds crazy to me.

It makes sense if they're managing to bill customers by the cable mile from
their location to the POP.  Imagine a POP in Terre Haute or Indianapolis and
1,500+ customers in the Gary area and another 1K in the South Bend and Fort
Wayne areas...  Of course, some other provider would get a clue and  and offer
the same price per mile "your location to our POP" - after putting a POP in
Gary, South Bend, and Fort Wayne. :)




pgp1Ex5J9sZBv.pgp
Description: PGP signature

Re: IPv6 end user addressing

[Brett Frankenberger]

On Sun, Aug 07, 2011 at 09:45:31PM -0400, valdis.kletni...@vt.edu wrote:
> On Sun, 07 Aug 2011 20:47:48 EDT, Randy Carpenter said:
> > Does AT&T seriously serve the entire state of Indiana from a single POP???
> > Sounds crazy to me.
> 
> It makes sense if they're managing to bill customers by the cable mile from
> their location to the POP.  Imagine a POP in Terre Haute or Indianapolis and
> 1,500+ customers in the Gary area and another 1K in the South Bend and Fort
> Wayne areas...  Of course, some other provider would get a clue and  and offer
> the same price per mile "your location to our POP" - after putting a POP in
> Gary, South Bend, and Fort Wayne. :)

AT&T doesn't serve the entire state of Indiana from a single POP.

The question at hand was how many POPs *with layer 3 service* they had. 
I don't know the answer to that question and don't claim that it is or
is not "one", but the TDM or L2 backhaul from the nearest POP to
whatever other POP has the Layer 3 service isn't paid for by the
customer.

It's also not clear if they were talking about AT&T the LEC (offering
services like DSL) or AT&T the IXC (offering things like business
Internet service, V4VPN services, etc).  If the latter, it's not at all
surprising; legacy IXCs often have more POPs than POPs w/ Layer 3
services, and they backhaul L3 services over their legacy TDM and/or
Layer 2 (ATM or FR) networks to a POP that has a router.  This was a
way for them to get IP service everywhere without installing routers
everywhere; as the service took off, more POPs could be IP enabled to
reduce the about of TDM (etc.) backhaul.  But large legacy IXCs have a
lot of POPs and, in general, still don't have routers (customer facing
routers, anyway) in all of them.

 -- Brett

Re: IPv6 end user addressing

[William Herrin]

On Sun, Aug 7, 2011 at 6:09 PM, Jonathon Exley
 wrote:
> This has probably been said before, but it makes me uncomfortable to think of 
> everybody in the world being given /48 subnets by default.
> All of a sudden that wide expanse of 2^128 IP addresses shrinks to 2^48 
> sites. Sure that's still 65535 times more than 2^32 IPv4 addresses, but 
> wouldn't it be wise to apply some conservatism now to allow the IPv6 address 
> space to last for many more years?
> After all, there are only 4 bits of IP version field so the basic packet 
> format won't last forever.

Hi Jonathan,

IPv6 uses a slightly different mental model when it comes to address allocation.

In IPv4 you assigned blocks of 32-bit addresses. In IPv6 this is no
longer the case. You do not assign blocks of 128-bit addresses.

In IPv6 you assign blocks of 64-bit LANs. Each LAN is 64-bits long as
required by technologies like SLAAC. So, a /48 is 65k LANs, _not_
however many bazillion addresses.

The question you should be asking is: is it excessive or unwise to go
around assigning 65,000 LANs to every customer? Would 256 (/56) or 1
(/64) be a better number?

Assigning 1 LAN seems questionable. We're trying to avoid NAT with
IPv6 which means a customer may want to spend a LAN on things like the
interior network of a virtual machine server. It's hard to do this if
you only have one LAN.

On the other hand, a whole lot of folks have through this through
before you and concluded that a /56 (256 LANs per customer) is a
smarter starting point than a /48.

Regards,
Bill Herrin

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv6 end user addressing

[Mohacsi Janos]

On Fri, 5 Aug 2011, Brian Mengel wrote:


In reviewing IPv6 end user allocation policies, I can find little
agreement on what prefix length is appropriate for residential end
users.  /64 and /56 seem to be the favorite candidates, with /56 being
slightly preferred.

I am most curious as to why a /60 prefix is not considered when trying
to address this problem.  It provides 16 /64 subnetworks, which seems
like an adequate amount for an end user.

Does anyone have opinions on the BCP for end user addressing in IPv6?


For business customers I would give /48 and home users who might have 1-2 
subnet I would give /56 or /60.

Reasons:
- Business customers night grow where you have to provide bigger amount of 
subnet - allow space for future extension -


- Home users - they usually don't know what is subnet. Setting up 
different subnets in their SOHO router can be difficult. Usually the 
simple 1 subnet for every device is enough for them. Separating some 
devices into  a separate subnets is usually enough for the most 
sophisticated home users. If  not then he can opt for business service


Just my 2 cents

Best Regards,
Janos Mohacsi

Re: IPv6 end user addressing

[Valdis . Kletnieks]

On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said:

> - Home users - they usually don't know what is subnet. Setting up 
> different subnets in their SOHO router can be difficult. Usually the 
> simple 1 subnet for every device is enough for them. Separating some 
> devices into  a separate subnets is usually enough for the most 
> sophisticated home users. If  not then he can opt for business service

You don't want to make the assumption that just because Joe Sixpack doesn't
know what a subnet is, that Joe Sixpack's CPE doesn't know either.

And remember that if it's 3 hops from one end of Joe Sixpack's internal net to
the other, you're gonna burn a few bits to support heirarchical routing so you
don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a
/56 by the provider, and it hands each device it sees a /60 in case it's a
device that routes too, it can only support 14 devices.  And if one of the
things that got handed a /60 is a wireless access point or something, it's only
going to be able to support 15 or so subnets. So a simple topology of only a
half dozen devices can burn up 8 bits of subnet addressing real fast. Yes, you
can conserve bits by being more clever, but then you probably need an IGP of
some sort




pgp3hzjjr0ugC.pgp
Description: PGP signature

Re: IPv6 end user addressing

[Mohacsi Janos]

On Mon, 8 Aug 2011, valdis.kletni...@vt.edu wrote:


On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said:


- Home users - they usually don't know what is subnet. Setting up
different subnets in their SOHO router can be difficult. Usually the
simple 1 subnet for every device is enough for them. Separating some
devices into  a separate subnets is usually enough for the most
sophisticated home users. If  not then he can opt for business service


You don't want to make the assumption that just because Joe Sixpack doesn't
know what a subnet is, that Joe Sixpack's CPE doesn't know either.

And remember that if it's 3 hops from one end of Joe Sixpack's internal net to
the other, you're gonna burn a few bits to support heirarchical routing so you
don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a
/56 by the provider, and it hands each device it sees a /60 in case it's a
device that routes too, it can only support 14 devices.  And if one of the


more exactly 16 routing devices. You don't have to count the all 0 and all 
1 as reserved maybe each deeice can see /57 or /58 or /59 
depending of capabilities your devices


I think daisy chaining of CPE routers is bad idea - as probably done in 
several IPv4 home networks. Why would you build several hierarchy into you 
network if it is unnecessary?



Best Regards,
Janos Mohacsi

Re: IPv6 end user addressing

[Mark Andrews]

In message <174561.1312807...@turing-police.cc.vt.edu>, valdis.kletni...@vt.edu
 writes:
> --==_Exmh_1312807411_38980P
> Content-Type: text/plain; charset=us-ascii
> 
> On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said:
> 
> > - Home users - they usually don't know what is subnet. Setting up 
> > different subnets in their SOHO router can be difficult. Usually the 
> > simple 1 subnet for every device is enough for them. Separating some 
> > devices into  a separate subnets is usually enough for the most 
> > sophisticated home users. If  not then he can opt for business service
> 
> You don't want to make the assumption that just because Joe Sixpack doesn't
> know what a subnet is, that Joe Sixpack's CPE doesn't know either.
> 
> And remember that if it's 3 hops from one end of Joe Sixpack's internal net t
> o
> the other, you're gonna burn a few bits to support heirarchical routing so yo
> u
> don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a
> /56 by the provider, and it hands each device it sees a /60 in case it's a
> device that routes too, it can only support 14 devices.  And if one of the
> things that got handed a /60 is a wireless access point or something, it's on
> ly
> going to be able to support 15 or so subnets. So a simple topology of only a
> half dozen devices can burn up 8 bits of subnet addressing real fast. Yes, yo
> u
> can conserve bits by being more clever, but then you probably need an IGP of
> some sort

Which is why CPE devices shouldn't do heirarchical assignment by default.
PD supports multiple upstream requests.  

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPv6 end user addressing

[Valdis . Kletnieks]

On Mon, 08 Aug 2011 16:12:00 +0200, Mohacsi Janos said:
>  You don't have to count the all 
> 0 and all
> 1 as reserved maybe each deeice can see /57 or /58 or /59
> depending of capabilities your devices

As I said further down the note - you can conserve bits but then it gets more
complicated.  You don't want to go to a static "subdivide whatever you got 16
ways if you can", you have to get more clever.  Sure, that one device may only
need a /61 right now because there's only 3 devices behind it.  So the upstream
bridge allocates the first /61 to that device, and allocates the next /63 to 
the next
device that comes online.  Then somebody adds a 4th device to that first router
and now it needs a /60, but you can't just expand the allocation to a /60
because somebody is in the way.  Somebody's gonna have to renumber.

Or you can just say "I can support 16 devices so I need 4 bits of space".  Or
you can bite the bullet and do something more clever.

> I think daisy chaining of CPE routers is bad idea - as probably done in
> several IPv4 home networks. Why would you build several hierarchy into you
> network if it is unnecessary?

Because we're talking Joe Sixpack here - and he can't *spell* hierarchy.  All
he knows is that he's got one box that his cable company sent him, then he
plugged his wireless access point into the cable company box, then he plugged
all the stuff in the media center into a box and connected that box to the
cable company box (He couldn't plug it all into the cable company box because
that only had 4 RJ45's, and one got used for the wireless, and he's got 9(*)
things in the media center that have RJ45s).  You're at 2 levels of heirarchy
already.  Now if he decides to get lazy and not run a cable to the upstairs
bedroom he wants to use as a home office, and gets another box that's really
similar to the on in his media center except it will do wirelesss, he just
added a third level of heirarchy.

And I don't think that's an at all unreasonable scenario.  Feel free to
redesign that network to get rid of one level, let me know what you ended up
doing.  Oh, and explain it in terms Joe Sixpack can understand. ;)

(*) Yes, 9 isn't at all unreasonable - I know plenty of people that have
a Wii, a PS/2, a PS/3, an XBox, a TV that will talk to the Internet, a DVR
that wants to talk to the Internet, and a PC. That's 7 already.

On Tue, 09 Aug 2011 00:18:57 +1000, Mark Andrews said:
> In message <174561.1312807...@turing-police.cc.vt.edu>, 
> valdis.kletni...@vt.edu
> > half dozen devices can burn up 8 bits of subnet addressing real fast. Yes, 
> > you
> > can conserve bits by being more clever, but then you probably need an IGP of
> > some sort
>
> Which is why CPE devices shouldn't do heirarchical assignment by default.
> PD supports multiple upstream requests.

As I said - you can conserve bits using PD or similar, but then you need a
routing solution - you can use PD to hand out prefixes, but then you still need
routing.  Consider the case above - the wireless box asks for a prefix
delegation, then the media center box asks for one. Then the home office asks
for one - and now you need to make sure there's a way for the stuff behind the
media center box to know that to get to the printer that''s hanging off the
home office box, it has to route to the wireless box.

Anybody got gear that can do that and is ready for Joe Sixpack?



pgpDE2rtvOZrO.pgp
Description: PGP signature

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 7, 2011, at 12:00 PM, Jeff Wheeler wrote:

> On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong  wrote:
>>> Well, you aren't actually doing this on your network today.  If you
>>> practiced what you are preaching, you would not be carrying aggregate
>>> routes to your tunnel broker gateways across your whole backbone.
>> 
>> Yes we would.
> 
> No, if you actually had a hierarchical addressing scheme, you would
> issue tunnel broker customer /64s from the same aggregate prefix that
> is used for their /48s.  You'd then summarize at your ABRs so the
> entire POP need only inject one route for customer addressing into the
> backbone.  Of course, this is not what you do today, and not because
> of limited RIR allocation policies -- but because you simply did not
> design your network with such route aggregation in mind.
> 
You are, once again, conflating two related, but, not identical terms.

A hierarchical addressing scheme is NOT a hierarchical routing structure
and vice versa. Yes, a hierarchical routing scheme requires a hierarchical
addressing scheme, but, a hierarchical addressing scheme does NOT
require a hierarchical routing scheme.

We have a hierarchical addressing scheme. The fact that you dont' like
our idea of having two parallel hierarchies for two different addressing
structures is also getting in the way here.

For us, using parallel similar hierarchies for the /64 and /48 prefix blocks
works quite well and produces certain scaling advantages in our system.

As to the details of how our IGP works. I'm not going to debate that
with you because it is an internal matter and not really part of this
discussion. If you want to talk in the abstract about good ways to structure
routing, I'm happy to do that. However, it's a different (though related
as described above) subject from hierarchical addressing.

>> Those are artifacts of a small allocation (/32) from a prior RIR policy.
>> The fact that those things haven't worked out so well for us was one of
>> the motivations behind developing policy 2011-3.
> 
> There was nothing stopping you from using one /48 out of the /37s you
> use to issue customer /48 networks for issuing the default /64 blocks
> your tunnel broker hands out.
> 

I was talking about the fact we were using /37s.

We have actually recognized significant advantages from using
different prefix blocks to assign /48s and /64s in the environment and
I don't expect us to change that practice even when we do get enough
address space to build out the hierarchy the way we want.

Those advantages, however, may well be unique to our tunnelbroker
structure and may not be applicable to other networks.

>> We give a minimum /48 per customer with the small exception that
>> customers who only want one subnet get a /64.
> 
> You assign a /64 by default.  Yes, customers can click a button and
> get themselves a /48 instantly, but let's tell the truth when talking
> about your current defaults -- customers are assigned a /64, not a
> /48.
> 

We assign a /64 by default only to tunnelbroker customers and to
customers without routers in our datacenters. I believe all others
default to a /48 per site.

I told the truth... We give a minimum /48 per customer with the small
exception that customers who only want one subnet get a /64. If you
didn't want only one subnet, presumably you would click the button
to get your instant /48.

>> We do have a hierarchical addressing plan. I said nothing about routing,
>> but, we certainly could implement hierarchical routing if we arrived at a
>> point where it was advantageous because we have designed for it.
> 
> How have you designed for it?  You already missed easy opportunities
> to inject fewer routes into your backbone, simply by using different
> aggregate prefixes for customer /64s vs /48s.
> 

You are correct... With present hind-sight, we could have designed things
in such a way that we could have cut the number of aggregates to be
injected into the backbone from 50 to 25. Assuming that our network
doubles in size every year for the next 4 years, that would take us to
a total of 800 routes that could be 400. OTOH, since we get some other
advantages from this relatively small increment in prefixes, I think
we'll probably stick with the architecture we have for the advantages
it offers in other areas.

Reducing prefix count is not the only consideration in running a network.

 However, requesting more than a /32 is perfectly reasonable. In
 the ARIN region, policy 2011-3.
>>> 
>>> My read of that policy, and please correct me if I misunderstand, is
>>> that it recognizes only a two-level hierarchy.  This would mean that
>>> an ISP could use some bits to represent a geographic region, a POP, or
>>> an aggregation router / address pool, but it does not grant them
>>> justification to reserve bits for all these purposes.
>>> 
>> 
>> While that's theoretically true, the combination of 25% minfree ,
>> nibble boundaries, and equal sized allocations for 

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 7, 2011, at 3:09 PM, Jonathon Exley wrote:

> This has probably been said before, but it makes me uncomfortable to think of 
> everybody in the world being given /48 subnets by default.
> All of a sudden that wide expanse of 2^128 IP addresses shrinks to 2^48 
> sites. Sure that's still 65535 times more than 2^32 IPv4 addresses, but 
> wouldn't it be wise to apply some conservatism now to allow the IPv6 address 
> space to last for many more years? 
> After all, there are only 4 bits of IP version field so the basic packet 
> format won't last forever.
> 

Let's look at this realistically.

In 30+ years of internet development, giving IP addresses to lots of things 
besides just single sites, we still haven't
completely used up the 32 bit space. This includes reserving 1/16th of it for 
unknown purposes that are never to be.

65,536 times enough space for all the sites we deployed in 30+ years will more 
than likely outlast the lifetime of the
protocol, so, yeah, I'm OK with giving every end-site in the world (note an 
end-site is not a  person, it's a building,
structure, or tenant in a multi-tenant building or structure).

Owen

P.S. Jonathon: If anything in your email was confidential, too bad. You posted 
it to a public list. Silly notice at the
bottom to that effect removed.




smime.p7s
Description: S/MIME cryptographic signature

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote:

> On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews  wrote:
>> So you want HE to force all their clients to renumber.
> 
> No.  I am simply pointing out that Owen exaggerated when he stated
> that he implements the following three practices together on his own
> networks:
> * hierarchical addressing
> * nibble-aligned addressing
> * /48 per access customer
> 
> You can simply read the last few messages in this thread to learn that
> his recommendations on this list are not even practical for his
> network today, because as Owen himself says, they are not yet able to
> obtain additional RIR allocations.  HE certainly operates a useful,
> high-profile tunnel-broker service which is IMO a very great asset to
> the Internet at-large; but if you spend a few minutes looking at the
> publicly available statistics on this service, they average only
> around 10,000 active tunnels across all their tunnel termination boxes
> combined.  They have not implemented the policies recommended by Owen
> because, as he states, a /32 is not enough.
> 
> Do I think the position he advocates will cause the eventual
> exhaustion of IPv6?  Well, let's do an exercise:
> 
> There has been some rather simplistic arithmetic posted today, 300m
> new subnets per year, etc. with zero consideration of address/subnet
> utilization efficiency within ISP networks and individual aggregation
> router pools.  That is foolish.  We can all pull out a calculator and
> figure that 2000::/3 has space for 35 trillion /48 networks.  That
> isn't how they will be assigned or routed.
> 
> The effect of 2011-3 is that an out-sized ISP like AT&T has every
> justification for deciding to allocate 24 bits worth of subnet ID for
> their "largest POP," say, one that happens to terminate layer-3
> services for all customers in an entire state.  They then have policy
> support for allocating the same sized subnet for every other POP, no
> matter how small.  After all, the RIR policy permits them to obtain
> additional allocations as soon as one POP subnet has become full.
> 
> So now you have a huge ISP with a few huge POPs, and a lot of small
> ones, justified in assigning the same size aggregate prefix, suitable
> for 2^24 subnets, to all those small POPs as well.  How many layer-3
> POPs might this huge ISP have?  Any number.  It could be every central
> office with some kind of layer-3 customer aggregation router.  It
> could even be every road-side hut for FTTH services.  Perhaps they
> will decide to address ten thousand POPs this way.
> 
> Now the nibble-aligned language in the policy permits them to round up
> from 10,000 POPs to 16 bits worth of address space for "POP ID."  So
> AT&T is quite justified in requesting:
>48 (customer subnet length) - 24 (largest POP subnet ID size) - 16
> (POP ID) == a /8 subnet for themselves.
> 
Right up until you read:

6.5.3 (d):
If an LIR has already reached a /12 or more, ARIN will
allocate a single additional /12 rather than continue
expanding nibble boundaries.
As you can see, there is a safety valve in the policy at /12 for just
this reason.


> Now you can see how this policy, and addressing scheme, is utterly
> brain-dead.  It really does put you (and me, and everyone else) in
> real danger of exhausting the IPv6 address space.  All it takes is a
> few out-sized ISPs, with one large POP each and a bunch of smaller
> ones, applying for the maximum amount of address space permitted them
> under 2011-3.
> 

Even by your calculations, it would take 256 such outsized ISPs without
a safety valve. With the safety valve that is built into the policy at /12,
it would take 4,096 such ISPs. I do not believe that there are more than
about 20 such ISPs world wide at this time and would put the foreseeable
likely maximum at less than 100 due to the need for customers to support
such outsized ISPs and the limited base that would have to be divided
among them.

Owen



smime.p7s
Description: S/MIME cryptographic signature

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 8, 2011, at 1:15 AM, Mohacsi Janos wrote:

> 
> 
> On Fri, 5 Aug 2011, Brian Mengel wrote:
> 
>> In reviewing IPv6 end user allocation policies, I can find little
>> agreement on what prefix length is appropriate for residential end
>> users.  /64 and /56 seem to be the favorite candidates, with /56 being
>> slightly preferred.
>> 
>> I am most curious as to why a /60 prefix is not considered when trying
>> to address this problem.  It provides 16 /64 subnetworks, which seems
>> like an adequate amount for an end user.
>> 
>> Does anyone have opinions on the BCP for end user addressing in IPv6?
> 
> For business customers I would give /48 and home users who might have 1-2 
> subnet I would give /56 or /60.
> Reasons:
> - Business customers night grow where you have to provide bigger amount of 
> subnet - allow space for future extension -
> 
> - Home users - they usually don't know what is subnet. Setting up different 
> subnets in their SOHO router can be difficult. Usually the simple 1 subnet 
> for every device is enough for them. Separating some devices into  a separate 
> subnets is usually enough for the most sophisticated home users. If  not then 
> he can opt for business service….
> 

This utterly ignores the reality of DHCPv6, DHCP-PD, and technologies currently 
being developed for rational automatic hierarchies of topology.

Owen



smime.p7s
Description: S/MIME cryptographic signature

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 8, 2011, at 5:43 AM, valdis.kletni...@vt.edu wrote:

> On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said:
> 
>> - Home users - they usually don't know what is subnet. Setting up 
>> different subnets in their SOHO router can be difficult. Usually the 
>> simple 1 subnet for every device is enough for them. Separating some 
>> devices into  a separate subnets is usually enough for the most 
>> sophisticated home users. If  not then he can opt for business service
> 
> You don't want to make the assumption that just because Joe Sixpack doesn't
> know what a subnet is, that Joe Sixpack's CPE doesn't know either.
> 
> And remember that if it's 3 hops from one end of Joe Sixpack's internal net to
> the other, you're gonna burn a few bits to support heirarchical routing so you
> don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a
> /56 by the provider, and it hands each device it sees a /60 in case it's a
> device that routes too, it can only support 14 devices.  And if one of the
> things that got handed a /60 is a wireless access point or something, it's 
> only
> going to be able to support 15 or so subnets. So a simple topology of only a
> half dozen devices can burn up 8 bits of subnet addressing real fast. Yes, you
> can conserve bits by being more clever, but then you probably need an IGP of
> some sort
> 
> 

YOu lost a /60 somewhere in there…

I understand 1 /60 for the primary device.
You accounted for 14 /60s to other subordinate devices.
Presumably the /64(s) that connect the other subordinate devices to the
primary router are from within that first /60, so, where did the 16th /60 go?

Finally, for things that are building automatic hierarchical topologies, it
seems only sane to me that they would implement some form of OSPF
to facilitate the routing. There's no reason that can't be equally automated.

Owen



smime.p7s
Description: S/MIME cryptographic signature

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 8, 2011, at 7:12 AM, Mohacsi Janos wrote:

> 
> 
> On Mon, 8 Aug 2011, valdis.kletni...@vt.edu wrote:
> 
>> On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said:
>> 
>>> - Home users - they usually don't know what is subnet. Setting up
>>> different subnets in their SOHO router can be difficult. Usually the
>>> simple 1 subnet for every device is enough for them. Separating some
>>> devices into  a separate subnets is usually enough for the most
>>> sophisticated home users. If  not then he can opt for business service
>> 
>> You don't want to make the assumption that just because Joe Sixpack doesn't
>> know what a subnet is, that Joe Sixpack's CPE doesn't know either.
>> 
>> And remember that if it's 3 hops from one end of Joe Sixpack's internal net 
>> to
>> the other, you're gonna burn a few bits to support heirarchical routing so 
>> you
>> don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a
>> /56 by the provider, and it hands each device it sees a /60 in case it's a
>> device that routes too, it can only support 14 devices.  And if one of the
> 
> more exactly 16 routing devices. You don't have to count the all 0 and all 1 
> as reserved maybe each deeice can see /57 or /58 or /59 depending of 
> capabilities your devices
> 
> I think daisy chaining of CPE routers is bad idea - as probably done in 
> several IPv4 home networks. Why would you build several hierarchy into you 
> network if it is unnecessary?
> 
> 
I can see things like wanting to have an entertainment systems network that is 
fronted
by a router with additional networks for each entertainment system fronted by 
their
own router, segmentation of various appliance networks with possibly an 
appliance
front-end router, etc.

There are lots of possibilities we haven't thought of here yet. Limiting 
end-users
to /56 or worse will only stifle the innovation that will help us identify the 
possibilities.
For this, if no other reason, (and I cite the limitations under which we have 
begun
to frame our assumptions about how the internet works as a result of NAT as an
example), I think we should avoid preserving this cultural conditioning in IPv6.


Owen



smime.p7s
Description: S/MIME cryptographic signature

Re: IPv6 end user addressing

[Sven Olaf Kamphuis]

we assign /112 per "end user vlan (or server)" at this moment... works 
perfectly fine (and thats even "a bit too big").


- nobody wants to use dynamic ips on -servers- or -router links- anyway

i -really- can't see why people don't just use subnets with just the 
required number of addresses.


take one /64 (for /64's sake ;), split it up into subnets which each have 
the required number of addresses (lets say you have 2-4 addresses for each 
bgp/router link, so you simply split it up into subnets that size)


etc.

no need to use /64 for -everything- at all, just because it fits 
(ethernet) mac addresses (as if ethernet will be around longer than ipv6 
ha-ha, someone will come up with something faster tomorrow and then its 
bye bye ethernet, the 10ge variant is getting slow, and the 100ge variant 
is not even standardized yet, and trunking is a bottleneck ;)


we don't use /24's for -everything- on ipv4 now do we :P

(oh wait, there once was a time where we did.. due to another retarded 
semi-automatic configuration thingy, called RIP , which also only seemed 
to understand /24 or bigger ;)


--
Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=
Address: Koloniestrasse 34 VAT Tax ID:  DE267268209
 D-13359   Registration:HRA 42834 B
 BERLINPhone:   +31/(0)87-8747479
 Germany   GSM: +49/(0)152-26410799
RIPE:CBSK1-RIPEe-Mail:  s...@cb3rob.net
=
 C3P0, der elektrische Westerwelle
http://www.facebook.com/cb3rob
=

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


On Mon, 8 Aug 2011, Owen DeLong wrote:



On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote:


On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews  wrote:

So you want HE to force all their clients to renumber.


No.  I am simply pointing out that Owen exaggerated when he stated
that he implements the following three practices together on his own
networks:
* hierarchical addressing
* nibble-aligned addressing
* /48 per access customer

You can simply read the last few messages in this thread to learn that
his recommendations on this list are not even practical for his
network today, because as Owen himself says, they are not yet able to
obtain additional RIR allocations.  HE certainly operates a useful,
high-profile tunnel-broker service which is IMO a very great asset to
the Internet at-large; but if you spend a few minutes looking at the
publicly available statistics on this service, they average only
around 10,000 active tunnels across all their tunnel termination boxes
combined.  They have not implemented the policies recommended by Owen
because, as he states, a /32 is not enough.

Do I think the position he advocates will cause the eventual
exhaustion of IPv6?  Well, let's do an exercise:

There has been some rather simplistic arithmetic posted today, 300m
new subnets per year, etc. with zero consideration of address/subnet
utilization efficiency within ISP networks and individual aggregation
router pools.  That is foolish.  We can all pull out a calculator and
figure that 2000::/3 has space for 35 trillion /48 networks.  That
isn't how they will be assigned or routed.

The effect of 2011-3 is that an out-sized ISP like AT&T has every
justification for deciding to allocate 24 bits worth of subnet ID for
their "largest POP," say, one that happens to terminate layer-3
services for all customers in an entire state.  They then have policy
support for allocating the same sized subnet for every other POP, no
matter how small.  After all, the RIR policy permits them to obtain
additional allocations as soon as one POP subnet has become full.

So now you have a huge ISP with a few huge POPs, and a lot of small
ones, justified in assigning the same size aggregate prefix, suitable
for 2^24 subnets, to all those small POPs as well.  How many layer-3
POPs might this huge ISP have?  Any number.  It could be every central
office with some kind of layer-3 customer aggregation router.  It
could even be every road-side hut for FTTH services.  Perhaps they
will decide to address ten thousand POPs this way.

Now the nibble-aligned language in the policy permits them to round up
from 10,000 POPs to 16 bits worth of address space for "POP ID."  So
AT&T is quite justified in requesting:
   48 (customer subnet length) - 24 (largest POP subnet ID size) - 16
(POP ID) == a /8 subnet for themselves.


Right up until you read:

6.5.3 (d):
If an L

RE: IPv6 end user addressing

[Jonathon Exley]

Silly confidentiality notices are usually enforced by silly corporate IT 
departments and cannot be removed by mere mortal employees.
They are an unavoidable part of life, like Outlook top posting and spam.

Jonathon.
 
-Original Message-
From: Owen DeLong [mailto:o...@delong.com] 
Sent: Tuesday, 9 August 2011 8:26 a.m.
To: Jonathon Exley
Cc: nanog@nanog.org
Subject: Re: IPv6 end user addressing

[snip]

P.S. Jonathon: If anything in your email was confidential, too bad. You posted 
it to a public list. Silly notice at the
bottom to that effect removed.


This email and attachments: are confidential; may be protected by
privilege and copyright; if received in error may not be used,copied,
or kept; are not guaranteed to be virus-free; may not express the
views of Kordia(R); do not designate an information system; and do not
give rise to any liability for Kordia(R).

Re: IPv6 end user addressing

[William Herrin]

On Mon, Aug 8, 2011 at 6:52 PM, Sven Olaf Kamphuis  wrote:
> we assign /112 per "end user vlan (or server)" at this moment... works
> perfectly fine (and thats even "a bit too big").
>
> - nobody wants to use dynamic ips on -servers- or -router links- anyway
>
> i -really- can't see why people don't just use subnets with just the
> required number of addresses.

Hi Sven,

Stateless autoconfiguration (which is NOT dynamic IP addresses; the IP
address is static but tied to the ethernet card) does not work unless
the subnet mask is exactly /64.

Even on a server lan you'll occasionally want to plug in a PC for
diagnostics without having to poke in an IP address by hand.


There are some great reasons to use a /112s or even smaller blocks for
some applications. Use them that way, sure. But IMHO it's
short-sighted to _assign_ address blocks at that size -- it means the
person downstream has to come back to you and waste your time when
they want to do anything else. And your choice delays them and wastes
their time as well -- a fine "customer service" indeed.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv6 end user addressing

[Randy Carpenter]

I heard at one time that hardware manufacturers were likely to route in 
hardware only down to a /64, and that any smaller subnets would be subject to 
the "slow path" as ASICs were being designed with 64-bit address tables. I have 
no idea of the validity of that claim. Does anyone have any concrete evidence 
for or against this argument?

If true, it would make /64s even more attractive.

-Randy


- Original Message -
> we assign /112 per "end user vlan (or server)" at this moment...
> works
> perfectly fine (and thats even "a bit too big").
> 
> - nobody wants to use dynamic ips on -servers- or -router links-
> anyway
> 
> i -really- can't see why people don't just use subnets with just the
> required number of addresses.
> 
> take one /64 (for /64's sake ;), split it up into subnets which each
> have
> the required number of addresses (lets say you have 2-4 addresses for
> each
> bgp/router link, so you simply split it up into subnets that size)
> 
> etc.
> 
> no need to use /64 for -everything- at all, just because it fits
> (ethernet) mac addresses (as if ethernet will be around longer than
> ipv6
> ha-ha, someone will come up with something faster tomorrow and then
> its
> bye bye ethernet, the 10ge variant is getting slow, and the 100ge
> variant
> is not even standardized yet, and trunking is a bottleneck ;)
> 
> we don't use /24's for -everything- on ipv4 now do we :P
> 
> (oh wait, there once was a time where we did.. due to another
> retarded
> semi-automatic configuration thingy, called RIP , which also only
> seemed
> to understand /24 or bigger ;)
> 
> --
> Greetings,
> 
> Sven Olaf Kamphuis,
> CB3ROB Ltd. & Co. KG
> =
> Address: Koloniestrasse 34 VAT Tax ID:  DE267268209
>   D-13359   Registration:HRA 42834 B
>   BERLINPhone:
> +31/(0)87-8747479
>   Germany   GSM:
>   +49/(0)152-26410799
> RIPE:CBSK1-RIPEe-Mail:  s...@cb3rob.net
> =
>  C3P0, der elektrische Westerwelle
> http://www.facebook.com/cb3rob
> =
> 
> Confidential: Please be advised that the information contained in
> this
> email message, including all attached documents or files, is
> privileged
> and confidential and is intended only for the use of the individual
> or
> individuals addressed. Any other use, dissemination, distribution or
> copying of this communication is strictly prohibited.
> 
> 
> On Mon, 8 Aug 2011, Owen DeLong wrote:
> 
> >
> > On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote:
> >
> >> On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews 
> >> wrote:
> >>> So you want HE to force all their clients to renumber.
> >>
> >> No.  I am simply pointing out that Owen exaggerated when he stated
> >> that he implements the following three practices together on his
> >> own
> >> networks:
> >> * hierarchical addressing
> >> * nibble-aligned addressing
> >> * /48 per access customer
> >>
> >> You can simply read the last few messages in this thread to learn
> >> that
> >> his recommendations on this list are not even practical for his
> >> network today, because as Owen himself says, they are not yet able
> >> to
> >> obtain additional RIR allocations.  HE certainly operates a
> >> useful,
> >> high-profile tunnel-broker service which is IMO a very great asset
> >> to
> >> the Internet at-large; but if you spend a few minutes looking at
> >> the
> >> publicly available statistics on this service, they average only
> >> around 10,000 active tunnels across all their tunnel termination
> >> boxes
> >> combined.  They have not implemented the policies recommended by
> >> Owen
> >> because, as he states, a /32 is not enough.
> >>
> >> Do I think the position he advocates will cause the eventual
> >> exhaustion of IPv6?  Well, let's do an exercise:
> >>
> >> There has been some rather simplistic arithmetic posted today,
> >> 300m
> >> new subnets per year, etc. with zero consideration of
> >> address/subnet
> >> utilization efficiency within ISP networks and individual
> >> aggregation
> >> router pools.  That is foolish.  We can all pull out a calculator
> >> and
> >> figure that 2000::/3 has space for 35 trillion /48 networks.  That
> >> isn't how they will be assigned or routed.
> >>
> >> The effect of 2011-3 is that an out-sized ISP like AT&T has every
> >> justification for deciding to allocate 24 bits worth of subnet ID
> >> for
> >> their "largest POP," say, one that happens to terminate layer-3
> >> services for all customers in an entire state.  They then have
> >> policy
> >> support for allocating the same sized subnet for every other POP,
> >> no
> >> matter how small.  After all, the RIR policy permits them to
> >> obtain
> >> additional alloca

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 8, 2011, at 3:52 PM, Sven Olaf Kamphuis wrote:

> we assign /112 per "end user vlan (or server)" at this moment... works 
> perfectly fine (and thats even "a bit too big").
> 

Sigh… Too big for what?

> - nobody wants to use dynamic ips on -servers- or -router links- anyway
> 

True… Guess what… Static addresses work in /64s as well.

Better yet, your /64 will support adding troubleshooting equipment rapidly 
without having to hunt
for an available address.

> i -really- can't see why people don't just use subnets with just the required 
> number of addresses.
> 

Because we see real advantages to sparse addressing?

Because it would make our lives unnecessarily more complicated?

Because it will lead to additional human factors issues in most environments 
with more than a
single administrator and likely even in cases where it is a single 
administrator?

Because it reduces the potential for better automation?

I'm sure there are more reasons, but, these are just a few that come to mind 
off the top
of my head.

> take one /64 (for /64's sake ;), split it up into subnets which each have the 
> required number of addresses (lets say you have 2-4 addresses for each 
> bgp/router link, so you simply split it up into subnets that size)
> 

The point of this being? What do you gain by doing this? I've shown you at 
least a few things you lose.

> etc.
> 
> no need to use /64 for -everything- at all, just because it fits (ethernet) 
> mac addresses (as if ethernet will be around longer than ipv6 ha-ha, someone 
> will come up with something faster tomorrow and then its bye bye ethernet, 
> the 10ge variant is getting slow, and the 100ge variant is not even 
> standardized yet, and trunking is a bottleneck ;)
> 

The /64 was chosen because it fits EUI-64 addresses. Ethernet MAC addresses are 
EUI-48.

Examples of network technologies that use EUI-64 include Firewire, Zigbee, 
6lowpan, etc.

So this argument is rather specious and orthogonal to your supposed point.

> we don't use /24's for -everything- on ipv4 now do we :P
> 

Right.. We ran out of IPv4 and stopped doing that in order to artificially 
extend its life.

> (oh wait, there once was a time where we did.. due to another retarded 
> semi-automatic configuration thingy, called RIP , which also only seemed to 
> understand /24 or bigger ;)
> 

The issuance of /24s was _NOT_ driven by RIP. Rather, the architecture of RIP 
was driven
by glassful addressing assumptions. There were many other reasons for classful 
addressing
and it still retains some of those advantages.

Owen
> 
> Confidential: Please be advised that the information contained in this
> email message, including all attached documents or files, is privileged
> and confidential and is intended only for the use of the individual or
> individuals addressed. Any other use, dissemination, distribution or
> copying of this communication is strictly prohibited.
> 

Guess you shouldn't have published it to a public list then.

> 
> On Mon, 8 Aug 2011, Owen DeLong wrote:
> 
>> 
>> On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote:
>> 
>>> On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews  wrote:
 So you want HE to force all their clients to renumber.
>>> 
>>> No.  I am simply pointing out that Owen exaggerated when he stated
>>> that he implements the following three practices together on his own
>>> networks:
>>> * hierarchical addressing
>>> * nibble-aligned addressing
>>> * /48 per access customer
>>> 
>>> You can simply read the last few messages in this thread to learn that
>>> his recommendations on this list are not even practical for his
>>> network today, because as Owen himself says, they are not yet able to
>>> obtain additional RIR allocations.  HE certainly operates a useful,
>>> high-profile tunnel-broker service which is IMO a very great asset to
>>> the Internet at-large; but if you spend a few minutes looking at the
>>> publicly available statistics on this service, they average only
>>> around 10,000 active tunnels across all their tunnel termination boxes
>>> combined.  They have not implemented the policies recommended by Owen
>>> because, as he states, a /32 is not enough.
>>> 
>>> Do I think the position he advocates will cause the eventual
>>> exhaustion of IPv6?  Well, let's do an exercise:
>>> 
>>> There has been some rather simplistic arithmetic posted today, 300m
>>> new subnets per year, etc. with zero consideration of address/subnet
>>> utilization efficiency within ISP networks and individual aggregation
>>> router pools.  That is foolish.  We can all pull out a calculator and
>>> figure that 2000::/3 has space for 35 trillion /48 networks.  That
>>> isn't how they will be assigned or routed.
>>> 
>>> The effect of 2011-3 is that an out-sized ISP like AT&T has every
>>> justification for deciding to allocate 24 bits worth of subnet ID for
>>> their "largest POP," say, one that happens to terminate layer-3
>>> services for all customers in an entire state.  They then

Re: IPv6 end user addressing

[Owen DeLong]

I'm sure there will be platforms that end up on both sides of this question.

YES: We made a less expensive box by cutting the width of the TCAM required in 
half.

NO: We spared no expense and passed the costs (and a nice profit margin) on to 
you so
that you can do whatever you like in IPv6 at wire speed.

I'm sure the market will chose products from both sides of the line for the 
same reasons.

Owen

On Aug 8, 2011, at 4:34 PM, Randy Carpenter wrote:

> 
> I heard at one time that hardware manufacturers were likely to route in 
> hardware only down to a /64, and that any smaller subnets would be subject to 
> the "slow path" as ASICs were being designed with 64-bit address tables. I 
> have no idea of the validity of that claim. Does anyone have any concrete 
> evidence for or against this argument?
> 
> If true, it would make /64s even more attractive.
> 
> -Randy
> 
> 
> - Original Message -
>> we assign /112 per "end user vlan (or server)" at this moment...
>> works
>> perfectly fine (and thats even "a bit too big").
>> 
>> - nobody wants to use dynamic ips on -servers- or -router links-
>> anyway
>> 
>> i -really- can't see why people don't just use subnets with just the
>> required number of addresses.
>> 
>> take one /64 (for /64's sake ;), split it up into subnets which each
>> have
>> the required number of addresses (lets say you have 2-4 addresses for
>> each
>> bgp/router link, so you simply split it up into subnets that size)
>> 
>> etc.
>> 
>> no need to use /64 for -everything- at all, just because it fits
>> (ethernet) mac addresses (as if ethernet will be around longer than
>> ipv6
>> ha-ha, someone will come up with something faster tomorrow and then
>> its
>> bye bye ethernet, the 10ge variant is getting slow, and the 100ge
>> variant
>> is not even standardized yet, and trunking is a bottleneck ;)
>> 
>> we don't use /24's for -everything- on ipv4 now do we :P
>> 
>> (oh wait, there once was a time where we did.. due to another
>> retarded
>> semi-automatic configuration thingy, called RIP , which also only
>> seemed
>> to understand /24 or bigger ;)
>> 
>> --
>> Greetings,
>> 
>> Sven Olaf Kamphuis,
>> CB3ROB Ltd. & Co. KG
>> =
>> Address: Koloniestrasse 34 VAT Tax ID:  DE267268209
>>  D-13359   Registration:HRA 42834 B
>>  BERLINPhone:
>>+31/(0)87-8747479
>>  Germany   GSM:
>>  +49/(0)152-26410799
>> RIPE:CBSK1-RIPEe-Mail:  s...@cb3rob.net
>> =
>>  C3P0, der elektrische Westerwelle
>> http://www.facebook.com/cb3rob
>> =
>> 
>> Confidential: Please be advised that the information contained in
>> this
>> email message, including all attached documents or files, is
>> privileged
>> and confidential and is intended only for the use of the individual
>> or
>> individuals addressed. Any other use, dissemination, distribution or
>> copying of this communication is strictly prohibited.
>> 
>> 
>> On Mon, 8 Aug 2011, Owen DeLong wrote:
>> 
>>> 
>>> On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote:
>>> 
 On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews 
 wrote:
> So you want HE to force all their clients to renumber.
 
 No.  I am simply pointing out that Owen exaggerated when he stated
 that he implements the following three practices together on his
 own
 networks:
 * hierarchical addressing
 * nibble-aligned addressing
 * /48 per access customer
 
 You can simply read the last few messages in this thread to learn
 that
 his recommendations on this list are not even practical for his
 network today, because as Owen himself says, they are not yet able
 to
 obtain additional RIR allocations.  HE certainly operates a
 useful,
 high-profile tunnel-broker service which is IMO a very great asset
 to
 the Internet at-large; but if you spend a few minutes looking at
 the
 publicly available statistics on this service, they average only
 around 10,000 active tunnels across all their tunnel termination
 boxes
 combined.  They have not implemented the policies recommended by
 Owen
 because, as he states, a /32 is not enough.
 
 Do I think the position he advocates will cause the eventual
 exhaustion of IPv6?  Well, let's do an exercise:
 
 There has been some rather simplistic arithmetic posted today,
 300m
 new subnets per year, etc. with zero consideration of
 address/subnet
 utilization efficiency within ISP networks and individual
 aggregation
 router pools.  That is foolish.  We can all pull out a calculator
 and
 figure that 2000::/3 has space for 35 t

Re: IPv6 end user addressing

[Matthew Moyle-Croft]

Hi Brian,

>From someone who's actually done this.

- Our customer base is primarily PPP connected broadband users (variety of 
technologies, mostly ADSL).
- We do a DYNAMIC /64 on the PPP interface so that people who terminate 
directly on a PC can get IPv6 without DHCPv6 PD.
- In addition for the subnet assigned via DHCPv6 Prefix delegation which is 
STATIC as that's what customers have been asking for:

In our trial phase we did /60s to customers - this worked just fine.  I don't 
recall anyone actually saying "I need more".  (The /60 was the first nibble 
boundary and it allowed us to do some dumb things for allocation which didn't 
compromise the allocation strategy later).

In production we've chosen a more conventional /56.   At some point it becomes 
a little arbitrary.  Our feeling is that at the point your have 256 /64s in 
production then ADSL is probably NOT what you need or want as a technology so 
we can do things differently for ethernet connected customers.

We're getting there with support for customers bringing their own PI space.

(For an idea of scale - we're tiny globally, but have around 250k customers 
across mainly Australia.  We run our own global dualstack network).

MMC


On 06/08/2011, at 1:47 AM, Brian Mengel wrote:

In reviewing IPv6 end user allocation policies, I can find little
agreement on what prefix length is appropriate for residential end
users.  /64 and /56 seem to be the favorite candidates, with /56 being
slightly preferred.

I am most curious as to why a /60 prefix is not considered when trying
to address this problem.  It provides 16 /64 subnetworks, which seems
like an adequate amount for an end user.

Does anyone have opinions on the BCP for end user addressing in IPv6?


--
Matthew Moyle-Croft
Peering Manager and Team Lead - Commercial and DSLAMs
Internode /Agile
Level 5, 150 Grenfell Street, Adelaide, SA 5000 Australia
Email: m...@internode.com.auWeb: 
http://www.on.net
Direct: +61-8-8228-2909  Mobile: +61-419-900-366
Reception: +61-8-8228-2999Fax: +61-8-8235-6909

Re: IPv6 end user addressing

[Ryan Malayter]

On Aug 8, 6:24 pm, Jonathon Exley  wrote:
> Silly confidentiality notices are usually enforced by silly
> corporate IT departments

Oh, no, it's the *legal* department (or maybe HR) that is to blame. I
actually had a guardhouse lawyer kick and scream about us not putting
disclaimers on our emails. I told him, "You do realize that email
disclaimers have no legal standing, have never been successfully used
in any litigation, do nothing to prevent loss of corporate assets, and
actually increase our liability by outlining a corporate policy that
may not be followed 100% internally by all employees, right?"

It took a long while and an embarrassing number of meetings with
senior management, but we eventually put a stop to the whole thing.

Re: IPv6 end user addressing

[Chris Adams]

Once upon a time, William Herrin  said:
> Stateless autoconfiguration (which is NOT dynamic IP addresses; the IP
> address is static but tied to the ethernet card) does not work unless
> the subnet mask is exactly /64.
> 
> Even on a server lan you'll occasionally want to plug in a PC for
> diagnostics without having to poke in an IP address by hand.

Actually, nobody should be plugging any random device into my server
LANs, and I certainly don't want to encourage it by having it work (even
if just for IPv6).

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: IPv6 end user addressing

[William Herrin]

On Mon, Aug 8, 2011 at 11:43 PM, Chris Adams  wrote:
> Once upon a time, William Herrin  said:
>> Even on a server lan you'll occasionally want to plug in a PC for
>> diagnostics without having to poke in an IP address by hand.
>
> Actually, nobody should be plugging any random device into my server
> LANs, and I certainly don't want to encourage it by having it work (even
> if just for IPv6).

When I send someone on site to do work for me, I don't want to have to
prepare excessive instructions on how to connect their laptop to the
local LAN. I want to say, "This switch, this port" and then move on to
the actual work I sent them there to do.

You're welcome to run your shop your way.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv6 end user addressing

[Jimmy Hess]

On Mon, Aug 8, 2011 at 10:43 PM, Chris Adams  wrote:
>> Even on a server lan you'll occasionally want to plug in a PC for
>> diagnostics without having to poke in an IP address by hand.
> Actually, nobody should be plugging any random device into my server
> LANs, and I certainly don't want to encourage it by having it work (even
> if just for IPv6).

If you must not have someone plugging into your server LAN without
permission, you
turn unused ports off, or preferably, place them in a VLAN island with
no topological
connection to anything.

Because it's going to be easier to turn the port back on, than to give someone a
128-bit IP6 address,  IPv6 netmask, IPv6 DNS servers, and IPv6 default gateway
address set to manually key into their machine.


If someone can get to a live port,  assuming it's not protected by
802.1x port security or similar;   IPv6 will  "just work" for  fe80::
network link-local connectivity,   whether you  deploy stateless
auto-config or not,  which is enough connectivity to find and mess
with servers in the LAN.

And probably enough connectivity to say "that's too much connectivity",
if the LAN is indeed restricted.

Similar to how IPv4 has rfc3927,  except IPv6 link local addresses
get assigned, even to devices that have global IPv6 IPs,
so the link local 'subnet' is active even on fully connected devices.



> Chris Adams 

Regards,

--
-JH

RE: IPv6 end user addressing

[Cameron]

> -Original Message-
> From: William Herrin [mailto:b...@herrin.us]
> Sent: Tuesday, 9 August 2011 2:30 PM
> To: Chris Adams; nanog@nanog.org
> Subject: Re: IPv6 end user addressing
> 
> When I send someone on site to do work for me, I don't want to have to
> prepare excessive instructions on how to connect their laptop to the
> local LAN. I want to say, "This switch, this port" and then move on to
> the actual work I sent them there to do.

To be fair, if you're sending someone to site who isn't familiar with
putting a static address on their laptop then you're probably doing things
wrong to begin with.

This line of argument isn't going to get us anywhere as for server networks,
the benefits of using a /64 are not necessarily beneficial given the
environment.


> You're welcome to run your shop your way.
> 
> Regards,
> Bill Herrin
> 
> 
> --
> William D. Herrin  her...@dirtside.com  b...@herrin.us
> 3005 Crane Dr. .. Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004

Re: IPv6 end user addressing

[Randy Bush]

> When I send someone on site to do work for me, I don't want to have to
> prepare excessive instructions on how to connect their laptop to the
> local LAN. I want to say, "This switch, this port" and then move on to
> the actual work I sent them there to do.

when i am allowed, i put up open wireless and dhcp.  my job is to deliver 
packets.

randy

Re: IPv6 end user addressing

[Joel Jaeggli]

On Aug 8, 2011, at 5:14 PM, Owen DeLong wrote:

> I'm sure there will be platforms that end up on both sides of this question.

I know of no asic in a switch that claims to support ipv6 that does it this 
way... That would tend to place you at a competitive disadvantage to 
broadcom/marvell/fulcrum/juniper/cisco if you implemented it that way... it's 
easier I imagine to simply reduce the size of the fib...

given that switches routinely have to forward to neighbors on /126 or /127 
prefix links I think that would be something of a mistake.

> YES: We made a less expensive box by cutting the width of the TCAM required 
> in half

> NO: We spared no expense and passed the costs (and a nice profit margin) on 
> to you so
>   that you can do whatever you like in IPv6 at wire speed.
> 
> I'm sure the market will chose products from both sides of the line for the 
> same reasons.
> 
> Owen
> 
> On Aug 8, 2011, at 4:34 PM, Randy Carpenter wrote:
> 
>> 
>> I heard at one time that hardware manufacturers were likely to route in 
>> hardware only down to a /64, and that any smaller subnets would be subject 
>> to the "slow path" as ASICs were being designed with 64-bit address tables. 
>> I have no idea of the validity of that claim. Does anyone have any concrete 
>> evidence for or against this argument?
>> 
>> If true, it would make /64s even more attractive.
>> 
>> -Randy
>> 
>> 
>> - Original Message -
>>> we assign /112 per "end user vlan (or server)" at this moment...
>>> works
>>> perfectly fine (and thats even "a bit too big").
>>> 
>>> - nobody wants to use dynamic ips on -servers- or -router links-
>>> anyway
>>> 
>>> i -really- can't see why people don't just use subnets with just the
>>> required number of addresses.
>>> 
>>> take one /64 (for /64's sake ;), split it up into subnets which each
>>> have
>>> the required number of addresses (lets say you have 2-4 addresses for
>>> each
>>> bgp/router link, so you simply split it up into subnets that size)
>>> 
>>> etc.
>>> 
>>> no need to use /64 for -everything- at all, just because it fits
>>> (ethernet) mac addresses (as if ethernet will be around longer than
>>> ipv6
>>> ha-ha, someone will come up with something faster tomorrow and then
>>> its
>>> bye bye ethernet, the 10ge variant is getting slow, and the 100ge
>>> variant
>>> is not even standardized yet, and trunking is a bottleneck ;)
>>> 
>>> we don't use /24's for -everything- on ipv4 now do we :P
>>> 
>>> (oh wait, there once was a time where we did.. due to another
>>> retarded
>>> semi-automatic configuration thingy, called RIP , which also only
>>> seemed
>>> to understand /24 or bigger ;)
>>> 
>>> --
>>> Greetings,
>>> 
>>> Sven Olaf Kamphuis,
>>> CB3ROB Ltd. & Co. KG
>>> =
>>> Address: Koloniestrasse 34 VAT Tax ID:  DE267268209
>>> D-13359   Registration:HRA 42834 B
>>> BERLINPhone:
>>>   +31/(0)87-8747479
>>> Germany   GSM:
>>> +49/(0)152-26410799
>>> RIPE:CBSK1-RIPEe-Mail:  s...@cb3rob.net
>>> =
>>>  C3P0, der elektrische Westerwelle
>>> http://www.facebook.com/cb3rob
>>> =
>>> 
>>> Confidential: Please be advised that the information contained in
>>> this
>>> email message, including all attached documents or files, is
>>> privileged
>>> and confidential and is intended only for the use of the individual
>>> or
>>> individuals addressed. Any other use, dissemination, distribution or
>>> copying of this communication is strictly prohibited.
>>> 
>>> 
>>> On Mon, 8 Aug 2011, Owen DeLong wrote:
>>> 
 
 On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote:
 
> On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews 
> wrote:
>> So you want HE to force all their clients to renumber.
> 
> No.  I am simply pointing out that Owen exaggerated when he stated
> that he implements the following three practices together on his
> own
> networks:
> * hierarchical addressing
> * nibble-aligned addressing
> * /48 per access customer
> 
> You can simply read the last few messages in this thread to learn
> that
> his recommendations on this list are not even practical for his
> network today, because as Owen himself says, they are not yet able
> to
> obtain additional RIR allocations.  HE certainly operates a
> useful,
> high-profile tunnel-broker service which is IMO a very great asset
> to
> the Internet at-large; but if you spend a few minutes looking at
> the
> publicly available statistics on this service, they average only
> around 10,000 active tunnels across all their tunnel termination
> boxes
> combined.  They have

Re: IPv6 end user addressing

[Owen DeLong]

It's at least true of how some of the Cisco platforms cope with IPv6 access 
lists.

Owen

On Aug 8, 2011, at 11:54 PM, Joel Jaeggli wrote:

> 
> On Aug 8, 2011, at 5:14 PM, Owen DeLong wrote:
> 
>> I'm sure there will be platforms that end up on both sides of this question.
> 
> I know of no asic in a switch that claims to support ipv6 that does it this 
> way... That would tend to place you at a competitive disadvantage to 
> broadcom/marvell/fulcrum/juniper/cisco if you implemented it that way... it's 
> easier I imagine to simply reduce the size of the fib...
> 
> given that switches routinely have to forward to neighbors on /126 or /127 
> prefix links I think that would be something of a mistake.
> 
>> YES: We made a less expensive box by cutting the width of the TCAM required 
>> in half
> 
>> NO: We spared no expense and passed the costs (and a nice profit margin) on 
>> to you so
>>  that you can do whatever you like in IPv6 at wire speed.
>> 
>> I'm sure the market will chose products from both sides of the line for the 
>> same reasons.
>> 
>> Owen
>> 
>> On Aug 8, 2011, at 4:34 PM, Randy Carpenter wrote:
>> 
>>> 
>>> I heard at one time that hardware manufacturers were likely to route in 
>>> hardware only down to a /64, and that any smaller subnets would be subject 
>>> to the "slow path" as ASICs were being designed with 64-bit address tables. 
>>> I have no idea of the validity of that claim. Does anyone have any concrete 
>>> evidence for or against this argument?
>>> 
>>> If true, it would make /64s even more attractive.
>>> 
>>> -Randy
>>> 
>>> 
>>> - Original Message -
 we assign /112 per "end user vlan (or server)" at this moment...
 works
 perfectly fine (and thats even "a bit too big").
 
 - nobody wants to use dynamic ips on -servers- or -router links-
 anyway
 
 i -really- can't see why people don't just use subnets with just the
 required number of addresses.
 
 take one /64 (for /64's sake ;), split it up into subnets which each
 have
 the required number of addresses (lets say you have 2-4 addresses for
 each
 bgp/router link, so you simply split it up into subnets that size)
 
 etc.
 
 no need to use /64 for -everything- at all, just because it fits
 (ethernet) mac addresses (as if ethernet will be around longer than
 ipv6
 ha-ha, someone will come up with something faster tomorrow and then
 its
 bye bye ethernet, the 10ge variant is getting slow, and the 100ge
 variant
 is not even standardized yet, and trunking is a bottleneck ;)
 
 we don't use /24's for -everything- on ipv4 now do we :P
 
 (oh wait, there once was a time where we did.. due to another
 retarded
 semi-automatic configuration thingy, called RIP , which also only
 seemed
 to understand /24 or bigger ;)
 
 --
 Greetings,
 
 Sven Olaf Kamphuis,
 CB3ROB Ltd. & Co. KG
 =
 Address: Koloniestrasse 34 VAT Tax ID:  DE267268209
D-13359   Registration:HRA 42834 B
BERLINPhone:
  +31/(0)87-8747479
Germany   GSM:
+49/(0)152-26410799
 RIPE:CBSK1-RIPEe-Mail:  s...@cb3rob.net
 =
  C3P0, der elektrische Westerwelle
 http://www.facebook.com/cb3rob
 =
 
 Confidential: Please be advised that the information contained in
 this
 email message, including all attached documents or files, is
 privileged
 and confidential and is intended only for the use of the individual
 or
 individuals addressed. Any other use, dissemination, distribution or
 copying of this communication is strictly prohibited.
 
 
 On Mon, 8 Aug 2011, Owen DeLong wrote:
 
> 
> On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote:
> 
>> On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews 
>> wrote:
>>> So you want HE to force all their clients to renumber.
>> 
>> No.  I am simply pointing out that Owen exaggerated when he stated
>> that he implements the following three practices together on his
>> own
>> networks:
>> * hierarchical addressing
>> * nibble-aligned addressing
>> * /48 per access customer
>> 
>> You can simply read the last few messages in this thread to learn
>> that
>> his recommendations on this list are not even practical for his
>> network today, because as Owen himself says, they are not yet able
>> to
>> obtain additional RIR allocations.  HE certainly operates a
>> useful,
>> high-profile tunnel-broker service which is IMO a very great 

Re: IPv6 end user addressing

[Tim Franklin]

> Silly confidentiality notices are usually enforced by silly corporate
> IT departments and cannot be removed by mere mortal employees.
> They are an unavoidable part of life, like Outlook top posting and
> spam.

Alternatively, if your corporate email imposes stupid policies and / or a 
stupid email client (note: it's possible to quote properly and not top-post 
with Outlook, it's just hard work), don't subscribe to mailing lists from your 
corporate email.  Of all the mailing list communities, I'd expect this one not 
to struggle very much with arranging an alternative...

Regards,
Tim.

Re: IPv6 end user addressing

[Chris Adams]

Once upon a time, Jimmy Hess  said:
> If you must not have someone plugging into your server LAN without
> permission, you
> turn unused ports off, or preferably, place them in a VLAN island with
> no topological
> connection to anything.

That's about what I do; unused ports are in a different VLAN.  I have a
separate LAN for notebooks, etc. that has DHCP (and will have a v6 /64
when I get v6 to that point).

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: IPv6 end user addressing

[Valdis . Kletnieks]

On Tue, 09 Aug 2011 11:24:03 +1200, Jonathon Exley said:
> Silly confidentiality notices are usually enforced by silly corporate IT
> departments and cannot be removed by mere mortal employees.
> They are an unavoidable part of life, like Outlook top posting and spam.

They may all three be things that we continually receive from clueless
netizens. However, it is not at all difficult for anybody clued enough to get
subscribed to NANOG to find ways to avoid inflicting all three on the rest of
us.



pgpgSTYWyhxo0.pgp
Description: PGP signature

Re: IPv6 end user addressing

[Alexander Harrowell]

On Monday 08 Aug 2011 22:00:52 Owen DeLong wrote:
> 
> On Aug 8, 2011, at 7:12 AM, Mohacsi Janos wrote:
> 
> > 
> > 
> > On Mon, 8 Aug 2011, valdis.kletni...@vt.edu wrote:
> > 
> >> On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said:
> >> 
> >>> - Home users - they usually don't know what is subnet. Setting up
> >>> different subnets in their SOHO router can be difficult. Usually 
the
> >>> simple 1 subnet for every device is enough for them. Separating 
some
> >>> devices into  a separate subnets is usually enough for the most
> >>> sophisticated home users. If  not then he can opt for business 
service
> >> 
> >> You don't want to make the assumption that just because Joe Sixpack 
doesn't
> >> know what a subnet is, that Joe Sixpack's CPE doesn't know either.
> >> 
> >> And remember that if it's 3 hops from one end of Joe Sixpack's 
internal net to
> >> the other, you're gonna burn a few bits to support heirarchical 
routing so you
> >> don't need a routing protocol. So if Joe's exterior-facing CPU gets 
handed a
> >> /56 by the provider, and it hands each device it sees a /60 in case 
it's a
> >> device that routes too, it can only support 14 devices.  And if one 
of the
> > 
> > more exactly 16 routing devices. You don't have to count the all 0 
and all 1 as reserved maybe each deeice can see /57 or /58 or 
/59 depending of capabilities your devices
> > 
> > I think daisy chaining of CPE routers is bad idea - as probably done 
in several IPv4 home networks. Why would you build several hierarchy 
into you network if it is unnecessary?
> > 
> > 
> I can see things like wanting to have an entertainment systems network 
that is fronted
> by a router with additional networks for each entertainment system 
fronted by their
> own router, segmentation of various appliance networks with possibly 
an appliance
> front-end router, etc.
> 
> There are lots of possibilities we haven't thought of here yet. 
Limiting end-users
> to /56 or worse will only stifle the innovation that will help us 
identify the possibilities.
> For this, if no other reason, (and I cite the limitations under which 
we have begun
> to frame our assumptions about how the internet works as a result of 
NAT as an
> example), I think we should avoid preserving this cultural 
conditioning in IPv6.
> 
> 
> Owen
> 
> 


Thinking about the CPE thread, isn't this a case for bridging as a 
feature in end-user devices? If Joe's media-centre box etc would bridge 
its downstream ports to the upstream port, the devices on them could 
just get an address, whether by DHCPv6 from the CPE router's delegation 
or by SLAAC, and then register in local DNS or more likely do multicast-
DNS so they could find each other. 


And then it really doesn't matter; everything gets its address, nothing 
is NATted, every address is mapped to a meaningful hostname.


Perhaps you'd need more aggregation and routing in the glorious one-IP-
per-nanite-and-Facebook-fridges future, but that's for another day once 
we've got fusion and a rational system of government out of the way:-) 
Joe's network as described isn't big enough or clever enough to need 
multiple routers. It's just a small LAN and it's only Joe's weirdness in 
using a $500 Roku as a $5 hank of cat5e and a $20 4-port switch that 
prevents it from being so.


Not all problems should be solved by routing - but a list full of 
"router people" is inherently likely to try to solve all its problems 
with more routers and routing.
-- 
The only thing worse than e-mail disclaimers...is people who send e-mail 
to lists complaining about them


signature.asc
Description: This is a digitally signed message part.

Re: IPv6 end user addressing

[Owen DeLong]

> 
> Thinking about the CPE thread, isn't this a case for bridging as a 
> feature in end-user devices? If Joe's media-centre box etc would bridge 
> its downstream ports to the upstream port, the devices on them could 
> just get an address, whether by DHCPv6 from the CPE router's delegation 
> or by SLAAC, and then register in local DNS or more likely do multicast-
> DNS so they could find each other. 
> 
Why do I want my kid's network seeing all the multicast packets that are
streaming the adult video from the player to the TV and the Amp in the
master bedroom?

Why do I want my appliance network's multicast packets getting tossed
around on the guest wireless?

Bridging eliminates the multicast isolation that you get from routing.

This is not a case for bridging, it's a case for making it possible to do real
routing in the home and we now have the space and the technology to
actually do it in a meaningful and sufficiently automatic way as to be
applicable to Joe 6-Mac.

> 
> And then it really doesn't matter; everything gets its address, nothing 
> is NATted, every address is mapped to a meaningful hostname.
> 

This assumption that an entire household should be a single broadcast
(or multicast) domain is fundamentally broken and needs to change
going forward.

> 
> Perhaps you'd need more aggregation and routing in the glorious one-IP-
> per-nanite-and-Facebook-fridges future, but that's for another day once 
> we've got fusion and a rational system of government out of the way:-) 
> Joe's network as described isn't big enough or clever enough to need 
> multiple routers. It's just a small LAN and it's only Joe's weirdness in 
> using a $500 Roku as a $5 hank of cat5e and a $20 4-port switch that 
> prevents it from being so.
> 

I think that the nanites and fridges that talk to other kitchen storage
systems will actually happen well before fusion or rational government.

Just because what you describe of today's situation is an accurate
picture of today does not mean it is how we should plan IPv6. Remember,
we don't want to have to replan IPv6 or switch to yet another numbering
system for several years, if not decades. In case you hadn't noticed, doing
so at today's scale is hard. Imagine what it will be like next time.

> 
> Not all problems should be solved by routing - but a list full of 
> "router people" is inherently likely to try to solve all its problems 
> with more routers and routing.

There are reasons to route and reasons to switch. I don't consider myself
a router person, but, I do consider myself a network engineer, so, I try
to use the right tool for the right job. In the case of LAN isolation which
I can see several desirable applications for in a home, I think routing
is a better choice than switching.

Remember, the multicast scopes in IPv6 are interface, link, and larger.
There's no scope in between everything on this interface and everything
on this link. (link == layer 3 network).

Owen

Re: IPv6 end user addressing

[Jeroen Massar]

On 2011-08-10 15:02 , Owen DeLong wrote:
[..]
> Why do I want my appliance network's multicast packets getting tossed
> around on the guest wireless?

Even wikipedia knows the answer to that:
http://en.wikipedia.org/wiki/IGMP_snooping
which is the first hit for IGMP snooping, which is generally a feature
that is present in the better (and thus more expensive) switching gear
(and thus probably not present in every home, but those homes probably
also don't care about that).

Granted, routing is the better and more appropriate way to isolate these
kind of packets and definitely more appropriate for broadcast nastyness
(mDNS is such a nice one there too...).

That said, /56 or /48 to the home should be what is happening.

The whole point of settling on a single prefix btw is so that networks
can at least keep the same numbering plan when they switch from one PA
prefix to another.

Greets,
 Jeroen

PS: the more power to your kids if they can sniff the network for your
'adult content', decode it, and then actually watch it (though if they
are technically inclined actually not too difficult, but heck, is that
not where crypto comes into play, as when they can pull that off on your
kiddienetwork they can also just plug something into the kiddie-'adult
content'-network and sniff it off there... something with 802.1x comes
to mind to solve that step.

Re: IPv6 end user addressing

[Alexander Harrowell]

On Wednesday 10 Aug 2011 14:57:54 Jeroen Massar wrote:
> PS: the more power to your kids if they can sniff the network for your
> 'adult content', decode it, and then actually watch it 

Indeed; I'd be more interested in making sure that, say, you can 
efficiently multicast the live footy to two different screens in the 
house, and things work automatically so they get used. 

I think we're operating on radically different Bayesian priors here and 
I wonder if a European/American issue is involved.

(PS, can you buy a switch that will do production grade IPv6, i.e. with 
things like RA guard, and not do IGMP-snooping?)


-- 
The only thing worse than e-mail disclaimers...is people who send e-mail 
to lists complaining about them


signature.asc
Description: This is a digitally signed message part.

Re: IPv6 end user addressing

[Scott Helms]

Neither of these are true, though in the future we _might_ have 
deployable technology that allows for automated routing setup (though I 
very seriously doubt it) in the home.  Layer 2 isolation is both easier 
and more reliable than attempting it at layer 3 which is isolation by 
agreement, i.e. it doesn't really exist.


On 8/10/2011 9:02 AM, Owen DeLong wrote:


Bridging eliminates the multicast isolation that you get from routing.

This is not a case for bridging, it's a case for making it possible to do real
routing in the home and we now have the space and the technology to
actually do it in a meaningful and sufficiently automatic way as to be
applicable to Joe 6-Mac.



--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000

http://twitter.com/kscotthelms

Re: IPv6 end user addressing

[Tim Chown]

On 10 Aug 2011, at 16:11, Scott Helms wrote:

> Neither of these are true, though in the future we _might_ have deployable 
> technology that allows for automated routing setup (though I very seriously 
> doubt it) in the home.  Layer 2 isolation is both easier and more reliable 
> than attempting it at layer 3 which is isolation by agreement, i.e. it 
> doesn't really exist.

Well, there is some new effort on this in the homenet WG in IETF.

For snooping IPv6 multicast it's MLD snooping rather than IGMP.  We use it in 
our enterprise since we have multiple multicast video channels in use.

Tim

> On 8/10/2011 9:02 AM, Owen DeLong wrote:
>> 
>> Bridging eliminates the multicast isolation that you get from routing.
>> 
>> This is not a case for bridging, it's a case for making it possible to do 
>> real
>> routing in the home and we now have the space and the technology to
>> actually do it in a meaningful and sufficiently automatic way as to be
>> applicable to Joe 6-Mac.
>> 
> 
> -- 
> Scott Helms
> Vice President of Technology
> ISP Alliance, Inc. DBA ZCorum
> (678) 507-5000
> 
> http://twitter.com/kscotthelms
> 
> 
> 

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 10, 2011, at 6:57 AM, Jeroen Massar wrote:

> On 2011-08-10 15:02 , Owen DeLong wrote:
> [..]
>> Why do I want my appliance network's multicast packets getting tossed
>> around on the guest wireless?
> 
> Even wikipedia knows the answer to that:
> http://en.wikipedia.org/wiki/IGMP_snooping
> which is the first hit for IGMP snooping, which is generally a feature
> that is present in the better (and thus more expensive) switching gear
> (and thus probably not present in every home, but those homes probably
> also don't care about that).
> 

That would be the answer to why I DON'T want that happening, but, why
would I WANT it to happen when, as you said, the better and more
appropriate solution is to route.

Unless you have some benefit to offer from NOT Routing, I stand by
my statement.

> Granted, routing is the better and more appropriate way to isolate these
> kind of packets and definitely more appropriate for broadcast nastyness
> (mDNS is such a nice one there too...).
> 
> That said, /56 or /48 to the home should be what is happening.
> 

That said, /48 to the home should be what is happening, and /56 is
a better compromise than anything smaller.

> The whole point of settling on a single prefix btw is so that networks
> can at least keep the same numbering plan when they switch from one PA
> prefix to another.
> 

That would be nice as well, but, unfortunately, it is obvious at this point
that some ISPs will unfortunately refuse to give home users /48s.

> Greets,
> Jeroen
> 
> PS: the more power to your kids if they can sniff the network for your
> 'adult content', decode it, and then actually watch it (though if they
> are technically inclined actually not too difficult, but heck, is that
> not where crypto comes into play, as when they can pull that off on your
> kiddienetwork they can also just plug something into the kiddie-'adult
> content'-network and sniff it off there... something with 802.1x comes
> to mind to solve that step.

The chances of the average amplifier and television supporting that
level of encryption in a way that the hypothetical kids in this situation
would be unable to decrypt a stream that does work between the
source and the television and amplifier are pretty slim IMHO.

Heck, I can't even get any one of those devices to speak IPv6 yet, let
alone all of them and with cryptography to boot.

Owen

Re: IPv6 end user addressing

[Jeff Wheeler]

On Wed, Aug 10, 2011 at 6:55 AM, Alexander Harrowell
 wrote:
> Thinking about the CPE thread, isn't this a case for bridging as a
> feature in end-user devices? If Joe's media-centre box etc would bridge
> its downstream ports to the upstream port, the devices on them could
> just get an address, whether by DHCPv6 from the CPE router's delegation
> or by SLAAC, and then register in local DNS or more likely do multicast-
> DNS so they could find each other.

This would require the ISP gateway to have IPv6 ND entries for all of
the end-user's devices.  If that is only a few devices, like the
typical SOHO LAN today, that's probably fine.  It is not fine if I
purchase some IPv6-connected nanobots.  Given today's routers, it is
probably not even fine if the average SOHO goes from 1 state entry to
just 20 or 30.  I have about 20 devices in my home that use the
Internet -- TVs, DVRs, VoIP telephones, printer, mobile phones with
Wi-Fi, a couple of video game consoles, etc.  I imagine that is not
atypical these days.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: IPv6 end user addressing

[Jeff Wheeler]

On Wed, Aug 10, 2011 at 2:03 PM, Owen DeLong  wrote:
> That said, /48 to the home should be what is happening, and /56 is
> a better compromise than anything smaller.

Is hierarchical routing within the SOHO network the reason you believe
/48 is useful?  You don't really imagine that end-users will require
more than 2^8 subnets, but that they will want several levels of very
simple, nibble-aligned routers within their network?

This is perhaps a good discussion to have.  I, for one, see CPE
vendors still shipping products without IPv6 support at all, let alone
any mechanism for creating an address or routing hierarchy within the
home without the end-user configuring it himself.  I am not aware of
any automatic means to do this, or even any working group trying to
produce that feature.

Is it true that there is no existing work on this?  If that is the
case, why would we not try to steer any such future work in such a way
that it can manage to do what the end-user wants without requiring a
/48 in their home?

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: IPv6 end user addressing

[Scott Helms]

Tim,

Hence the "might".  I worry when people start throwing around terms 
like routing in the home that they don't understand the complexities of 
balancing the massive CPE installed base, technical features, end user 
support, ease of installation & managemenet, and (perhaps most 
importantly) the economics of mass adoption.  This one of the choices 
that made DSL deployments more complex and expensive than DOCSIS cable 
deployments which in turn caused the CEO of AT&T to say their entire DSL 
network is obsolete.

http://goo.gl/exwqu



On 8/10/2011 12:57 PM, Tim Chown wrote:

On 10 Aug 2011, at 16:11, Scott Helms wrote:


Neither of these are true, though in the future we _might_ have deployable 
technology that allows for automated routing setup (though I very seriously 
doubt it) in the home.  Layer 2 isolation is both easier and more reliable than 
attempting it at layer 3 which is isolation by agreement, i.e. it doesn't 
really exist.

Well, there is some new effort on this in the homenet WG in IETF.

For snooping IPv6 multicast it's MLD snooping rather than IGMP.  We use it in 
our enterprise since we have multiple multicast video channels in use.

Tim


On 8/10/2011 9:02 AM, Owen DeLong wrote:

Bridging eliminates the multicast isolation that you get from routing.

This is not a case for bridging, it's a case for making it possible to do real
routing in the home and we now have the space and the technology to
actually do it in a meaningful and sufficiently automatic way as to be
applicable to Joe 6-Mac.


--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000

http://twitter.com/kscotthelms









--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000

http://twitter.com/kscotthelms

Re: IPv6 end user addressing

[Owen DeLong]

There is some deployable technology that allows some aspects of this today.
Yes, it's in its infancy. Small prefix limitations will guarantee it never sees 
the
light of day just as NAT precluded many useful innovations from getting 
deployed.

Layer 3 isolation is only isolation by agreement if the hosts have some way
to get on the same physical or logical LAN layer 2 segment. Otherwise, layer 3
isolation is as effective as any firewall. Layer 2 isolation, OTOH, is both
harder to administer and no more effective than layer 3. If you can bypass 
layer 3
by connecting to the same LAN segment, chances are you can bypass layer 2
by making that LAN segment one which doesn't go through the enforcement
switch between the two devices in question.

Owen

On Aug 10, 2011, at 8:11 AM, Scott Helms wrote:

> Neither of these are true, though in the future we _might_ have deployable 
> technology that allows for automated routing setup (though I very seriously 
> doubt it) in the home.  Layer 2 isolation is both easier and more reliable 
> than attempting it at layer 3 which is isolation by agreement, i.e. it 
> doesn't really exist.
> 
> On 8/10/2011 9:02 AM, Owen DeLong wrote:
>> 
>> Bridging eliminates the multicast isolation that you get from routing.
>> 
>> This is not a case for bridging, it's a case for making it possible to do 
>> real
>> routing in the home and we now have the space and the technology to
>> actually do it in a meaningful and sufficiently automatic way as to be
>> applicable to Joe 6-Mac.
>> 
> 
> -- 
> Scott Helms
> Vice President of Technology
> ISP Alliance, Inc. DBA ZCorum
> (678) 507-5000
> 
> http://twitter.com/kscotthelms
> 
> 

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 10, 2011, at 11:17 AM, Jeff Wheeler wrote:

> On Wed, Aug 10, 2011 at 2:03 PM, Owen DeLong  wrote:
>> That said, /48 to the home should be what is happening, and /56 is
>> a better compromise than anything smaller.
> 
> Is hierarchical routing within the SOHO network the reason you believe
> /48 is useful?  You don't really imagine that end-users will require
> more than 2^8 subnets, but that they will want several levels of very
> simple, nibble-aligned routers within their network?
> 

Not necessarily nibble aligned, but, multiple bits per level, yes.

> This is perhaps a good discussion to have.  I, for one, see CPE
> vendors still shipping products without IPv6 support at all, let alone
> any mechanism for creating an address or routing hierarchy within the
> home without the end-user configuring it himself.  I am not aware of
> any automatic means to do this, or even any working group trying to
> produce that feature.
> 

If we are stingy in address allocations, it will stifle such innovations as
the vendors tend to develop to the lowest common denominator. If we
make the allocations available, innovative ideas will make use of them.

> Is it true that there is no existing work on this?  If that is the
> case, why would we not try to steer any such future work in such a way
> that it can manage to do what the end-user wants without requiring a
> /48 in their home?
> 

No, it is not true.

I suppose that limiting enough households to too small an allocation
will have that effect. I would rather we steer the internet deployment
towards liberal enough allocations to avoid such disability for the
future.

Have we learned nothing from the way NAT shaped the (lack of)
innovation in the home?

Owen

Re: IPv6 end user addressing

[Jeff Wheeler]

On Wed, Aug 10, 2011 at 7:12 PM, Owen DeLong  wrote:
>> Is it true that there is no existing work on this?  If that is the
>> case, why would we not try to steer any such future work in such a way
>> that it can manage to do what the end-user wants without requiring a
>> /48 in their home?
>
> No, it is not true.

Can you give any example of a product, or on-going work?  I have read
two posts from you today saying that something either exists already,
or is being worked on.  I haven't read this anywhere else.

> I suppose that limiting enough households to too small an allocation
> will have that effect. I would rather we steer the internet deployment
> towards liberal enough allocations to avoid such disability for the
> future.
>
> Have we learned nothing from the way NAT shaped the (lack of)
> innovation in the home?

I am afraid we may not have learned from exhausting IPv4.  If I may
use the Hurricane Electric tunnel broker as an example again,
supposing that is an independent service with no relation to your
hosting, transit, etc. operations, it can justify a /24 allocation
immediately under 2011-3, without even relying on growth projections.
That's a middle ground figure that we can all live with, but it is
based on you serving (at this moment) only 8000 tunnels at your
busiest tunnel gateway.  If your tunnel gateways could serve 12,288 +
1 users each, then your /24 justification grows to a /20.  So you
would have a pretty significant chunk of the available IPv6 address
space for a fairly small number of end-users -- about 72,543 at
present.

It isn't hard to do some arithmetic and guess that if every household
in the world had IPv6 connectivity from a relatively low-density
service like the above example, we would still only burn through about
3% of the IPv6 address space on end-users (nothing said about server
farms, etc. here) but what does bother me is that the typical end-user
today has one, single IP address; and now we will be issuing them 2^16
subnets; yet it is not too hard to imagine a future where the global
IPv6 address pool becomes constrained due to service-provider
inefficiency.

I would like to have innovations in SOHO devices, too; who knows what
these may be.  But I fear we may repeat the mistake that caused NAT to
be a necessity in IPv4 -- exhausting address space -- by foolishly
assuming that every household is going to need twenty-four orders of
magnitude more public addresses than it has today.

That is what these practices do -- they literally give end-users
twenty-four orders of magnitude more addresses, while it is easy to
imagine that we will come within one order of magnitude of running
completely out of IPv6 addresses for issuing to service providers.

I didn't know what the digit "1" followed by twenty-four zeroes was
called.  I had to look it up.  So our end-users will be receiving
about one-Septillion addresses to use in their home, but no one seems
to be asking what future technology we may be harming by possibly
constraining the global address pool.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: IPv6 end user addressing

[Mark Andrews]

In message 
, Jeff Wheeler writes:
> On Wed, Aug 10, 2011 at 7:12 PM, Owen DeLong  wrote:
> >> Is it true that there is no existing work on this? =A0If that is the
> >> case, why would we not try to steer any such future work in such a way
> >> that it can manage to do what the end-user wants without requiring a
> >> /48 in their home?
> >
> > No, it is not true.
> 
> Can you give any example of a product, or on-going work?  I have read
> two posts from you today saying that something either exists already,
> or is being worked on.  I haven't read this anywhere else.
> 
> > I suppose that limiting enough households to too small an allocation
> > will have that effect. I would rather we steer the internet deployment
> > towards liberal enough allocations to avoid such disability for the
> > future.
> >
> > Have we learned nothing from the way NAT shaped the (lack of)
> > innovation in the home?
> 
> I am afraid we may not have learned from exhausting IPv4.  If I may
> use the Hurricane Electric tunnel broker as an example again,
> supposing that is an independent service with no relation to your
> hosting, transit, etc. operations, it can justify a /24 allocation
> immediately under 2011-3, without even relying on growth projections.
> That's a middle ground figure that we can all live with, but it is
> based on you serving (at this moment) only 8000 tunnels at your
> busiest tunnel gateway.  If your tunnel gateways could serve 12,288 +
> 1 users each, then your /24 justification grows to a /20.  So you
> would have a pretty significant chunk of the available IPv6 address
> space for a fairly small number of end-users -- about 72,543 at
> present.
> 
> It isn't hard to do some arithmetic and guess that if every household
> in the world had IPv6 connectivity from a relatively low-density
> service like the above example, we would still only burn through about
> 3% of the IPv6 address space on end-users (nothing said about server
> farms, etc. here) but what does bother me is that the typical end-user
> today has one, single IP address; and now we will be issuing them 2^16
> subnets; yet it is not too hard to imagine a future where the global
> IPv6 address pool becomes constrained due to service-provider
> inefficiency.

No.  A typical user has 10 to 20 addresses NAT'd to one public address.
My household has

* game consoles
* laptops
* desktops
* cell phones
* voip phones
* printers

all connected to the net.  It doesn't yet have a media server but otherwise
it is pretty typical.

Someday, I expect the pantry to have a barcode reader on it connected back
a computer setup for the kitchen someday.  Most of us already use barcode
readers when we shop so its not a big step to home use.

Just about anything with fireware in it will eventually connect to the net.

The typical household already has 1 or 2 subnets.

> I would like to have innovations in SOHO devices, too; who knows what
> these may be.  But I fear we may repeat the mistake that caused NAT to
> be a necessity in IPv4 -- exhausting address space -- by foolishly
> assuming that every household is going to need twenty-four orders of
> magnitude more public addresses than it has today.
> 
> That is what these practices do -- they literally give end-users
> twenty-four orders of magnitude more addresses, while it is easy to
> imagine that we will come within one order of magnitude of running
> completely out of IPv6 addresses for issuing to service providers.

Housholds can get as much internal addressing as they need today and as
many nets as they need today with RFC1918.  10/8 broken up into
to /24 is equivalent to a /48 broken up into /64s.

A /56 is equivalent to 192.168/16 broken up into its class C's.
 
> I didn't know what the digit "1" followed by twenty-four zeroes was
> called.  I had to look it up.  So our end-users will be receiving
> about one-Septillion addresses to use in their home, but no one seems
> to be asking what future technology we may be harming by possibly
> constraining the global address pool.

There was a concious decision made a decade and a half ago to got to
128 bits instead of 64 bits and give each subnet 64 bits so we would
never have to worry about the size of a subnet again.  IPv6 is about
managing networks not managing addresses.
 
> --=20
> Jeff S Wheeler 
> Sr Network Operator=A0 /=A0 Innovative Network Concepts
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPv6 end user addressing

[james machado]

> It isn't hard to do some arithmetic and guess that if every household
> in the world had IPv6 connectivity from a relatively low-density
> service like the above example, we would still only burn through about
> 3% of the IPv6 address space on end-users (nothing said about server
> farms, etc. here) but what does bother me is that the typical end-user
> today has one, single IP address; and now we will be issuing them 2^16
> subnets; yet it is not too hard to imagine a future where the global
> IPv6 address pool becomes constrained due to service-provider
> inefficiency.
>

what is the life expectancy of IPv6?  It won't live forever and we
can't reasonably expect it too.  I understand we don't want run out of
addresses in the next 10-40 years but what about 100? 200? 300?

We will run out and our decedents will go through re-numbering again.
The question becomes what is the life expectancy of IPv6 and does the
allocation plan make a reasonable attempt to run out of addresses
around the end of the expected life of IPv6.


> Jeff S Wheeler 
> Sr Network Operator  /  Innovative Network Concepts
>
>

james

Re: IPv6 end user addressing

[Mark Andrews]

In message 
, james machado writes:
> > It isn't hard to do some arithmetic and guess that if every household
> > in the world had IPv6 connectivity from a relatively low-density
> > service like the above example, we would still only burn through about
> > 3% of the IPv6 address space on end-users (nothing said about server
> > farms, etc. here) but what does bother me is that the typical end-user
> > today has one, single IP address; and now we will be issuing them 2^16
> > subnets; yet it is not too hard to imagine a future where the global
> > IPv6 address pool becomes constrained due to service-provider
> > inefficiency.
> >
> 
> what is the life expectancy of IPv6?  It won't live forever and we
> can't reasonably expect it too.  I understand we don't want run out of
> addresses in the next 10-40 years but what about 100? 200? 300?
> 
> We will run out and our decedents will go through re-numbering again.
> The question becomes what is the life expectancy of IPv6 and does the
> allocation plan make a reasonable attempt to run out of addresses
> around the end of the expected life of IPv6.

It really depends on whether the RIR's recover and, importantly,
reallocate address space that is not being paid for or not.  If
they do this should last for the forseeable future.  It would also
be my recommendation that RIR's start doing this immediately, if
they are not already doing so, so that there is no expectation that
you can use address space forever without paying for it.

> > Jeff S Wheeler 
> > Sr Network Operator=A0 /=A0 Innovative Network Concepts
> >
> >
> 
> james
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPv6 end user addressing

[Jeff Wheeler]

On Wed, Aug 10, 2011 at 8:40 PM, Mark Andrews  wrote:
> No.  A typical user has 10 to 20 addresses NAT'd to one public address.

I'd say this is fair.  Amazingly enough, it all basically works right
with one IP address today.  It will certainly be nice to have the
option to give all these devices public IP addresses, or even have a
few public subnets; but it does require more imagination than any of
us have demonstrated to figure out how any end-user will need more
than 2^8 subnets.  That's still assuming that device-makers won't
decide they need to be able to operate with subnets of arbitrary size,
rather than fixed-size /64 subnets.

> There was a concious decision made a decade and a half ago to got to
> 128 bits instead of 64 bits and give each subnet 64 bits so we would
> never have to worry about the size of a subnet again.  IPv6 is about
> managing networks not managing addresses.

Thanks for the explanation of how to subnet IPv4 networks and use
RFC1918.  I hope most readers are already familiar with these
concepts.  You should note that IPv6 was not, in fact, originally
envisioned with /64 subnets; that figure was to be /80 or /96.  In the
mid-1990s, it was believed that dramatically increasing the number of
bits available for ISP routing flexibility was very beneficial, as
well as making access subnets so big that they should never need to
grow.  Then SLAAC came along.  Except SLAAC doesn't do necessary
things that DHCPv6 does, and the cost of implementing things like
DHCPv6 in very small, inexpensive devices has gone down dramatically.

I am amazed that so few imagine we might, in within the lifetime of
IPv6, like to have more bits of address space for routing structure
within ISP networks; but these people do think that end-users need
1.2e+24 addresses for the devices they'll have in their home.

I don't have to use my imagination to think of ways that additional
bits on the network address side would have been advantageous -- all I
need is my memory.  In the 90s, it was suggested that a growing number
of dual-homed networks cluttering the DFZ could be handled more
efficiently by setting aside certain address space for customers who
dual-homed to pairs of the largest ISPs.  The customer routes would
then not need to be carried by anyone except those two ISPs, who are
earning money from the customer.  This never happened for a variety of
good reasons, but most of the technical reasons would have gone away
with the adoption of IPv6, as it was envisioned in the mid-90s.

There seems to be a lot of imagination being used for SOHO networks,
and none on the ISP side.  What a shame that is.

Owen, I do agree with the point you made off-list, that if huge
mistakes are made now and the IPv6 address space is consumed more
rapidly than the community is comfortable with, there should be plenty
of opportunity to fix that down the road.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: IPv6 end user addressing

[Owen DeLong]

> 
> Someday, I expect the pantry to have a barcode reader on it connected back
> a computer setup for the kitchen someday.  Most of us already use barcode
> readers when we shop so its not a big step to home use.
> 

Nah... That's short-term thinking. The future holds advanced pantries with
RFID sensors that know what is in the pantry and when they were manufactured,
what their expiration date is, etc. The refrigerator will have not only the
necessary RFID sensors, but, multiple pressure transducers capable of
recognizing not only that there is a carton of milk in the refrigerator, but,
how much milk is remaining.

You'll be able to scan a QR code in the grocery store that links to a recipe
for something you thought would be good for dinner, pass the ingredient
list to the web server in the refrigerator and get back a nearly instant
reply containing the relevant inventory list and a list of items you need
to buy to complete the recipe.

> Just about anything with fireware in it will eventually connect to the net.
> 
I think you meant firmware, and, I'd say that a lot of things (cans, jars,
milk cartons, etc.) that don't currently connect to the net will actually
form IP adjacencies in the future.

> The typical household already has 1 or 2 subnets.
> 
Or even more in some cases (LAN, WLAN, WLAN Guest, DMZ for example).

>> I would like to have innovations in SOHO devices, too; who knows what
>> these may be.  But I fear we may repeat the mistake that caused NAT to
>> be a necessity in IPv4 -- exhausting address space -- by foolishly
>> assuming that every household is going to need twenty-four orders of
>> magnitude more public addresses than it has today.
>> 
>> That is what these practices do -- they literally give end-users
>> twenty-four orders of magnitude more addresses, while it is easy to
>> imagine that we will come within one order of magnitude of running
>> completely out of IPv6 addresses for issuing to service providers.
> 
> Housholds can get as much internal addressing as they need today and as
> many nets as they need today with RFC1918.  10/8 broken up into
> to /24 is equivalent to a /48 broken up into /64s.
> 
> A /56 is equivalent to 192.168/16 broken up into its class C's.
> 
Good point.

>> I didn't know what the digit "1" followed by twenty-four zeroes was
>> called.  I had to look it up.  So our end-users will be receiving
>> about one-Septillion addresses to use in their home, but no one seems
>> to be asking what future technology we may be harming by possibly
>> constraining the global address pool.
> 
> There was a concious decision made a decade and a half ago to got to
> 128 bits instead of 64 bits and give each subnet 64 bits so we would
> never have to worry about the size of a subnet again.  IPv6 is about
> managing networks not managing addresses.
> 
Yep.

Owen

Re: IPv6 end user addressing

[William Herrin]

On Wed, Aug 10, 2011 at 2:17 PM, Jeff Wheeler  wrote:
> On Wed, Aug 10, 2011 at 2:03 PM, Owen DeLong  wrote:
>> That said, /48 to the home should be what is happening, and /56 is
>> a better compromise than anything smaller.
>
> You don't really imagine that end-users will require
> more than 2^8 subnets, but that they will want several levels of very
> simple, nibble-aligned routers within their network?

Hi Jeff,

In Owen's world, the refrigerator, toaster and microwave each request
a /64 from the GE Home Appliance Controller, those /64's being
necessary to address each appliance's internal button, light and
sensor networks. To accommodate all of these appliances, the HAC has
acquired a /59 for all the home appliances from the Home Automation
System (HAS) which also has its own LAN and supplied a big block to
the furnace and a smaller block to the security system. So, the HAS
needed a /58 which it got from the Linksys Home Router.

The Sony Home Entertainment Network (HEN) Controller also needed a /58
from the Home Router to accommodate the Playstation 5's need for a /62
(one /64 for its internal network, another for the PSN VPN and a third
for the peripherals network). The Ultra-NES 512 only needed one /64,
but the amplifier insisted on a /60 so it could delegate /64's to the
cassette tape deck, cd player, mp3 player, etc.

The Ford Home Automotive Network (HAN) also grabbed a block from which
to delegate /62's to the three parked cars. Because you know: you need
separate networks in each car for the life safety systems, the
non-safety systems and the entertainment systems. I mean really, why
wouldn't the life safety system in a car dynamically acquire its
globally-addressable IPv6 addresses from the customer's cheap home
Internet equipment? So they'll each need their /64's which means the
car as a whole needs a /62. But the HAN only needed a /60 for for all
of it since there were only 3 cars.

Now, the Windows 9 PC sat on the /64 PC LAN directly connected to the
Home Router, but it needed an additional /64 for its virtual machine
network hosting the Windows XP VM needed to run older software. And
the wireless LAN only ended up consuming a single /64. But after the
two /58's, that meant the Home Router needed a full /56 from the
Internet Router.

Finally, the Internet Router connects two networks... the customer's
web server DMZ (/64) and the home router (/56). So after you figure in
the HAC, the HAN, the HAS, the HEN and all the other connections you
need at least a /55... which doesn't fit in a /56 but does fit in a
/48. Qed. *



Now, in Bill's world, the appliances don't expose their internals.
When they employ any form of IP networking inside, which they
generally don't, they use fe80 link-local addresses inside or maybe a
ULA prefix.  So even you have a Smart Fridge within the time span that
you care about for today's home user IPv6 assignments, it occupies a
single public address on your home's flat /64. Ditto the game consoles
and tape decks. With maybe two other /64's: one for servers and one
for the wireless LAN. And that /62 need easily fits in your /56
assignment.


Regards,
Bill Herrin


* I say this with trepidation. A quarter century ago I used a similar
reductio ad absurdum with a friend who suggested making every road a
toll road. "Back out of the driveway. Pay the toll. Turn on to main.
Pay the toll. Left on 15th. Pay the toll." Wouldn't you know, E-Z Pass
came along and brought it to the edge of possible. Then again,
possible doesn't necessarily mean advisable.

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv6 end user addressing

[William Herrin]

On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong  wrote:
>> Someday, I expect the pantry to have a barcode reader on it connected back
>> a computer setup for the kitchen someday.  Most of us already use barcode
>> readers when we shop so its not a big step to home use.
>
> Nah... That's short-term thinking. The future holds advanced pantries with
> RFID sensors that know what is in the pantry and when they were manufactured,
> what their expiration date is, etc.

And since your can of creamed corn is globally addressable, the rest
of the world knows what's in your pantry too. ;)

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv6 end user addressing

[Brian E Carpenter]

On 2011-08-11 12:45, james machado wrote:

> what is the life expectancy of IPv6?  It won't live forever and we
> can't reasonably expect it too.  I understand we don't want run out of
> addresses in the next 10-40 years but what about 100? 200? 300?
> 
> We will run out and our decedents will go through re-numbering again.
> The question becomes what is the life expectancy of IPv6 and does the
> allocation plan make a reasonable attempt to run out of addresses
> around the end of the expected life of IPv6.

Well, we know that the human population will stabilise somewhere below
ten billion by around 2050. The current unicast space provides for about
15 trillion /48s. Let's assume that the RIRs and ISPs retain their current
level of engineering common sense - i.e. the address space will begin to be
really full when there are about 25% of those /48s being routed... that makes
3.75 trillion /48s routed for ten billion people, or 375 /48s per man, woman
and child. (Or about 25 million /64s if you prefer.)

At that point, IANA would have to release unicast space other than 2000::/3
and we could start again with a new allocation policy.

I am *really* not worried about this. Other stuff, such as BGP4, will break
irrevocably long before this.

   Brian

Re: IPv6 end user addressing

[Owen DeLong]

> 
> I don't have to use my imagination to think of ways that additional
> bits on the network address side would have been advantageous -- all I
> need is my memory.  In the 90s, it was suggested that a growing number
> of dual-homed networks cluttering the DFZ could be handled more
> efficiently by setting aside certain address space for customers who
> dual-homed to pairs of the largest ISPs.  The customer routes would
> then not need to be carried by anyone except those two ISPs, who are
> earning money from the customer.  This never happened for a variety of
> good reasons, but most of the technical reasons would have gone away
> with the adoption of IPv6, as it was envisioned in the mid-90s.
> 


I think that can still be very realistically achieved within the existing 
available
address space.

> There seems to be a lot of imagination being used for SOHO networks,
> and none on the ISP side.  What a shame that is.
> 

I disagree.

> Owen, I do agree with the point you made off-list, that if huge
> mistakes are made now and the IPv6 address space is consumed more
> rapidly than the community is comfortable with, there should be plenty
> of opportunity to fix that down the road.
> 

Precisely, so, let's risk a small chance of a mistake here now so that we don't
cut off innovation so early.

Owen

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 10, 2011, at 6:46 PM, William Herrin wrote:

> On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong  wrote:
>>> Someday, I expect the pantry to have a barcode reader on it connected back
>>> a computer setup for the kitchen someday.  Most of us already use barcode
>>> readers when we shop so its not a big step to home use.
>> 
>> Nah... That's short-term thinking. The future holds advanced pantries with
>> RFID sensors that know what is in the pantry and when they were manufactured,
>> what their expiration date is, etc.
> 
> And since your can of creamed corn is globally addressable, the rest
> of the world knows what's in your pantry too. ;)
> 

This definitely helps explain your misconceptions about NAT as a security tool.


Globally addressable != globally reachable.

Things can have global addresses without having global reachability. There are
these tools called access control lists and routing policies. Perhaps you've 
heard
of them. They can be quite useful.

Owen

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 10, 2011, at 6:43 PM, William Herrin wrote:

> On Wed, Aug 10, 2011 at 2:17 PM, Jeff Wheeler  wrote:
>> On Wed, Aug 10, 2011 at 2:03 PM, Owen DeLong  wrote:
>>> That said, /48 to the home should be what is happening, and /56 is
>>> a better compromise than anything smaller.
>> 
>> You don't really imagine that end-users will require
>> more than 2^8 subnets, but that they will want several levels of very
>> simple, nibble-aligned routers within their network?
> 
> Hi Jeff,
> 
> In Owen's world, the refrigerator, toaster and microwave each request
> a /64 from the GE Home Appliance Controller, those /64's being
> necessary to address each appliance's internal button, light and
> sensor networks. To accommodate all of these appliances, the HAC has
> acquired a /59 for all the home appliances from the Home Automation
> System (HAS) which also has its own LAN and supplied a big block to
> the furnace and a smaller block to the security system. So, the HAS
> needed a /58 which it got from the Linksys Home Router.
> 
> The Sony Home Entertainment Network (HEN) Controller also needed a /58
> from the Home Router to accommodate the Playstation 5's need for a /62
> (one /64 for its internal network, another for the PSN VPN and a third
> for the peripherals network). The Ultra-NES 512 only needed one /64,
> but the amplifier insisted on a /60 so it could delegate /64's to the
> cassette tape deck, cd player, mp3 player, etc.
> 
> The Ford Home Automotive Network (HAN) also grabbed a block from which
> to delegate /62's to the three parked cars. Because you know: you need
> separate networks in each car for the life safety systems, the
> non-safety systems and the entertainment systems. I mean really, why
> wouldn't the life safety system in a car dynamically acquire its
> globally-addressable IPv6 addresses from the customer's cheap home
> Internet equipment? So they'll each need their /64's which means the
> car as a whole needs a /62. But the HAN only needed a /60 for for all
> of it since there were only 3 cars.
> 
> Now, the Windows 9 PC sat on the /64 PC LAN directly connected to the
> Home Router, but it needed an additional /64 for its virtual machine
> network hosting the Windows XP VM needed to run older software. And
> the wireless LAN only ended up consuming a single /64. But after the
> two /58's, that meant the Home Router needed a full /56 from the
> Internet Router.
> 
> Finally, the Internet Router connects two networks... the customer's
> web server DMZ (/64) and the home router (/56). So after you figure in
> the HAC, the HAN, the HAS, the HEN and all the other connections you
> need at least a /55... which doesn't fit in a /56 but does fit in a
> /48. Qed. *
> 
> 
Thanks... An excellent write up, even if it was intended tongue in cheek.

However, you left out the need for addressing for the RFID tags that will
end up on most groceries, etc.

> 
> Now, in Bill's world, the appliances don't expose their internals.
> When they employ any form of IP networking inside, which they
> generally don't, they use fe80 link-local addresses inside or maybe a
> ULA prefix.  So even you have a Smart Fridge within the time span that
> you care about for today's home user IPv6 assignments, it occupies a
> single public address on your home's flat /64. Ditto the game consoles
> and tape decks. With maybe two other /64's: one for servers and one
> for the wireless LAN. And that /62 need easily fits in your /56
> assignment.
> 

I'm glad I live in Owen's world and not Bill's. I think my appliance vendors
will make much cooler and more useful products than yours.

Owen

Re: IPv6 end user addressing

[Philip Dorr]

On Wed, Aug 10, 2011 at 8:56 PM, Owen DeLong  wrote:
>
> I'm glad I live in Owen's world and not Bill's. I think my appliance vendors
> will make much cooler and more useful products than yours.

In Owen's world the fridge and pantry would know what they have, the
amounts, and possibly location. The recipe book would be able to check
what is in the fridge and pantry and tell if you need to buy more.  It
could then set the oven to the correct temperature when you reach the
correct step in the recipe.

Yes, all that could be done with servers on the pantry and fridge, but
then there would be different implementations of each protocol and
incompatibilities between the fridge, pantry, recipe book, and oven.

Re: IPv6 end user addressing

[Mark Newton]

On 11/08/2011, at 8:42 AM, Owen DeLong wrote:
> 
> I suppose that limiting enough households to too small an allocation
> will have that effect. I would rather we steer the internet deployment
> towards liberal enough allocations to avoid such disability for the
> future.


I see the lack of agreement on whether /48 or /56 or /60 is good for a
home network to be a positive thing.

As long as there's no firm consensus, router vendors will have to implement
features which don't make silly hard-coded assumptions.

Innovation will still happen, features will still be implemented, we'll
still climb out of the NAT morass.  But we'll do it with CPE that allows for
a richer spectrum of variation than we would if we just said, "Dammit, /48 for
everyone."

It's all good.  At this stage of the game, any amount of "moving forward" is
better than staying where we are.

(which reminds me: http://www.internode.on.net/news/2011/08/238.php It ain't
that hard)

  - mark

--
Mark Newton   Email:  new...@internode.com.au (W)
Network Engineer  Email:  new...@atdot.dotat.org  (H)
Internode Pty Ltd Desk:   +61-8-82282999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223

Re: IPv6 end user addressing

[Mark Newton]

On 11/08/2011, at 12:04 PM, Philip Dorr wrote:

> On Wed, Aug 10, 2011 at 8:56 PM, Owen DeLong  wrote:
>> 
>> I'm glad I live in Owen's world and not Bill's. I think my appliance vendors
>> will make much cooler and more useful products than yours.
> 
> In Owen's world the fridge and pantry would know what they have, the
> amounts, and possibly location. The recipe book would be able to check
> what is in the fridge and pantry and tell if you need to buy more.  It
> could then set the oven to the correct temperature when you reach the
> correct step in the recipe.


The wine cellar will know how much you drank last night, and communicate with
the life-critical systems in the car to prevent engine start while you're
over the limit.  When the home BMS network notices that the flow sensor on the
shower hasn't started at the usual time the next morning, it'll play an IVR
out of your home PBX network to tell the boss you're too hungover to come to
work.

Owen's world has built in automated protection to help you through the fact that
IPv6 subnetting will turn you to drink :-)

  - mark

--
Mark Newton   Email:  new...@internode.com.au (W)
Network Engineer  Email:  new...@atdot.dotat.org  (H)
Internode Pty Ltd Desk:   +61-8-82282999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223

Re: IPv6 end user addressing

[Cameron Byrne]

On Aug 10, 2011 7:45 PM, "Mark Newton"  wrote:
>
>
> On 11/08/2011, at 8:42 AM, Owen DeLong wrote:
> >
> > I suppose that limiting enough households to too small an allocation
> > will have that effect. I would rather we steer the internet deployment
> > towards liberal enough allocations to avoid such disability for the
> > future.
>
>
> I see the lack of agreement on whether /48 or /56 or /60 is good for a
> home network to be a positive thing.
>
> As long as there's no firm consensus, router vendors will have to
implement
> features which don't make silly hard-coded assumptions.
>
> Innovation will still happen, features will still be implemented, we'll
> still climb out of the NAT morass.  But we'll do it with CPE that allows
for
> a richer spectrum of variation than we would if we just said, "Dammit, /48
for
> everyone."
>
> It's all good.  At this stage of the game, any amount of "moving forward"
is
> better than staying where we are.
>
> (which reminds me: http://www.internode.on.net/news/2011/08/238.php It
ain't
> that hard)
>

Finally a useful post in this thread.  Good work on the deployment of real
ipv6!

Cb

>  - mark
>
> --
> Mark Newton   Email:  new...@internode.com.au(W)
> Network Engineer  Email:  new...@atdot.dotat.org (H)
> Internode Pty Ltd Desk:   +61-8-82282999
> "Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223
>
>
>
>
>
>

Re: IPv6 end user addressing

[Mark Newton]

On 11/08/2011, at 12:30 PM, Cameron Byrne wrote:
> Finally a useful post in this thread.  Good work on the deployment of real 
> ipv6!
> 

Thanks. And thanks to Vendor-C for helping us through it.  The IPv6 Broadband
featureset on the ASR platform starting from IOS-XR 3.1 is a vast improvement
on its predecessors.

Biggest hassle with IPv6 in production right now:  DNS support is woefully 
undercooked.  I don't think anyone has put anywhere near as much effort into
making it fluid, user-friendly, and automated.  Simple questions like, "How
are reverse mappings supposed to work when you can't predict an end-user's
address?" have no good answer.  If any systems folks want a nice meaty problem
domain to focus their efforts on, DNS would be da shiznit.

  - mark

--
Mark Newton   Email:  new...@internode.com.au (W)
Network Engineer  Email:  new...@atdot.dotat.org  (H)
Internode Pty Ltd Desk:   +61-8-82282999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223

Re: IPv6 end user addressing

[Mark Newton]

On 11/08/2011, at 12:41 PM, Mark Newton wrote:

> 
> On 11/08/2011, at 12:30 PM, Cameron Byrne wrote:
>> Finally a useful post in this thread.  Good work on the deployment of real 
>> ipv6!
>> 
> 
> Thanks. And thanks to Vendor-C for helping us through it.  The IPv6 Broadband
> featureset on the ASR platform starting from IOS-XR 3.1 is a vast improvement
> on its predecessors.

Oops.  s/XR/XE/

  - mark


--
Mark Newton   Email:  new...@internode.com.au (W)
Network Engineer  Email:  new...@atdot.dotat.org  (H)
Internode Pty Ltd Desk:   +61-8-82282999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223

Re: IPv6 end user addressing

[Michael Hare]

On 8/10/2011 8:46 PM, William Herrin wrote:

On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong  wrote:

Someday, I expect the pantry to have a barcode reader on it connected back
a computer setup for the kitchen someday.  Most of us already use barcode
readers when we shop so its not a big step to home use.


Nah... That's short-term thinking. The future holds advanced pantries with
RFID sensors that know what is in the pantry and when they were manufactured,
what their expiration date is, etc.


And since your can of creamed corn is globally addressable, the rest
of the world knows what's in your pantry too. ;)


I can't believe no one has made a joke yet about a kernel.

Sorry for the bad joke,
-Michael



Regards,
Bill Herrin

Re: IPv6 end user addressing

[Mark Newton]

On 11/08/2011, at 1:33 PM, Owen DeLong wrote:

> Yes and no. In terms of potential innovations, if enough of the market chooses
> /60, they will hard code the assumption that they cannot count on more than
> a /60 being available into their development process regardless of what
> gets into the router. Sure, they won't be able to assume you can't get a /48,
> but, they also won't necessarily implement features that would take advantage
> of a /48.

They will on their "premium" high price point CPE and/or service provider
offerings.  It'll be a product differentiator.  

If enough customers are attracted to it, it'll win.  If they
aren't, it'll lose.

The process of invention and innovation will happen anyway.  We're
not really talking about that here, we're talking about post-innovation
marketing.

Maybe ISP#2 in Australia will launch onto the market with /48's for everyone,
and we'll respond competitively.  Dunno.  Whatever, it's all kinda arbitrary
really.  Not worth arguing about, and certainly not worth delaying 
implementation until you finish debating the "right" answer.

> Perhaps far more than most of you wanted to know about navigation, but, at 
> least worth
> considering when we think that all forward movement is good forward movement.


The 1-in-60 rule I learned during my pilots license training is a lot easier
to explain, without diagrams and with no need for trigonometry.

Another useful judgement call when you're flying is to understand that
as long as you know where you are and where you want to be, any forward 
progress whatsoever is a positive when there's a growing thunderstorm
behind you :-)

  - mark


--
Mark Newton   Email:  new...@internode.com.au (W)
Network Engineer  Email:  new...@atdot.dotat.org  (H)
Internode Pty Ltd Desk:   +61-8-82282999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223

Re: IPv6 end user addressing

[Joel Jaeggli]

On Aug 10, 2011, at 6:52 PM, Brian E Carpenter wrote:

> On 2011-08-11 12:45, james machado wrote:
> 
>> what is the life expectancy of IPv6?  It won't live forever and we
>> can't reasonably expect it too.  I understand we don't want run out of
>> addresses in the next 10-40 years but what about 100? 200? 300?
>> 
>> We will run out and our decedents will go through re-numbering again.
>> The question becomes what is the life expectancy of IPv6 and does the
>> allocation plan make a reasonable attempt to run out of addresses
>> around the end of the expected life of IPv6.
> 
> Well, we know that the human population will stabilise somewhere below
> ten billion by around 2050. The current unicast space provides for about
> 15 trillion /48s. Let's assume that the RIRs and ISPs retain their current
> level of engineering common sense - i.e. the address space will begin to be
> really full when there are about 25% of those /48s being routed... that makes
> 3.75 trillion /48s routed for ten billion people, or 375 /48s per man, woman
> and child. (Or about 25 million /64s if you prefer.)

It's not the humans that are going to soak up the address space, so it seems a 
little misguided to count up the humans a reference for the bounding properties 
on growth. That said I think 2000::/3 will last long enough, that we shouldn't 
be out rewriting policy anytime soon.

> At that point, IANA would have to release unicast space other than 2000::/3
> and we could start again with a new allocation policy.
> 
> I am *really* not worried about this. Other stuff, such as BGP4, will break
> irrevocably long before this.

We have a few problems to solve along the way. Running the current network is 
hard enough as it is.

>   Brian
> 

Re: IPv6 end user addressing

[Joel Jaeggli]

On Aug 10, 2011, at 6:43 PM, William Herrin wrote:

> I mean really, why
> wouldn't the life safety system in a car dynamically acquire its
> globally-addressable IPv6 addresses from the customer's cheap home
> Internet equipment? So they'll each need their /64's which means the
> car as a whole needs a /62. But the HAN only needed a /60 for for all
> of it since there were only 3 cars.

several cars on the road today have cellular radios on more than one network ( 
the nissan leaf for example)

When you account for integration into the driver and passengers personal area 
networks (pans) as for example ford sync does today, and integration into home 
automation networks, (garage doors, lighting, media syncronization) and in the 
case of electric cars, the smart grid) why wouldn't a car, acquire addresses 
and be discoverable on the users home network? By the time this is fully 
realized, the car will be on quite a few networks, instead of just the two or 
three it's presently either supporting or attached to...

Re: IPv6 end user addressing

[Eugen Leitl]

On Thu, Aug 11, 2011 at 01:52:10PM +1200, Brian E Carpenter wrote:

> Well, we know that the human population will stabilise somewhere below
> ten billion by around 2050. The current unicast space provides for about

How about the machine population? How about self-replicating systems?
How about geography-based address allocation, to go away with global routing
tables? How about InterPlaNet, such as LEO routers, solar power
satellites, controlling industrial production on the Moon and elsewhere?

I don't expect IPv6 will last much longer than IPv4. And that's probably
a good thing.

> 15 trillion /48s. Let's assume that the RIRs and ISPs retain their current
> level of engineering common sense - i.e. the address space will begin to be
> really full when there are about 25% of those /48s being routed... that makes
> 3.75 trillion /48s routed for ten billion people, or 375 /48s per man, woman
> and child. (Or about 25 million /64s if you prefer.)
> 
> At that point, IANA would have to release unicast space other than 2000::/3
> and we could start again with a new allocation policy.
> 
> I am *really* not worried about this. Other stuff, such as BGP4, will break
> irrevocably long before this.

-- 
Eugen* Leitl http://leitl.org";>leitl http://leitl.org
__
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 10, 2011, at 8:29 PM, Joel Jaeggli wrote:

> 
> On Aug 10, 2011, at 6:52 PM, Brian E Carpenter wrote:
> 
>> On 2011-08-11 12:45, james machado wrote:
>> 
>>> what is the life expectancy of IPv6?  It won't live forever and we
>>> can't reasonably expect it too.  I understand we don't want run out of
>>> addresses in the next 10-40 years but what about 100? 200? 300?
>>> 
>>> We will run out and our decedents will go through re-numbering again.
>>> The question becomes what is the life expectancy of IPv6 and does the
>>> allocation plan make a reasonable attempt to run out of addresses
>>> around the end of the expected life of IPv6.
>> 
>> Well, we know that the human population will stabilise somewhere below
>> ten billion by around 2050. The current unicast space provides for about
>> 15 trillion /48s. Let's assume that the RIRs and ISPs retain their current
>> level of engineering common sense - i.e. the address space will begin to be
>> really full when there are about 25% of those /48s being routed... that makes
>> 3.75 trillion /48s routed for ten billion people, or 375 /48s per man, woman
>> and child. (Or about 25 million /64s if you prefer.)
> 
> It's not the humans that are going to soak up the address space, so it seems 
> a little misguided to count up the humans a reference for the bounding 
> properties on growth. That said I think 2000::/3 will last long enough, that 
> we shouldn't be out rewriting policy anytime soon.
> 

I disagree. I think current policy in several RIRs (APNIC, especially) is far 
too conservative
and that we do need to rewrite it. That's why I submitted prop-090 which has 
taken the
feedback I received into account and become prop-098.

Owen

RE: IPv6 end user addressing

[Jamie Bowden]

Owen wrote:

> -Original Message-
> From: Owen DeLong [mailto:o...@delong.com]
> Sent: Wednesday, August 10, 2011 9:58 PM
> To: William Herrin
> Cc: nanog@nanog.org
> Subject: Re: IPv6 end user addressing
> 
> 
> On Aug 10, 2011, at 6:46 PM, William Herrin wrote:
> 
> > On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong 
wrote:
> >>> Someday, I expect the pantry to have a barcode reader on it
> connected back
> >>> a computer setup for the kitchen someday.  Most of us already use
> barcode
> >>> readers when we shop so its not a big step to home use.
> >>
> >> Nah... That's short-term thinking. The future holds advanced
> pantries with
> >> RFID sensors that know what is in the pantry and when they were
> manufactured,
> >> what their expiration date is, etc.
> >
> > And since your can of creamed corn is globally addressable, the rest
> > of the world knows what's in your pantry too. ;)
> >
> 
> This definitely helps explain your misconceptions about NAT as a
> security tool.
> 
> 
> Globally addressable != globally reachable.
> 
> Things can have global addresses without having global reachability.
> There are
> these tools called access control lists and routing policies. Perhaps
> you've heard
> of them. They can be quite useful.

And your average home user, whose WiFi network is an open network named
"linksys" is going to do that how?

Jamie

RE: IPv6 end user addressing

[Frank Bulk]

This same Vendor C wants us to upgrade our 7206VXR's to ASR1K's just so we
have the (hopefully working) IPv6 features in IOS-XE that are broken in
12.x.

Frank

-Original Message-
From: Mark Newton [mailto:new...@internode.com.au] 
Sent: Wednesday, August 10, 2011 10:12 PM
To: Cameron Byrne
Cc: NANOG
Subject: Re: IPv6 end user addressing


On 11/08/2011, at 12:30 PM, Cameron Byrne wrote:
> Finally a useful post in this thread.  Good work on the deployment of real
ipv6!
> 

Thanks. And thanks to Vendor-C for helping us through it.  The IPv6
Broadband
featureset on the ASR platform starting from IOS-XR 3.1 is a vast
improvement
on its predecessors.

Biggest hassle with IPv6 in production right now:  DNS support is woefully 
undercooked.  I don't think anyone has put anywhere near as much effort into
making it fluid, user-friendly, and automated.  Simple questions like, "How
are reverse mappings supposed to work when you can't predict an end-user's
address?" have no good answer.  If any systems folks want a nice meaty
problem
domain to focus their efforts on, DNS would be da shiznit.

  - mark

--
Mark Newton   Email:  new...@internode.com.au
(W)
Network Engineer  Email:  new...@atdot.dotat.org
(H)
Internode Pty Ltd Desk:   +61-8-82282999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223