Re: minimum IPv6 announcement size

[Cutler James R]

I try not to think about sinners too much when planning networks. Subnets are 
more interesting.

Maybe many of you like spending time maintaining NAT configurations and 
creatively masking as determined by today's end system count on each subnet. 
This all, of course, in the interest of maximum address assignment efficiency, 
a term of only the most nebulous definition.

Hogwash, I say.  The days of counting end systems in order to determine 
addressing is GONE. And I, for one, am much pleased.

Let's optimize the person instead of micro-optimizing bits.  Count the subnets 
you really think you need, shift one or two bits left, and ask for /whatever as 
described by Owen.  "many many years" is probably multiples of the two decades 
or so of IPv4 we have experienced.

Continuing arguments on NANOG and elsewhere about /64 - Good or Bad - check 
one, are just wasting your time and mine. Get yourself into action and just get 
IPv6 deployed.  

Owen has the right of it.

Cutler


On Oct 1, 2013, at 4:20 PM, Owen DeLong  wrote:

> The original plan was to go from 32 to 64 bits total. The additional 64 bits 
> were added purely for the sake of EUI-64 based addressing, and really, 64 
> bits of network number is way more than enough. 
> 
> The /64 a are not what justify the larger blocks. That's IPv4 think. 
> 
> In IPv6, it is far better to think about the number of sinners without regard 
> to counting hosts. The /48 per site is justified because it is almost 
> inconceivable that a single site would ever need more than 65536 subnets. 
> 
> The /32 is a minimum reasonable allocation for an ISP to balance the tradeoff 
> between routing table entries and consumption. 
> 
> Most estimates say that the vast majority of significant providers will end 
> up using a /28 with some outliers on both sides. Many smaller providers will 
> end up with /32 and a few medium to large ones will get /24 or even /20. A 
> minute (probably less than 20 world wide) number might get /16s. 
> 
> Absent some novel (and IMHO I'll-advised) approach to semantic overloading, 
> we will have plenty of address space to number the internet for many many 
> years. 
> 
> Owen
> 
> 
>> On Oct 1, 2013, at 12:11, Ryan McIntosh  wrote:
>> 
>> I'd love to be able to turn the microwave and oven on with my phone..
>> maybe ten years from now lol..
>> 
>> In all seriousness though (and after skimming some of the other
>> responses), I absolutely understand the ideals and needs amongst
>> conserving memory on our routers for the sake of the future of bgp and
>> internal routing. The problem I described has nothing to do with that
>> however, I was mearly pointing out the fact that the basis of the
>> larger allocations are based upon the fact we're handing over /64's to
>> each vlan/point to point/lan/etc that we're turning up. In practice, I
>> understand, a /64 means that 64 bits can handle a unique ip for every
>> host without having to worry about numbering them, but how many hosts
>> do we truly think will be sitting on one network? Surely not a /64's
>> worth, that alone would cause havoc on a neighbor table's maximum
>> memory limit. Maybe I'm missing the connection here, but I still don't
>> see how a /64 is justified for each individual user/host/server/etc
>> sitting on the edge of the internet that's getting ip's from an
>> upstream provider (not arin/ripe/etc).
>> 
>> It's those smaller blocks that justify handing over larger ones, which
>> I do understand there's plenty of, but how long are we going to patch
>> the same problem and not try to fix it right?
>> 
>> Ryan
>> 
>>> On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon  wrote:
 On 9/27/2013 1:10 AM, Ryan McIntosh wrote:
 
 I don't respond to many of these threads but I have to say I've
 contested this one too only to have to beaten into my head that a /64
 is "appropriate".. it still hasn't stuck, but unfortunately rfc's for
 other protocols depend on the blocks to now be a /64..
 
 It's a waste, even if we're "planning for the future", no one house
 needs a /64 sitting on their lan.. or at least none I can sensibly
 think of o_O.
>>> 
>>> 
>>> 
>>> Are you accounting for connections to your refrigerator, water heater,
>>> razor, vibrator, and on down to list so the gubermint can tell they when you
>>> can use power for them?
>>> 
>>> --
>>> Requiescas in pace o email   Two identifying characteristics
>>>   of System Administrators:
>>> Ex turpi causa non oritur actio  Infallibility, and the ability to
>>>   learn from their mistakes.
>>> (Adapted from Stephen Pinker)
>>> 
> 

Re: minimum IPv6 announcement size

[Scott Weeks]

--- o...@delong.com wrote:
From: Owen DeLong 
 
we will have plenty of address space to number the internet 
for many many years. 
--


You can't know the future and what addressing requirements
it'll bring:

"I have to say that in 1981, making those decisions, I felt 
like I was providing enough freedom for 10 years. That is, 
a move from 64k to 640k felt like something that would last 
a great deal of time. Well, it didn't - it took about only 
6 years before people started to see that as a real problem."


scott

Re: minimum IPv6 announcement size

[Owen DeLong]

The original plan was to go from 32 to 64 bits total. The additional 64 bits 
were added purely for the sake of EUI-64 based addressing, and really, 64 bits 
of network number is way more than enough. 

The /64 a are not what justify the larger blocks. That's IPv4 think. 

In IPv6, it is far better to think about the number of sinners without regard 
to counting hosts. The /48 per site is justified because it is almost 
inconceivable that a single site would ever need more than 65536 subnets. 

The /32 is a minimum reasonable allocation for an ISP to balance the tradeoff 
between routing table entries and consumption. 

Most estimates say that the vast majority of significant providers will end up 
using a /28 with some outliers on both sides. Many smaller providers will end 
up with /32 and a few medium to large ones will get /24 or even /20. A minute 
(probably less than 20 world wide) number might get /16s. 

Absent some novel (and IMHO I'll-advised) approach to semantic overloading, we 
will have plenty of address space to number the internet for many many years. 

Owen


> On Oct 1, 2013, at 12:11, Ryan McIntosh  wrote:
> 
> I'd love to be able to turn the microwave and oven on with my phone..
> maybe ten years from now lol..
> 
> In all seriousness though (and after skimming some of the other
> responses), I absolutely understand the ideals and needs amongst
> conserving memory on our routers for the sake of the future of bgp and
> internal routing. The problem I described has nothing to do with that
> however, I was mearly pointing out the fact that the basis of the
> larger allocations are based upon the fact we're handing over /64's to
> each vlan/point to point/lan/etc that we're turning up. In practice, I
> understand, a /64 means that 64 bits can handle a unique ip for every
> host without having to worry about numbering them, but how many hosts
> do we truly think will be sitting on one network? Surely not a /64's
> worth, that alone would cause havoc on a neighbor table's maximum
> memory limit. Maybe I'm missing the connection here, but I still don't
> see how a /64 is justified for each individual user/host/server/etc
> sitting on the edge of the internet that's getting ip's from an
> upstream provider (not arin/ripe/etc).
> 
> It's those smaller blocks that justify handing over larger ones, which
> I do understand there's plenty of, but how long are we going to patch
> the same problem and not try to fix it right?
> 
> Ryan
> 
>> On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon  wrote:
>>> On 9/27/2013 1:10 AM, Ryan McIntosh wrote:
>>> 
>>> I don't respond to many of these threads but I have to say I've
>>> contested this one too only to have to beaten into my head that a /64
>>> is "appropriate".. it still hasn't stuck, but unfortunately rfc's for
>>> other protocols depend on the blocks to now be a /64..
>>> 
>>> It's a waste, even if we're "planning for the future", no one house
>>> needs a /64 sitting on their lan.. or at least none I can sensibly
>>> think of o_O.
>> 
>> 
>> 
>> Are you accounting for connections to your refrigerator, water heater,
>> razor, vibrator, and on down to list so the gubermint can tell they when you
>> can use power for them?
>> 
>> --
>> Requiescas in pace o email   Two identifying characteristics
>>of System Administrators:
>> Ex turpi causa non oritur actio  Infallibility, and the ability to
>>learn from their mistakes.
>>  (Adapted from Stephen Pinker)
>> 

Re: minimum IPv6 announcement size

[bmanning]

back in the good o'l days when we would hand out 24 bits for the 
number of hosts in a network.   It was too many bits then and is 
too many bits now  a /64 is just overkill.

/bill



On Tue, Oct 01, 2013 at 03:11:39PM -0400, Ryan McIntosh wrote:
> I'd love to be able to turn the microwave and oven on with my phone..
> maybe ten years from now lol..
> 
> In all seriousness though (and after skimming some of the other
> responses), I absolutely understand the ideals and needs amongst
> conserving memory on our routers for the sake of the future of bgp and
> internal routing. The problem I described has nothing to do with that
> however, I was mearly pointing out the fact that the basis of the
> larger allocations are based upon the fact we're handing over /64's to
> each vlan/point to point/lan/etc that we're turning up. In practice, I
> understand, a /64 means that 64 bits can handle a unique ip for every
> host without having to worry about numbering them, but how many hosts
> do we truly think will be sitting on one network? Surely not a /64's
> worth, that alone would cause havoc on a neighbor table's maximum
> memory limit. Maybe I'm missing the connection here, but I still don't
> see how a /64 is justified for each individual user/host/server/etc
> sitting on the edge of the internet that's getting ip's from an
> upstream provider (not arin/ripe/etc).
> 
> It's those smaller blocks that justify handing over larger ones, which
> I do understand there's plenty of, but how long are we going to patch
> the same problem and not try to fix it right?
> 
> Ryan
> 
> On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon  wrote:
> > On 9/27/2013 1:10 AM, Ryan McIntosh wrote:
> >>
> >> I don't respond to many of these threads but I have to say I've
> >> contested this one too only to have to beaten into my head that a /64
> >> is "appropriate".. it still hasn't stuck, but unfortunately rfc's for
> >> other protocols depend on the blocks to now be a /64..
> >>
> >> It's a waste, even if we're "planning for the future", no one house
> >> needs a /64 sitting on their lan.. or at least none I can sensibly
> >> think of o_O.
> >
> >
> >
> > Are you accounting for connections to your refrigerator, water heater,
> > razor, vibrator, and on down to list so the gubermint can tell they when you
> > can use power for them?
> >
> > --
> > Requiescas in pace o email   Two identifying characteristics
> > of System Administrators:
> > Ex turpi causa non oritur actio  Infallibility, and the ability to
> > learn from their mistakes.
> >   (Adapted from Stephen Pinker)
> >

Re: minimum IPv6 announcement size

[Ryan McIntosh]

I'd love to be able to turn the microwave and oven on with my phone..
maybe ten years from now lol..

In all seriousness though (and after skimming some of the other
responses), I absolutely understand the ideals and needs amongst
conserving memory on our routers for the sake of the future of bgp and
internal routing. The problem I described has nothing to do with that
however, I was mearly pointing out the fact that the basis of the
larger allocations are based upon the fact we're handing over /64's to
each vlan/point to point/lan/etc that we're turning up. In practice, I
understand, a /64 means that 64 bits can handle a unique ip for every
host without having to worry about numbering them, but how many hosts
do we truly think will be sitting on one network? Surely not a /64's
worth, that alone would cause havoc on a neighbor table's maximum
memory limit. Maybe I'm missing the connection here, but I still don't
see how a /64 is justified for each individual user/host/server/etc
sitting on the edge of the internet that's getting ip's from an
upstream provider (not arin/ripe/etc).

It's those smaller blocks that justify handing over larger ones, which
I do understand there's plenty of, but how long are we going to patch
the same problem and not try to fix it right?

Ryan

On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon  wrote:
> On 9/27/2013 1:10 AM, Ryan McIntosh wrote:
>>
>> I don't respond to many of these threads but I have to say I've
>> contested this one too only to have to beaten into my head that a /64
>> is "appropriate".. it still hasn't stuck, but unfortunately rfc's for
>> other protocols depend on the blocks to now be a /64..
>>
>> It's a waste, even if we're "planning for the future", no one house
>> needs a /64 sitting on their lan.. or at least none I can sensibly
>> think of o_O.
>
>
>
> Are you accounting for connections to your refrigerator, water heater,
> razor, vibrator, and on down to list so the gubermint can tell they when you
> can use power for them?
>
> --
> Requiescas in pace o email   Two identifying characteristics
> of System Administrators:
> Ex turpi causa non oritur actio  Infallibility, and the ability to
> learn from their mistakes.
>   (Adapted from Stephen Pinker)
>

RE: minimum IPv6 announcement size

[Leo Vegoda]

William Herrin wrote:

[...]

> And yet we're allocating /19's 

If the stats published at
http://www.nro.net/pub/stats/nro/delegated-extended are to be believed
then the only two /19s were allocated in 2005 when the HD-ratio value in
the policy was lower. Looking at all the RIRs together another nine /20s
have been allocated and seven /21s.  There are just 51 allocations of
/22 of shorter prefixes.

Given that almost 17,000 IPv6 blocks have been issued, those 51 blocks
are really just a fraction of a percent and seem to represent the
exception and not the norm.

Leo


smime.p7s
Description: S/MIME cryptographic signature

Re: minimum IPv6 announcement size

[Owen DeLong]

On Oct 1, 2013, at 11:11 , William Herrin  wrote:

> On Tue, Oct 1, 2013 at 12:04 PM, Rob Seastrom  wrote:
>> William Herrin  writes:
>>> IPv4 jumped from 8 bits to 32 bits. Which when you think about it is
>>> the same ratio as jumping from 32 bits to 128 bits.
>> 
>> Jumping from 8 bits to 32 bits (1:16mm) is the same ratio as would be
>> jumping from 32 bits to 48 bits (also, 1:16mm).
> 
> Hi Rob,
> 
> And yet we're allocating /19's where previously we allocated space
> that added up to /7's and /48's where previously we allocated /24's.
> My math may be flawed but the pattern is there all the same.

Not exactly...

We're allocating /16s and/or /20s where previously we allocated space
that added up to /7's, but, the holders of the /7s were coming back for more
and more on a regular basis. I don't believe anyone holding a /16 or /20
of IPv6 has come back for another allocation at all and I would be surprised
if such an organization were to do so in the next 5 years or so.

We're allocating /48s where previously we allocated roughly /16-/24.

Any effort at making direct comparisons between IPv4 and IPv6 number utilization
is flawed because there is, by definition, nothing approximating a simple ratio
between the two.

> 
> 
>> Going from 32 bits to 128 bits is 1:79228162514264337593543950336 which
>> is not even remotely the same ratio.
> 
> You know enough about IPv6 to realize that we didn't go from 32 bits
> to 128 bits, we went from either 24ish bits to 48 or 28ish bits to 64,
> depending on how you look at it. While IPv6 is capable of working the
> same as IPv4, that's not how we're actually using it.

Both of those estimates are also flawed.

> More, growth has not been linear since IPv4's advent and is not (by
> anyone reasonable) projected to be linear or sub-linear in IPv6.
> Computing a linear ratio as if that were representative of the
> expected lifetime of the new address space does not paint an honest
> picture.

Nor does any effort to apply a simple ratio between IPv4 and IPv6.

There are sufficient differences in the allocation algorithms and counting
methods between the two that an apples to apples comparison of allocation
policies simply isn't possible.

Owen

Re: minimum IPv6 announcement size

[William Herrin]

On Tue, Oct 1, 2013 at 12:04 PM, Rob Seastrom  wrote:
> William Herrin  writes:
>> IPv4 jumped from 8 bits to 32 bits. Which when you think about it is
>> the same ratio as jumping from 32 bits to 128 bits.
>
> Jumping from 8 bits to 32 bits (1:16mm) is the same ratio as would be
> jumping from 32 bits to 48 bits (also, 1:16mm).

Hi Rob,

And yet we're allocating /19's where previously we allocated space
that added up to /7's and /48's where previously we allocated /24's.
My math may be flawed but the pattern is there all the same.


> Going from 32 bits to 128 bits is 1:79228162514264337593543950336 which
> is not even remotely the same ratio.

You know enough about IPv6 to realize that we didn't go from 32 bits
to 128 bits, we went from either 24ish bits to 48 or 28ish bits to 64,
depending on how you look at it. While IPv6 is capable of working the
same as IPv4, that's not how we're actually using it.

More, growth has not been linear since IPv4's advent and is not (by
anyone reasonable) projected to be linear or sub-linear in IPv6.
Computing a linear ratio as if that were representative of the
expected lifetime of the new address space does not paint an honest
picture.


> Sorry for the late reply, Bill, but you were snoozing when they taught
> logarithms in high school weren't you?

While I did in fact snooze my way through a significant part of
school, I was wide awake for the word problems where we were asked to
build an appropriate equation. You remember: the trick questions where
a couple of irrelevant bits of data were thrown in and critical
factors were implied without being stated. And despite the
distractions you were asked to grasp the essential problem from the
English language description. Those were fun.

Regards,
Bill Herrin


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

Re: minimum IPv6 announcement size

[Rob Seastrom]

William Herrin  writes:

> IPv4 jumped from 8 bits to 32 bits. Which when you think about it is
> the same ratio as jumping from 32 bits to 128 bits.

Sorry for the late reply, Bill, but you were snoozing when they taught
logarithms in high school weren't you?

Jumping from 8 bits to 32 bits (1:16mm) is the same ratio as would be
jumping from 32 bits to 48 bits (also, 1:16mm).

Going from 32 bits to 128 bits is 1:79228162514264337593543950336 which
is not even remotely the same ratio.

-r

Re: minimum IPv6 announcement size

[Larry Sheldon]

On 9/27/2013 1:10 AM, Ryan McIntosh wrote:

I don't respond to many of these threads but I have to say I've
contested this one too only to have to beaten into my head that a /64
is "appropriate".. it still hasn't stuck, but unfortunately rfc's for
other protocols depend on the blocks to now be a /64..

It's a waste, even if we're "planning for the future", no one house
needs a /64 sitting on their lan.. or at least none I can sensibly
think of o_O.



Are you accounting for connections to your refrigerator, water heater, 
razor, vibrator, and on down to list so the gubermint can tell they when 
you can use power for them?


--
Requiescas in pace o email   Two identifying characteristics
of System Administrators:
Ex turpi causa non oritur actio  Infallibility, and the ability to
learn from their mistakes.
  (Adapted from Stephen Pinker)

Re: minimum IPv6 announcement size

[Eric A Louie]

"...and leave my BN alone, please - go play with the AGS"




>
> From: "valdis.kletni...@vt.edu" 
>To: Ben  
>Cc: nanog@nanog.org 
>Sent: Monday, September 30, 2013 7:40 AM
>Subject: Re: minimum IPv6 announcement size
> 
>
>On Mon, 30 Sep 2013 13:05:01 +0100, Ben said:
>
>> Most people here were probably not of working age in 1985 ;-)
>
>"All you kids, get off my Proteon!" :)
>
>
>

Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size)

[John Curran]

On Sep 29, 2013, at 12:49 AM, Blake Dunlap  wrote:
> Yes, I was lazy in most of the adaptation, but I think it serves a
> good starting point for market based suggestions to the route slot
> problem.
> 
> Your post advocates a
> 
> (X) technical ( ) legislative (X) market-based ( ) vigilante
> 
> approach to fighting spam^H^H^H^H route deaggregation. Your idea will
> not work. Here is why it won't work. 
> ...

There's actually no new technology involved, and you're overlooking the fact 
that there already _is_ market operating when it comes to routing table slots - 
try asking your ISP if they'll accept and propagate more specifics and your
answer is going based on imputed worth to them as a customer...  you just 
have no visibility into their assessment of your value, nor any way to make
the judgement yourself and pay accordingly.

FYI,
/John

Re: minimum IPv6 announcement size

[bmanning]

On Mon, Sep 30, 2013 at 11:27:26AM -0400, William Herrin wrote:
> On Mon, Sep 30, 2013 at 10:46 AM, TJ  wrote:
> > On Mon, Sep 30, 2013 at 9:32 AM, William Herrin  wrote:
> >>  IPv4 jumped from 8 bits to
> >>  32 bits. Which when you think about it is the same ratio as jumping
> >> from 32 bits to 128 bits.
> >
> >  Only insofar as the jump from 1 to 1000 is the same as the jump from 1000
> > is to 100 ... :)
> 
> If we're on an exponential growth curve, it's the same ratio. Are we?
> 
> Regards,
> Bill Herrin

sure...   and I appreciate you advertizing all that unused "dark" space 
for me
to hide my spam return addresses in.  grateful you have enough 
bandwidth to absorb
the incoming DDoS packets for non-existent hosts.

profound thanks.

/bill

Re: minimum IPv6 announcement size

[William Herrin]

On Mon, Sep 30, 2013 at 10:46 AM, TJ  wrote:
> On Mon, Sep 30, 2013 at 9:32 AM, William Herrin  wrote:
>>  IPv4 jumped from 8 bits to
>>  32 bits. Which when you think about it is the same ratio as jumping
>> from 32 bits to 128 bits.
>
>  Only insofar as the jump from 1 to 1000 is the same as the jump from 1000
> is to 100 ... :)

If we're on an exponential growth curve, it's the same ratio. Are we?

Regards,
Bill Herrin

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

Re: minimum IPv6 announcement size

[TJ]

On Mon, Sep 30, 2013 at 9:32 AM, William Herrin  wrote:

> 
>
 IPv4 jumped from 8 bits to
>  32 bits. Which when you think about it is the same ratio as jumping
> from 32 bits to 128 bits.
>

 Only insofar as the jump from 1 to 1000 is the same as the jump from 1000
is to 100 ... :)


/TJ

RE: minimum IPv6 announcement size

[Lustgraaf, Paul J [ITNET]]

Stop, you're giving me nightmares!

Paul Lustgraafgr...@iastate.edu
"Change is inevitable.  Progress is not."
Network Engineer, Iowa State University IT Services 
 515-294-0324

-Original Message-
From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] 
Sent: Monday, September 30, 2013 9:41 AM
To: Ben
Cc: nanog@nanog.org
Subject: Re: minimum IPv6 announcement size

On Mon, 30 Sep 2013 13:05:01 +0100, Ben said:

> Most people here were probably not of working age in 1985 ;-)

"All you kids, get off my Proteon!" :)

Re: minimum IPv6 announcement size

[Valdis . Kletnieks]

On Mon, 30 Sep 2013 13:05:01 +0100, Ben said:

> Most people here were probably not of working age in 1985 ;-)

"All you kids, get off my Proteon!" :)


pgp6RpOt1bBpB.pgp
Description: PGP signature

Re: minimum IPv6 announcement size

[William Herrin]

On Thu, Sep 26, 2013 at 4:41 PM, Randy Bush  wrote:
>>> sounds just like folks in 1985, talking about IPv4...
>> The foundation of that, though, was ignorance of address space
>> exhaustion.
>
> no.  ipv4 was the second time, not the first

Hi Randy,

The first time they had 256 addresses (8 bits) right? That's where the
original /8 assignments in IPv4 came from, the folks listed back in
RFC 758 who had an IP address before IPv4. IPv4 jumped from 8 bits to
32 bits. Which when you think about it is the same ratio as jumping
from 32 bits to 128 bits.

Regards,
Bill Herrin


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

Fwd: minimum IPv6 announcement size

[Alexander Neilson]

*Beer* - sorry to take this further off topic.

Regards
Alexander

Alexander Neilson
Neilson Productions Limited

alexan...@neilson.net.nz
021 329 681
022 456 2326

Begin forwarded message:

> From: Ben 
> Subject: Re: minimum IPv6 announcement size
> Date: 1 October 2013 1:05:01 AM NZDT
> To: nanog@nanog.org
> 
> On 26/09/2013 09:52, bmann...@vacation.karoshi.com wrote:
>>  sounds just like folks in 1985, talking about IPv4...
>> 
> 
> Most people here were probably not of working age in 1985 ;-)
> 
> 

Working age?? some of us weren't even born yet.

smime.p7s
Description: S/MIME cryptographic signature

Re: minimum IPv6 announcement size

[Ben]

On 26/09/2013 09:52, bmann...@vacation.karoshi.com wrote:

  sounds just like folks in 1985, talking about IPv4...



Most people here were probably not of working age in 1985 ;-)

Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size)

[Blake Dunlap]

Yes, I was lazy in most of the adaptation, but I think it serves a
good starting point for market based suggestions to the route slot
problem.


Your post advocates a

(X) technical ( ) legislative (X) market-based ( ) vigilante

approach to fighting spam^H^H^H^H route deaggregation. Your idea will
not work. Here is why it won't work. (One or more of the following may
apply to your particular idea, and it may have other flaws which used
to vary from state to state before a bad federal law was passed.)

(X) No one will be able to find the guy or collect the money
(X) End Users will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
(X) Requires too much cooperation from spammers
( ) Requires immediate total cooperation from everybody at once
( ) Anyone could anonymously destroy anyone else's career or business

Specifically, your plan fails to account for

( ) Laws expressly prohibiting it
(X) Lack of centrally controlling authority for routing
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
(X) Jurisdictional problems
(X) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP^H^H^H^H BGP
( ) Susceptibility of protocols other than SMTP^H^H^H^H BGP to attack
(X) Eternal arms race involved in all filtering approaches
(X) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
(X) Dishonesty on the part of spammers themselves
(X) Bandwidth costs that are unaffected by client filtering
( ) Outlook

and the following philosophical objections may also apply:

(X) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
(X) SMTP headers^H^H^H^H^H^H^H Routing should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
(X) Countermeasures must work if phased in gradually
( ) Sending email should be free
(X) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough

Furthermore, this is what I think about you:

( ) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your
house down!



-Blake



On Sat, Sep 28, 2013 at 6:10 PM, Steven Bellovin wrote:

>
> On Sep 26, 2013, at 11:07 AM, John Curran  wrote:
>
> > On Sep 26, 2013, at 4:52 AM, bmann...@vacation.karoshi.com wrote:
> >
> >> sounds just like folks in 1985, talking about IPv4...
> >
> > If there were ever were a need for an market/settlement model, it is
> with respect
> > to routing table slots.
>
> https://www.cs.columbia.edu/~smb/papers/piara/index.html, from 1997.
>
> We even had a BoF at an IETF, but you can imagine the reaction it got.
>
> --Steve Bellovin, https://www.cs.columbia.edu/~smb
>
>
>
>
>
>
>
>

Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size)

[Steven Bellovin]

On Sep 26, 2013, at 11:07 AM, John Curran  wrote:

> On Sep 26, 2013, at 4:52 AM, bmann...@vacation.karoshi.com wrote:
> 
>> sounds just like folks in 1985, talking about IPv4...
> 
> If there were ever were a need for an market/settlement model, it is with 
> respect 
> to routing table slots.

https://www.cs.columbia.edu/~smb/papers/piara/index.html, from 1997.

We even had a BoF at an IETF, but you can imagine the reaction it got.

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

Re: minimum IPv6 announcement size

[Matt Palmer]

On Fri, Sep 27, 2013 at 02:10:47AM -0400, Ryan McIntosh wrote:
> I don't respond to many of these threads but I have to say I've
> contested this one too only to have to beaten into my head that a /64
> is "appropriate".. it still hasn't stuck, but unfortunately rfc's for
> other protocols depend on the blocks to now be a /64..

I became a "convert" to the school of thought that hands out a /48 to every
end user when I realised that the current, *most* profligate addressing
scheme anyone's recommending involves essentially giving out an IPv6 /48 to
anyone who's currently getting an IPv4 /32 (eyeball SP end-users, and
dedicated server / VPS customers).  Even with this scheme, we have an
address space over eight *thousand* times greater than what we have now[1]. 
If I am the current IPv4 Internet, then we can have more IPv6 Internets than
there are people in the town I live in.

Once that sunk in, I realised that, practically speaking, we're solid.  Yes,
there have been a few "big" blocks like /20s handed out, but they're few and
far between.  I work for a comparatively *tiny* hosting company, and we've
got 3 IPv4 /20s, and yet the single IPv6 /32 we've got should more than do
us for a *very* long time to come[2].

I'm now firmly in the camp that the resource to be worrying about is routing
table slots, not address space exhaustion.

> It's a waste, even if we're "planning for the future", no one house
> needs a /64 sitting on their lan.. or at least none I can sensibly
> think of o_O.

I prefer to think of it as simply "enough address space I don't have to
worry about manual assignment", rather than "I'm 'wasting'
18446744073709551612 addresses".  Thinking of IPv6 as being a 48-bit or
64-bit address space that also has the added bonus of never having to worry
about host addressing makes things a lot more palatable.

- Matt

[1] And that's assuming that we only use 2000::/3 for this go around, which
is one of six /3 blocks that we have to play with.  If we completely fuck
this up, we've effectively got IPv's 7 through 11 to try different ideas
without having to change addressing formats.

[2] To be fair, we're using an IPv6 addressing scheme that involves a lot
more compaction than "/48s for everyone!", but even if we were handing out
/48s for every machine in our facilities (which we wouldn't need to do,
because plenty of customers have multiple machines, and thus would get a
single /48 for all their machines), we'd still not be running out any time
soon -- we've got ~65k IPv6 /48s, compared to ~12k IPv4 /32s, so yeah...
  

-- 
Generally the folk who love the environment in vague, frilly ways are at
odds with folk who love the environment next to the mashed potatoes.
-- Anthony de Boer, in a place that does not exist

Re: minimum IPv6 announcement size

[Owen DeLong]

On Sep 26, 2013, at 13:18 , Darren Pilgrim  wrote:

> On 9/26/2013 1:07 PM, joel jaeggli wrote:
>> 
>> On Sep 26, 2013, at 12:29 PM, Darren Pilgrim 
>> wrote:
>> 
>>> On 9/26/2013 1:52 AM, bmann...@vacation.karoshi.com wrote:
 sounds just like folks in 1985, talking about IPv4...
>>> 
>>> The foundation of that, though, was ignorance of address space
>>> exhaustion.  IPv4's address space was too small for such large
>>> thinking.
>> 
>> The first dicussion I could find about ipv4 runnout  in email
>> archives is circa 1983
>> 
>>> IPv6 is far beyond enough to use such allocation policies.
>> 
>> There are certain tendencies towards profligacy that might
>> prematurely influence the question of ipv6 exhaustion and we should
>> be on guard against them… allocating enough /48s as part of direct
>> assignments  is probably not one of them.
> 
> That's just it, I really don't think we actually have an exhaustion risk with 
> IPv6.  IPv6 is massive beyond massive.  Let me explain.
> 

There are some (bizarre) ideas for using IPv6 in really stupid ways that would 
profligately waste /12 and larger blocks of IPv6.

There are no more /12s in IPv6 than there are /12s in IPv4... Exactly 4096 of 
them.

If we waste ~4000 /12s, we might be in trouble.

> Current science says Earth can support ten billion humans.  If we let the 
> humans proliferate to three times the theoretical upper limit for Earth's 
> population, a /64 for each human would be at about a /35's worth of /64's.  
> If we're generous with Earth's carrying capacity, a /36.

But a /64 is nowhere near enough. You should, instead, be presuming the 
following:

a /48 for each human's tablet
a /48 for each human's phone
a /48 for each human household (~1 /48 per 3 humans)
a /48 for each human business site (hard to develop a good ratio here, 
but I'd guess something like 20 wouldn't be unreasonable,
so that's another /48 for every 20 humans).

Then, add to that network infrastructure, servers, etc.

Additionally, we expect IPv6 to last long enough that you may not be able to 
depend on Earth as a bounding limitation, nor can you count on the limits of 
current science as a population limit.

> If we handed out /48's instead so each human could give a /64 to each of 
> their devices, it would all fit in a single /52.  Those /48's would number 
> existance at a rate of one /64 per human, one /64 per device, and a 65535:1 
> device:human ratio.  That means we could allocate 4000::/3 just for Earth 
> humans and devices and never need another block for that purpose.

You can't fit multiple /48s in a single /52, so that doesn't work.

There are only 4096 /64s in a /52.

> That's assuming a very high utilisation ratio, of course, but really no worse 
> than IPv4 is currently.  The problem isn't allocation density, but router 
> hardware.  We need room for route aggregation and other means of 
> compartmentalisation.  Is a 10% utilisation rate sparse enough?  At 10% 
> utilisation, keeping the allocations to just 4000::/3, we'd need less than a 
> single /60 for all those /48's.  If 10% isn't enough, we can go quite a bit 
> farther:

This just doesn't work mathematically. You can't put multiple /48s into a 
/60... A /48 consists of 4096 /60s.

> 
> - 1% utilisation would fit all those /48's into a /62.
> - A full /64 of those /48's would be 0.2% utilisation.
> - 0.1%? We'd have to steal a bit and hand out /47's instead.
> - /47 is ugly.  At /52, we'd get .024% (one per 4096).

It's really hard to follow what you are trying to claim given that you seem to 
have the bit math all backwards.

> 
> That's while maintaining a practice of one /64 per human or device with 65535 
> devices per human.  Introduce one /64 per subnet and sub-ppm utilisation is 
> possible.  That would be giving a site a /44 and them only ever using the 
> ::/64 of it.

I'm not sure what this is supposed to mean.

> 
> Even with sloppy, sparse allocation policies and allowing limitless human and 
> device population growth, we very likely can not exhaust IPv6.

In terms of current allocation policies for humans, devices, and 
infrastructure, that is true.

However, at one point, many ISPs wanted a /16 in order to be able to give each 
IPv4 subscriber a /48 based on their current IPv4 unicast address(es) for 6rd. 
There are only 65,536 /16s in IPv6. (Which is one of the many reasons this 
proposal did not make it into policy without
moving some bits to the right). Fortunately, few operators actually implemented 
6rd in such a profligate way anyway, so little harm was done.

There are other proposals that have been made. One proposal was to map VIN 
numbers onto /48 prefixes and give each car manufactured a /48 that would be 
permanently allocated to the vehicle. Since these network numbers would not be 
reliably reclaimable at vehicle end-of-life, this
usage pattern could become problematic over time.

There have been others as well.

Re: minimum IPv6 announcement size

[William Herrin]

On Fri, Sep 27, 2013 at 2:11 PM, William Herrin  wrote:
> On Fri, Sep 27, 2013 at 1:04 PM, Randy Carpenter  wrote:
>> Therefore, I don't see any reason to artificially inflate
>> the routing table by conserving, and then making
>> orgs come back for additional allocations.
>
> I'm not convinced of that. Suppose the plan was: you start with a /56.
> When you need more you get a /48. Next is a /40. Next a /32. Next a
> /28. You can hold exactly one of each size, never more. And the RIRs
> tell us all which address banks each size comes from.
>
> In such a scenario, the RIR doesn't have to reserve a /28 for
> expansion every time the allocate a /32. 'Cause, you know, that's what
> they've been doing. And you can easily program your router to discard
> the TE routes you don't wish to carry since you know what the
> allocation size was. That means you only have to carry at most 5
> routes for any given organization. You'd want to allow some TE for the
> sake of efficient routing, but you get to choose how much.
>
> As things stand now, you're going to allow those guys with the /19s
> and /22s to do traffic engineering all the way down to /48. You don't
> have a practical way to say "no."


Point is: there are a number of address management practices which
significantly impact the routing table size. The ones that jump to
mind are:


1. Receiving discontiguous blocks from the registry on subsequent
requests. If the blocks can't aggregate then they consume two routes
even if they don't need to.

Registry-level mitigations: allocate in excess of immediate need.
Reserve additional space to allow subsequent allocations by changing
the netmask on the same contiguous block.


2. Registry assignments to single-homed users. Registry assignments
can't aggregate, even if their use shares fate with another AS's
routes.

Registry-level mitigations:minimize allocations to organizations which
are not multihomed.


3. Traffic engineering. Fine tuning how data flows by cutting up an
address block into smaller announced routes.

Registry-level mitigations: Standardize allocation sizes and allocate
from blocks reserved for that particular allocation size. Do not
change a netmask in order to reduce or enlarge an allocation. This
allows the recipients of TE advertisements to identify them and, if
desired, filter them.


4. ISP assignments to multihomed users. In other networks, assignments
to end users from your space are likely to be indistinguishable from
traffic engineering routes. TE filtering is impossible if some of the
announcements are multihomed customers whose fate is not shared with
the ISP to whom the space was allocated.

Registry-level mitigations: Direct assignment to all multihomed
networks. Discourage ISPs from assigning subnets to multihomed
customers.


Note the contradictory mitigations. Standardized block sizes increases
the number of discontiguous blocks. Netmask changes defeat
standardized block sizes. So, it's a balancing act. Does more route
bloat come from filterable TE? Or from discontiguous allocations? The
customer lock-in from being the organization who assigns the
customer's IP addresses turns around and bites you in the form of
unfilterable traffic engineering routes.

Regards,
Bill Herrin


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

Re: minimum IPv6 announcement size

[Randy Carpenter]

> In ipv4 there are 482319 routes and 45235 ASNs in the DFZ this week, of that
> 18619 ~40% announce only one prefix. given the distribution of prefix counts
> across ASNs it's quite reasonable  to conclude that the consumption of
> routing table slots is not primarly a property of the number of participants
> but rather in the hands of a smaller number of large participants many of
> whom are in this room.

Which, compounds the idea that routing slots are going to be more of an issue 
than allocation size.

-Randy

Re: minimum IPv6 announcement size

[William Herrin]

On Fri, Sep 27, 2013 at 1:04 PM, Randy Carpenter  wrote:
>
>> There is no bit length which allocations of /20's and larger won't
>> quickly exhaust. It's not about the number of bits, it's about how we
>> choose to use them.
>
> True, but how many orgs do we expect to fall into that category? If the 
> majority are getting /32, and only a handful are getting /24 or larger, can 
> we assume that the average is going to be ~/28 ? If that is so, then out of 
> the current /3, we can support over 30,000,000 entities. Actually, I would 
> think the average is much closer to /32, since there are several orders of 
> magnitude more orgs with /32 than /20 or smaller. Assuming /32 would be 500 
> million out of the /3. So somewhere between 30 and 500 million orgs.
>
> How many ISPs do we expect to be able to support? Also, consider that there 
> are 7 more /3s that could be allocated in the future.

Hi Randy,

If that's how we choose to use IPv6 then runout should be a long way
away. That's a big "if". And choosing to stay that course is a form of
conservation.


> Therefore, I don't see any reason to artificially inflate
> the routing table by conserving, and then making
> orgs come back for additional allocations.

I'm not convinced of that. Suppose the plan was: you start with a /56.
When you need more you get a /48. Next is a /40. Next a /32. Next a
/28. You can hold exactly one of each size, never more. And the RIRs
tell us all which address banks each size comes from.

In such a scenario, the RIR doesn't have to reserve a /28 for
expansion every time the allocate a /32. 'Cause, you know, that's what
they've been doing. And you can easily program your router to discard
the TE routes you don't wish to carry since you know what the
allocation size was. That means you only have to carry at most 5
routes for any given organization. You'd want to allow some TE for the
sake of efficient routing, but you get to choose how much.

As things stand now, you're going to allow those guys with the /19s
and /22s to do traffic engineering all the way down to /48. You don't
have a practical way to say "no."

Food for thought.

Regards,
Bill Herrin



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

Re: minimum IPv6 announcement size

[joel jaeggli]

On Sep 27, 2013, at 10:04 AM, Randy Carpenter  wrote:

> 
>> There is no bit length which allocations of /20's and larger won't
>> quickly exhaust. It's not about the number of bits, it's about how we
>> choose to use them.
>> 
>> Regards,
>> Bill Herrin
> 
> True, but how many orgs do we expect to fall into that category? If the 
> majority are getting /32, and only a handful are getting /24 or larger, can 
> we assume that the average is going to be ~/28 ? If that is so, then out of 
> the current /3, we can support over 30,000,000 entities. Actually, I would 
> think the average is much closer to /32, since there are several orders of 
> magnitude more orgs with /32 than /20 or smaller. Assuming /32 would be 500 
> million out of the /3. So somewhere between 30 and 500 million orgs.
> 
> How many ISPs do we expect to be able to support? Also, consider that there 
> are 7 more /3s that could be allocated in the future.
> 
> As has been said, routing slots in the DFZ get to be problematic much sooner 
> than address runout. Most current routers support ~1 million IPv6 routes. I 
> think it would be reasonable to assume that that number could grow by an 
> order of magnitude or 2, but I don't thin we'll see a billion or more routes 
> in the lifetime of IPv6. Therefore, I don't see any reason to artificially 
> inflate the routing table by conserving, and then making orgs come back for 
> additional allocations.

In ipv4 there are 482319 routes and 45235 ASNs in the DFZ this week, of that 
18619 ~40% announce only one prefix. given the distribution of prefix counts 
across ASNs it's quite reasonable  to conclude that the consumption of routing 
table slots is not primarly a property of the number of participants but rather 
in the hands of a smaller number of large participants many of whom are in this 
room.

> -Randy
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: minimum IPv6 announcement size

[Randy Carpenter]

> There is no bit length which allocations of /20's and larger won't
> quickly exhaust. It's not about the number of bits, it's about how we
> choose to use them.
> 
> Regards,
> Bill Herrin

True, but how many orgs do we expect to fall into that category? If the 
majority are getting /32, and only a handful are getting /24 or larger, can we 
assume that the average is going to be ~/28 ? If that is so, then out of the 
current /3, we can support over 30,000,000 entities. Actually, I would think 
the average is much closer to /32, since there are several orders of magnitude 
more orgs with /32 than /20 or smaller. Assuming /32 would be 500 million out 
of the /3. So somewhere between 30 and 500 million orgs.

How many ISPs do we expect to be able to support? Also, consider that there are 
7 more /3s that could be allocated in the future.

As has been said, routing slots in the DFZ get to be problematic much sooner 
than address runout. Most current routers support ~1 million IPv6 routes. I 
think it would be reasonable to assume that that number could grow by an order 
of magnitude or 2, but I don't thin we'll see a billion or more routes in the 
lifetime of IPv6. Therefore, I don't see any reason to artificially inflate the 
routing table by conserving, and then making orgs come back for additional 
allocations.

-Randy

Re: minimum IPv6 announcement size

[William Herrin]

On Fri, Sep 27, 2013 at 10:40 AM, Brandon Ross  wrote:
> Okay, I'm just curious, what size do you (and other's of similar opinion)
> think the IPv6 space _should_ have been in order to allow us to not have to
> jump through conservation hoops ever again?  128 bits isn't enough, clearly,
> 256?  1k?  10k?

Hi Brandon,

There is no bit length which allocations of /20's and larger won't
quickly exhaust. It's not about the number of bits, it's about how we
choose to use them.

Regards,
Bill Herrin


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

Re: minimum IPv6 announcement size

[Joe Abley]

On 2013-09-27, at 10:40, Brandon Ross  wrote:

> On Fri, 27 Sep 2013, Ryan McIntosh wrote:
> 
>> It's a waste, even if we're "planning for the future", no one house
>> needs a /64 sitting on their lan.. or at least none I can sensibly
>> think of o_O.
> 
> Okay, I'm just curious, what size do you (and other's of similar opinion) 
> think the IPv6 space _should_ have been in order to allow us to not have to 
> jump through conservation hoops ever again?  128 bits isn't enough, clearly, 
> 256?  1k?  10k?

Given the design decision to use the bottom 64 bits to identify an individual 
host on a broadcast domain, the increase in address size isn't really 32 bits 
to 128 bits -- if your average v4 subnet size for a vlan is a /27, say, then 
it's more like an increase of 27 bits to 64 bits from the point of view of 
global assignment.

Alternatively, considering that it's normal to give a service provider at least 
a /32, whereas the equivalent assignment in v4 might have been something like a 
/19 (handwave, handwave), it's more like an increase of 13 bits to 32 bits.

Alternatively, considering that it's considered reasonable in some quarters to 
give an end-user a /48 so that they can break out different subnets inside 
their network whereas with IPv4 you'd give a customer a single address and 
expect them to use NAT, then it's more like an increase of 31 bits to 48 bits.

That's still a lower bound of 2^17 times as many available addresses, and 
having enough addresses to satisfy a network 131,072 times as big as the 
current v4 Internet does not seem like a horrible thing. But the oft-repeated 
mantra that "there are enough addresses to individually number every grain of 
sand on the world's beaches" doesn't describe reality very well.

The IPv6 addressing plan didn't wind up meeting our requirements very well. 
Film at 11.


Joe

Re: minimum IPv6 announcement size

[Brandon Ross]

On Fri, 27 Sep 2013, Ryan McIntosh wrote:


It's a waste, even if we're "planning for the future", no one house
needs a /64 sitting on their lan.. or at least none I can sensibly
think of o_O.


Okay, I'm just curious, what size do you (and other's of similar opinion) 
think the IPv6 space _should_ have been in order to allow us to not have 
to jump through conservation hoops ever again?  128 bits isn't enough, 
clearly, 256?  1k?  10k?


--
Brandon Ross  Yahoo & AIM:  BrandonNRoss
+1-404-635-6667ICQ:  2269442
Schedule a meeting:  https://doodle.com/brossSkype:  brandonross

Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size)

[William Herrin]

On Thu, Sep 26, 2013 at 5:05 PM, Scott Brim  wrote:
> Oh this sure will be fun. For a good time, see how GSMA handles connectivity
> with IPXs.

Hi Scott,

For those of us who aren't deeply engrossed in GSM mobile telecom,
would you offer a synopsis?

Thanks,
Bill Herrin



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

Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size)

[John Curran]

On Sep 26, 2013, at 1:43 PM, Randy Bush  wrote:

> y'know, it's funny.  there is a market in ipv4 space.  there is no
> market in routing table slots.  perhaps this is not conspiracy but
> rather the market is speaking.

That easily could be the case.  So how well is has the current model
been working out for IPv4?  It appears that only feedback mechanism
is the "The Cidr Report" , 
and last time this topic came up was almost exactly two years ago 
back at 375000 routes... is this success?  Perhaps more conference 
banners are needed?

> of course, we can use the idea of a market in routing table slots,
> rack space, or coffee to distract from the artificial problems in
> the only actual market, ipv4 address space.

No desire at all to distract from the discussions on that topic, and 
in fact, I'd encourage folks (including yourself) to pop on over to 
PPML and make suggestions for policy changes as desired.  That's not
an option available to me, and I was simply commenting on the fact 
that we're recreating the same IPv6 routing table feedback system 
which gave us our present "success" with the IPv4 routing table.

FYI,
/John

Re: minimum IPv6 announcement size

[Ryan McIntosh]

I don't respond to many of these threads but I have to say I've
contested this one too only to have to beaten into my head that a /64
is "appropriate".. it still hasn't stuck, but unfortunately rfc's for
other protocols depend on the blocks to now be a /64..

It's a waste, even if we're "planning for the future", no one house
needs a /64 sitting on their lan.. or at least none I can sensibly
think of o_O.

Ryan

On Fri, Sep 27, 2013 at 12:57 AM,   wrote:
>  Yup.  Seen/Heard all that.  Even tooted that horn for a while.
>  /64 is an artifical boundary - many/most IANA/RIR delegations are in the top 
> /32
>  which is functionally the same as handing out traditional /16s.  Some RIR 
> client
>  are "bigger" and demand more, so they get the v6 equvalent of /14s or 
> smaller.
>  Its the _exact_ same model as v4 in the previous decade.  With the entire 
> waste
>  in the bottom /64.
>
>  Its tilting at windmills, but most of the community has "drunk the koolaide"
>  on wasteful /v6 assignment.   What a horrific legacy to hand to our children
>  (and yes, it will hit that soon)
>
> /bill
>
>
> On Thu, Sep 26, 2013 at 01:18:50PM -0700, Darren Pilgrim wrote:
>> On 9/26/2013 1:07 PM, joel jaeggli wrote:
>> >
>> >On Sep 26, 2013, at 12:29 PM, Darren Pilgrim 
>> >wrote:
>> >
>> >>On 9/26/2013 1:52 AM, bmann...@vacation.karoshi.com wrote:
>> >>>sounds just like folks in 1985, talking about IPv4...
>> >>
>> >>The foundation of that, though, was ignorance of address space
>> >>exhaustion.  IPv4's address space was too small for such large
>> >>thinking.
>> >
>> >The first dicussion I could find about ipv4 runnout  in email
>> >archives is circa 1983
>> >
>> >>IPv6 is far beyond enough to use such allocation policies.
>> >
>> >There are certain tendencies towards profligacy that might
>> >prematurely influence the question of ipv6 exhaustion and we should
>> >be on guard against them  allocating enough /48s as part of direct
>> >assignments  is probably not one of them.
>>
>> That's just it, I really don't think we actually have an exhaustion risk
>> with IPv6.  IPv6 is massive beyond massive.  Let me explain.
>>
>> We have this idea of the "/64 boundary".  All those nifty automatic
>> addressing things rely on it.  We now have two generations of hardware
>> and software that would more or less break if we did away with it.  In
>> essence, we've translated an IPv4 /32 into an IPv6 /64.  Not great, but
>> still quite large.
>>
>> Current science says Earth can support ten billion humans.  If we let
>> the humans proliferate to three times the theoretical upper limit for
>> Earth's population, a /64 for each human would be at about a /35's worth
>> of /64's.  If we're generous with Earth's carrying capacity, a /36.
>>
>> If we handed out /48's instead so each human could give a /64 to each of
>> their devices, it would all fit in a single /52.  Those /48's would
>> number existance at a rate of one /64 per human, one /64 per device, and
>> a 65535:1 device:human ratio.  That means we could allocate 4000::/3
>> just for Earth humans and devices and never need another block for that
>> purpose.
>>
>> That's assuming a very high utilisation ratio, of course, but really no
>> worse than IPv4 is currently.  The problem isn't allocation density, but
>> router hardware.  We need room for route aggregation and other means of
>> compartmentalisation.  Is a 10% utilisation rate sparse enough?  At 10%
>> utilisation, keeping the allocations to just 4000::/3, we'd need less
>> than a single /60 for all those /48's.  If 10% isn't enough, we can go
>> quite a bit farther:
>>
>> - 1% utilisation would fit all those /48's into a /62.
>> - A full /64 of those /48's would be 0.2% utilisation.
>> - 0.1%? We'd have to steal a bit and hand out /47's instead.
>> - /47 is ugly.  At /52, we'd get .024% (one per 4096).
>>
>> That's while maintaining a practice of one /64 per human or device with
>> 65535 devices per human.  Introduce one /64 per subnet and sub-ppm
>> utilisation is possible.  That would be giving a site a /44 and them
>> only ever using the ::/64 of it.
>>
>> Even with sloppy, sparse allocation policies and allowing limitless
>> human and device population growth, we very likely can not exhaust IPv6.
>

Re: minimum IPv6 announcement size

[bmanning]

 Yup.  Seen/Heard all that.  Even tooted that horn for a while.
 /64 is an artifical boundary - many/most IANA/RIR delegations are in the top 
/32
 which is functionally the same as handing out traditional /16s.  Some RIR 
client
 are "bigger" and demand more, so they get the v6 equvalent of /14s or smaller.
 Its the _exact_ same model as v4 in the previous decade.  With the entire waste
 in the bottom /64.

 Its tilting at windmills, but most of the community has "drunk the koolaide"
 on wasteful /v6 assignment.   What a horrific legacy to hand to our children
 (and yes, it will hit that soon)

/bill


On Thu, Sep 26, 2013 at 01:18:50PM -0700, Darren Pilgrim wrote:
> On 9/26/2013 1:07 PM, joel jaeggli wrote:
> >
> >On Sep 26, 2013, at 12:29 PM, Darren Pilgrim 
> >wrote:
> >
> >>On 9/26/2013 1:52 AM, bmann...@vacation.karoshi.com wrote:
> >>>sounds just like folks in 1985, talking about IPv4...
> >>
> >>The foundation of that, though, was ignorance of address space
> >>exhaustion.  IPv4's address space was too small for such large
> >>thinking.
> >
> >The first dicussion I could find about ipv4 runnout  in email
> >archives is circa 1983
> >
> >>IPv6 is far beyond enough to use such allocation policies.
> >
> >There are certain tendencies towards profligacy that might
> >prematurely influence the question of ipv6 exhaustion and we should
> >be on guard against them allocating enough /48s as part of direct
> >assignments  is probably not one of them.
> 
> That's just it, I really don't think we actually have an exhaustion risk 
> with IPv6.  IPv6 is massive beyond massive.  Let me explain.
> 
> We have this idea of the "/64 boundary".  All those nifty automatic 
> addressing things rely on it.  We now have two generations of hardware 
> and software that would more or less break if we did away with it.  In 
> essence, we've translated an IPv4 /32 into an IPv6 /64.  Not great, but 
> still quite large.
> 
> Current science says Earth can support ten billion humans.  If we let 
> the humans proliferate to three times the theoretical upper limit for 
> Earth's population, a /64 for each human would be at about a /35's worth 
> of /64's.  If we're generous with Earth's carrying capacity, a /36.
> 
> If we handed out /48's instead so each human could give a /64 to each of 
> their devices, it would all fit in a single /52.  Those /48's would 
> number existance at a rate of one /64 per human, one /64 per device, and 
> a 65535:1 device:human ratio.  That means we could allocate 4000::/3 
> just for Earth humans and devices and never need another block for that 
> purpose.
> 
> That's assuming a very high utilisation ratio, of course, but really no 
> worse than IPv4 is currently.  The problem isn't allocation density, but 
> router hardware.  We need room for route aggregation and other means of 
> compartmentalisation.  Is a 10% utilisation rate sparse enough?  At 10% 
> utilisation, keeping the allocations to just 4000::/3, we'd need less 
> than a single /60 for all those /48's.  If 10% isn't enough, we can go 
> quite a bit farther:
> 
> - 1% utilisation would fit all those /48's into a /62.
> - A full /64 of those /48's would be 0.2% utilisation.
> - 0.1%? We'd have to steal a bit and hand out /47's instead.
> - /47 is ugly.  At /52, we'd get .024% (one per 4096).
> 
> That's while maintaining a practice of one /64 per human or device with 
> 65535 devices per human.  Introduce one /64 per subnet and sub-ppm 
> utilisation is possible.  That would be giving a site a /44 and them 
> only ever using the ::/64 of it.
> 
> Even with sloppy, sparse allocation policies and allowing limitless 
> human and device population growth, we very likely can not exhaust IPv6.

Re: minimum IPv6 announcement size

[bmanning]

On Thu, Sep 26, 2013 at 12:29:17PM -0700, Darren Pilgrim wrote:
> On 9/26/2013 1:52 AM, bmann...@vacation.karoshi.com wrote:
> >  sounds just like folks in 1985, talking about IPv4...
> 
> The foundation of that, though, was ignorance of address space 
> exhaustion.  IPv4's address space was too small for such large thinking. 
>  IPv6 is far beyond enough to use such allocation policies.

when concevied, IPv4 was unimaginably large ...  /8's were
handed out to networks with fewer than 10 devices.Hindsight
is 20/20.

"those who ignore teh past are doomed to repeat it" 

/bill

Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size)

[Scott Brim]

Oh this sure will be fun. For a good time, see how GSMA handles
connectivity with IPXs.
On Sep 26, 2013 1:28 PM, "William Herrin"  wrote:

> On Thu, Sep 26, 2013 at 11:07 AM, John Curran  wrote:
> > On Sep 26, 2013, at 4:52 AM, bmann...@vacation.karoshi.com wrote:
> >
> >> sounds just like folks in 1985, talking about IPv4...
> >
> > If there were ever were a need for an market/settlement model, it is
> with respect
> > to routing table slots.
> > That's not to say that establishing a framework for externalizing
> routing costs would
> > be easy; it's a complicated and twisted matter, and also fraught with
> various legal &
> > competitive aspects.
>
> Hi John,
>
> That's putting it mildly. Establishing such a framework would be an
> immense challenge. Here are some ideas I've heard:
>
>
> 1. The International Clearinghouse
>
> Every BGP participant files with a clearinghouse, specifying:
>
> a. How much they charge to carry 1 route
> b. Whether or not they are a leaf node
> c. Whether or not they are a transit-free network.
>
> Any network which is not transit free must implement a default route
> which leads to a big transit-free network in order to maintain full
> connectivity.
>
> The BGP participants then publish the exact routes they intend to
> announce to the clearinghouse and for each one select which networks
> they'll pay to carry the route. The route must still reach each
> network via BGP; payment just means that the network won't filter the
> route out.
>
> The clearinghouse then collects payments from everybody and makes
> payments to everybody, as well as providing each participant a list of
> the routes that are paid for. Sellers are expected to promptly
> incorporate new paid routes into their BGP filters.
>
> From my research a few years ago, a reasonable rate would be around 3
> to 4 cents per year per advertised route per BGP-carrying router in
> the organization. A couple billion dollars per year if the routing
> table maintained its current size.
>
>
> 2. The partial routing scenario
>
> Large service providers put bids in to the RIRs for the right to
> announce /8 covering routes for each /8 delegated to the RIR. Each /8
> matches exactly one service provider. Smaller BGP system participants
> make private arrangements with a small (20 to 30) set of networks
> (including their direct ISPs) to carry their advertised routes through
> a reasonably redundant number of pathways to (and including) the
> winning bidder for the /8 they inhabit. For the sake of performance,
> they may also pay additional large networks to shortcut the traffic
> towards them rather than let it dump at the /8 advertiser.
>
> For the folks you don't pay via the clearinghouse, many end-user
> systems and the majority of transit systems simply don't carry your
> route unless yours is among the handful of systems critically
> important to their customers. Instead, traffic to your network follows
> the /8 advertisement until it reaches a network which carries your
> specific route.
>
> With the routing costs suitably reduced, settlement for the remaining
> routes becomes moot.
>
> This is usually within a few percent of the routing efficiency that
> would have been achieved with total route propagation.
>
>
> 3. The routing overlay
>
> Establish a semi-stateless tunneling system. Each BGP participant sets
> up a tunnel ingress node and links a default route to it. Packets for
> a destination not found in the routing table follow the default route
> to the tunnel ingress.
>
> The tunnel device then looks up an tunnel exit node via a mapping
> protocol. Both the map server and the exit node have to be hosted on
> IP addresses reachable via the normal routing table.
>
> Having found an exit node, the original packet is encapsulated into a
> tunnel packet and sent to the exit node. The exit node is in a part of
> the network that carries an explicit route to the destination.
>
> Then, move the definition of threshold size. Except for whitelisted
> critical infrastructure, /24 advertisements would no longer carry an
> expectation of universal distribution. To maintain connectivity, folks
> at the bottom of the chain would need to establish or subscribe to
> tunnel exit nodes that have a route back to them.
>
> With the routing costs suitably reduced, settlement for the remaining
> routes becomes moot.
>
> The IRTF Routing Research Group studied such protocols a few years ago
> and have pretty well fleshed out how to make one work with all the
> tangled issues involving path mtu, dead path detection and so on.
> Multiple designs sit on a shelf waiting for a promise that the
> technology will be purchased if built.
>
> Regards,
> Bill Herrin
>
>
> --
> William D. Herrin  her...@dirtside.com  b...@herrin.us
> 3005 Crane Dr. .. Web: 
> Falls Church, VA 22042-3004
>
>

Re: minimum IPv6 announcement size

[Randy Bush]

>> sounds just like folks in 1985, talking about IPv4...
> The foundation of that, though, was ignorance of address space 
> exhaustion.

no.  ipv4 was the second time, not the first

randy

Re: minimum IPv6 announcement size

[joel jaeggli]

On Sep 26, 2013, at 1:18 PM, Darren Pilgrim  wrote:

> On 9/26/2013 1:07 PM, joel jaeggli wrote:
>> 
>> On Sep 26, 2013, at 12:29 PM, Darren Pilgrim 
>> wrote:
>> 
>>> On 9/26/2013 1:52 AM, bmann...@vacation.karoshi.com wrote:
 sounds just like folks in 1985, talking about IPv4...
>>> 
>>> The foundation of that, though, was ignorance of address space
>>> exhaustion.  IPv4's address space was too small for such large
>>> thinking.
>> 
>> The first dicussion I could find about ipv4 runnout  in email
>> archives is circa 1983
>> 
>>> IPv6 is far beyond enough to use such allocation policies.
>> 
>> There are certain tendencies towards profligacy that might
>> prematurely influence the question of ipv6 exhaustion and we should
>> be on guard against them… allocating enough /48s as part of direct
>> assignments  is probably not one of them.
> 
> That's just it, I really don't think we actually have an exhaustion risk with 
> IPv6.  IPv6 is massive beyond massive.  Let me explain.
> 

Instead of explaining to me how awesomely big ipv6 is you might figure out who 
you're talking to, or maybe consider the problem a bit more.

Semantic addressing schemes can soak up as many bits as you're willing to give 
them.

ISP(s) using (for example) 6rd or other automatic prefix mapping mechanisms can 
potentially use rather large prefixes.

128 bits is not so many that we can't trivially soak them all up and we should 
not pretend otherwise. We are stewards of the resource and we should manage it 
with care that reflect's long term thinking, both so that allocations we make 
now are not inappropriately small in the future and such that we are not again 
confronting the shortcomings of our decision-making again in 20 years.


> We have this idea of the "/64 boundary".  All those nifty automatic 
> addressing things rely on it.  We now have two generations of hardware and 
> software that would more or less break if we did away with it.  In essence, 
> we've translated an IPv4 /32 into an IPv6 /64.  Not great, but still quite 
> large.
> 
> Current science says Earth can support ten billion humans.  If we let the 
> humans proliferate to three times the theoretical upper limit for Earth's 
> population, a /64 for each human would be at about a /35's worth of /64's.  
> If we're generous with Earth's carrying capacity, a /36.
> 
> If we handed out /48's instead so each human could give a /64 to each of 
> their devices, it would all fit in a single /52.  Those /48's would number 
> existance at a rate of one /64 per human, one /64 per device, and a 65535:1 
> device:human ratio.  That means we could allocate 4000::/3 just for Earth 
> humans and devices and never need another block for that purpose.
> 
> That's assuming a very high utilisation ratio, of course, but really no worse 
> than IPv4 is currently.  The problem isn't allocation density, but router 
> hardware.  We need room for route aggregation and other means of 
> compartmentalisation.  Is a 10% utilisation rate sparse enough?  At 10% 
> utilisation, keeping the allocations to just 4000::/3, we'd need less than a 
> single /60 for all those /48's.  If 10% isn't enough, we can go quite a bit 
> farther:
> 
> - 1% utilisation would fit all those /48's into a /62.
> - A full /64 of those /48's would be 0.2% utilisation.
> - 0.1%? We'd have to steal a bit and hand out /47's instead.
> - /47 is ugly.  At /52, we'd get .024% (one per 4096).
> 
> That's while maintaining a practice of one /64 per human or device with 65535 
> devices per human.  Introduce one /64 per subnet and sub-ppm utilisation is 
> possible.  That would be giving a site a /44 and them only ever using the 
> ::/64 of it.
> 
> Even with sloppy, sparse allocation policies and allowing limitless human and 
> device population growth, we very likely can not exhaust IPv6.
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: minimum IPv6 announcement size

[William Herrin]

On Thu, Sep 26, 2013 at 4:18 PM, Darren Pilgrim  wrote:
> That's just it, I really don't think we actually have an exhaustion risk
> with IPv6.  IPv6 is massive beyond massive.

Hi Darren,

At one point, I saw a proposal to allocate IPv6 /15's to ISPs. One /16
so they could overlay 32 bits of IPv4 using 6rd and deliver a /48 per
ipv4 address and the other /16 for their native IPv6 operation,
packaged as a /15 so they wouldn't need multiple routes.

Yeah.

So if we let ourselves assign addresses carelessly we could run out in
the first half of this century. And while the plan above didn't fly,
IPv6 /19's and /22's have been allocated already.

Regards,
Bill Herrin


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

Re: minimum IPv6 announcement size

[Darren Pilgrim]

On 9/26/2013 1:07 PM, joel jaeggli wrote:


On Sep 26, 2013, at 12:29 PM, Darren Pilgrim 
wrote:


On 9/26/2013 1:52 AM, bmann...@vacation.karoshi.com wrote:

sounds just like folks in 1985, talking about IPv4...


The foundation of that, though, was ignorance of address space
exhaustion.  IPv4's address space was too small for such large
thinking.


The first dicussion I could find about ipv4 runnout  in email
archives is circa 1983


IPv6 is far beyond enough to use such allocation policies.


There are certain tendencies towards profligacy that might
prematurely influence the question of ipv6 exhaustion and we should
be on guard against them… allocating enough /48s as part of direct
assignments  is probably not one of them.


That's just it, I really don't think we actually have an exhaustion risk 
with IPv6.  IPv6 is massive beyond massive.  Let me explain.


We have this idea of the "/64 boundary".  All those nifty automatic 
addressing things rely on it.  We now have two generations of hardware 
and software that would more or less break if we did away with it.  In 
essence, we've translated an IPv4 /32 into an IPv6 /64.  Not great, but 
still quite large.


Current science says Earth can support ten billion humans.  If we let 
the humans proliferate to three times the theoretical upper limit for 
Earth's population, a /64 for each human would be at about a /35's worth 
of /64's.  If we're generous with Earth's carrying capacity, a /36.


If we handed out /48's instead so each human could give a /64 to each of 
their devices, it would all fit in a single /52.  Those /48's would 
number existance at a rate of one /64 per human, one /64 per device, and 
a 65535:1 device:human ratio.  That means we could allocate 4000::/3 
just for Earth humans and devices and never need another block for that 
purpose.


That's assuming a very high utilisation ratio, of course, but really no 
worse than IPv4 is currently.  The problem isn't allocation density, but 
router hardware.  We need room for route aggregation and other means of 
compartmentalisation.  Is a 10% utilisation rate sparse enough?  At 10% 
utilisation, keeping the allocations to just 4000::/3, we'd need less 
than a single /60 for all those /48's.  If 10% isn't enough, we can go 
quite a bit farther:


- 1% utilisation would fit all those /48's into a /62.
- A full /64 of those /48's would be 0.2% utilisation.
- 0.1%? We'd have to steal a bit and hand out /47's instead.
- /47 is ugly.  At /52, we'd get .024% (one per 4096).

That's while maintaining a practice of one /64 per human or device with 
65535 devices per human.  Introduce one /64 per subnet and sub-ppm 
utilisation is possible.  That would be giving a site a /44 and them 
only ever using the ::/64 of it.


Even with sloppy, sparse allocation policies and allowing limitless 
human and device population growth, we very likely can not exhaust IPv6.

Re: minimum IPv6 announcement size

[joel jaeggli]

On Sep 26, 2013, at 12:29 PM, Darren Pilgrim  wrote:

> On 9/26/2013 1:52 AM, bmann...@vacation.karoshi.com wrote:
>>  sounds just like folks in 1985, talking about IPv4...
> 
> The foundation of that, though, was ignorance of address space exhaustion.  
> IPv4's address space was too small for such large thinking.

The first dicussion I could find about ipv4 runnout  in email archives is circa 
1983

>  IPv6 is far beyond enough to use such allocation policies.

There are certain tendencies towards profligacy that might prematurely 
influence the question of ipv6 exhaustion and we should be on guard against 
them… allocating enough /48s as part of direct assignments  is probably not one 
of them.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: minimum IPv6 announcement size

[Darren Pilgrim]

On 9/26/2013 1:52 AM, bmann...@vacation.karoshi.com wrote:

  sounds just like folks in 1985, talking about IPv4...


The foundation of that, though, was ignorance of address space 
exhaustion.  IPv4's address space was too small for such large thinking. 
 IPv6 is far beyond enough to use such allocation policies.

Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size)

[Randy Bush]

y'know, it's funny.  there is a market in ipv4 space.  there is no
market in routing table slots.  perhaps this is not conspiracy but
rather the market is speaking.

of course, we can use the idea of a market in routing table slots,
rack space, or coffee to distract from the artificial problems in
the only actual market, ipv4 address space.

randy

Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size)

[William Herrin]

On Thu, Sep 26, 2013 at 11:07 AM, John Curran  wrote:
> On Sep 26, 2013, at 4:52 AM, bmann...@vacation.karoshi.com wrote:
>
>> sounds just like folks in 1985, talking about IPv4...
>
> If there were ever were a need for an market/settlement model, it is with 
> respect
> to routing table slots.
> That's not to say that establishing a framework for externalizing routing 
> costs would
> be easy; it's a complicated and twisted matter, and also fraught with various 
> legal &
> competitive aspects.

Hi John,

That's putting it mildly. Establishing such a framework would be an
immense challenge. Here are some ideas I've heard:


1. The International Clearinghouse

Every BGP participant files with a clearinghouse, specifying:

a. How much they charge to carry 1 route
b. Whether or not they are a leaf node
c. Whether or not they are a transit-free network.

Any network which is not transit free must implement a default route
which leads to a big transit-free network in order to maintain full
connectivity.

The BGP participants then publish the exact routes they intend to
announce to the clearinghouse and for each one select which networks
they'll pay to carry the route. The route must still reach each
network via BGP; payment just means that the network won't filter the
route out.

The clearinghouse then collects payments from everybody and makes
payments to everybody, as well as providing each participant a list of
the routes that are paid for. Sellers are expected to promptly
incorporate new paid routes into their BGP filters.

>From my research a few years ago, a reasonable rate would be around 3
to 4 cents per year per advertised route per BGP-carrying router in
the organization. A couple billion dollars per year if the routing
table maintained its current size.


2. The partial routing scenario

Large service providers put bids in to the RIRs for the right to
announce /8 covering routes for each /8 delegated to the RIR. Each /8
matches exactly one service provider. Smaller BGP system participants
make private arrangements with a small (20 to 30) set of networks
(including their direct ISPs) to carry their advertised routes through
a reasonably redundant number of pathways to (and including) the
winning bidder for the /8 they inhabit. For the sake of performance,
they may also pay additional large networks to shortcut the traffic
towards them rather than let it dump at the /8 advertiser.

For the folks you don't pay via the clearinghouse, many end-user
systems and the majority of transit systems simply don't carry your
route unless yours is among the handful of systems critically
important to their customers. Instead, traffic to your network follows
the /8 advertisement until it reaches a network which carries your
specific route.

With the routing costs suitably reduced, settlement for the remaining
routes becomes moot.

This is usually within a few percent of the routing efficiency that
would have been achieved with total route propagation.


3. The routing overlay

Establish a semi-stateless tunneling system. Each BGP participant sets
up a tunnel ingress node and links a default route to it. Packets for
a destination not found in the routing table follow the default route
to the tunnel ingress.

The tunnel device then looks up an tunnel exit node via a mapping
protocol. Both the map server and the exit node have to be hosted on
IP addresses reachable via the normal routing table.

Having found an exit node, the original packet is encapsulated into a
tunnel packet and sent to the exit node. The exit node is in a part of
the network that carries an explicit route to the destination.

Then, move the definition of threshold size. Except for whitelisted
critical infrastructure, /24 advertisements would no longer carry an
expectation of universal distribution. To maintain connectivity, folks
at the bottom of the chain would need to establish or subscribe to
tunnel exit nodes that have a route back to them.

With the routing costs suitably reduced, settlement for the remaining
routes becomes moot.

The IRTF Routing Research Group studied such protocols a few years ago
and have pretty well fleshed out how to make one work with all the
tangled issues involving path mtu, dead path detection and so on.
Multiple designs sit on a shelf waiting for a promise that the
technology will be purchased if built.

Regards,
Bill Herrin


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

RE: minimum IPv6 announcement size

[Azinger, Marla]

There are many ways to mediate this.  No matter what one is chosen a balance 
between market, Networks and policy will need to be met.  And in the end 
Networks will do what is best for their network.  However if there is a norm of 
some kind, then at least there will be a target to hover around.

Market & Networks- 
Pro- Entities managing the health of their network would be less willing to 
route what would result in overload.
Con- The more financially healthy Entities can afford faster turn over and burn 
to new routers and circuit upgrades. The upper hand of growth goes to them 
since overload wouldn't be as much as an internal issue as it would be to other 
smaller networks.  The global scheme gets lost in the eye of the mighty dollar. 
 This is not anything new market pattern wise but Larger/Financially healthy 
entities would survive better than any smaller provider.

Policy
Pro- there would be a set standard to target
Con- policy is managed by the community and not always supporting every 
business model equally.  Plus policy can become a moving target as we have 
witnessed with IPv4.

List Publishing-Policy
Pro- qualified ASN's are approved a range of subnet size of route 
advertisements and any "too specific/smaller" advertisements are  ignored 
if not on the list.
Con- this is policy. No one tells a network what to do.  

Set Boundary policy 
Pro- something exists as a target to help manage the issue
Con- policy is very likely to become a moving target. No one tells a 
network what to do. 

Keep Head in Sand
Pro- Happy
Con- Calamity...but when? Or will there be a new option...the next best thing.  
Hope in one hand and @#$$ in the other.  One usually fills up faster.

Somehow the community needs to choose one of these paths.

My 2 cents 
Marla


-Original Message-
From: Patrick [mailto:na...@haller.ws] 
Sent: Thursday, September 26, 2013 2:23 AM
To: bmann...@vacation.karoshi.com
Cc: nanog@nanog.org
Subject: Re: minimum IPv6 announcement size

On 2013-09-26 08:52, bmann...@vacation.karoshi.com wrote:
>  sounds just like folks in 1985, talking about IPv4...

Yeah, but who doesn't run CIDR now?

Get everyone in the IPv6 pool now; we'll inevitably add hacks later

Filter-based routing table management (was: Re: minimum IPv6 announcement size)

[John Curran]

On Sep 26, 2013, at 4:52 AM, bmann...@vacation.karoshi.com wrote:

> sounds just like folks in 1985, talking about IPv4...

If there were ever were a need for an market/settlement model, it is with 
respect 
to routing table slots.  As it is, we have no real feedback mechanism in the 
present
system, just conventions that are variably enforced depending on relative 
stature of 
the parties having the discussion.  Externalizing the true cost of having a 
prefix 
routed would create a more equitable and fair environment (i.e. knowledge that 
you 
could have any prefix globally routed for a fairly predictable cost, and 
ability to 
weigh the benefits of that versus taking a prefix from your ISP.)  It might 
even 
spur research into various interesting alternatives such routing costs for 
smaller 
scopes (regional, geographic, etc.) and cost implications and technical 
tradeoffs
from various alternative mobility schemes.

That's not to say that establishing a framework for externalizing routing costs 
would 
be easy; it's a complicated and twisted matter, and also fraught with various 
legal &
competitive aspects.  However, it would at least be doing something more than 
crossing 
our fingers and just hoping for the best out of today's "IPv6 prefixes for 
all"...  
Another benefit of such a system (for those fans of market-based approaches) is 
that 
we could better utilize IPv4, rather than the currently implied "/24 is 
routable, /25 
is not" filter-based approach which may not survive the market pressures 
associated 
with IPv4 depletion in any case...

FYI,
/John

Disclaimer:  My views alone.  Feel free to ignore this message as desired.

Re: minimum IPv6 announcement size

[Patrick]

On 2013-09-26 08:52, bmann...@vacation.karoshi.com wrote:
>  sounds just like folks in 1985, talking about IPv4...

Yeah, but who doesn't run CIDR now?

Get everyone in the IPv6 pool now; we'll inevitably add hacks later

Re: minimum IPv6 announcement size

[bmanning]

 sounds just like folks in 1985, talking about IPv4...


/bill


On Wed, Sep 25, 2013 at 06:45:02AM -0700, Owen DeLong wrote:
> Each site should get at least a /48.
> 
> Stop worrying about dense-packing the IP space in IPv6. This is IPv4-think. 
> IPv6 is intended to be sparsely allocated.
> 
> Owen
> 
> On Sep 24, 2013, at 8:10 PM, Nathanael C. Cariaga  
> wrote:
> 
> > Hi,
> > 
> > I raised actually this concern during our IP resource application.
> > 
> > On a personal note, I think /48 IPv6 allocation is more than enough for our 
> > organization to use for at least the next 5-10 years assuming that this can 
> > be farmed out to our multiple sites. What makes this complicated for us is 
> > that we are operating on a multiple sites (geographically) with each site 
> > is doing multi-homing and having a /48 in each site would be very big waste 
> > of IP resources.
> > 
> > -nathan
> > 
> > On 9/25/2013 2:36 AM, Bryan Socha wrote:
> >> Everyone is following the same policies.   a /48 PER SITE.did you
> >> request enough addresses from your RIR?
> >> 
> >> Bryan Socha
> >> 
> > 
> 
> 

Re: minimum IPv6 announcement size

[Owen DeLong]

Each site should get at least a /48.

Stop worrying about dense-packing the IP space in IPv6. This is IPv4-think. 
IPv6 is intended to be sparsely allocated.

Owen

On Sep 24, 2013, at 8:10 PM, Nathanael C. Cariaga  
wrote:

> Hi,
> 
> I raised actually this concern during our IP resource application.
> 
> On a personal note, I think /48 IPv6 allocation is more than enough for our 
> organization to use for at least the next 5-10 years assuming that this can 
> be farmed out to our multiple sites. What makes this complicated for us is 
> that we are operating on a multiple sites (geographically) with each site is 
> doing multi-homing and having a /48 in each site would be very big waste of 
> IP resources.
> 
> -nathan
> 
> On 9/25/2013 2:36 AM, Bryan Socha wrote:
>> Everyone is following the same policies.   a /48 PER SITE.did you
>> request enough addresses from your RIR?
>> 
>> Bryan Socha
>> 
> 

Re: minimum IPv6 announcement size

[Måns Nilsson]

Subject: Re: minimum IPv6 announcement size Date: Wed, Sep 25, 2013 at 
11:10:52AM +0800 Quoting Nathanael C. Cariaga (nccari...@stluke.com.ph):
> Hi,
> 
> I raised actually this concern during our IP resource application.
> 
> On a personal note, I think /48 IPv6 allocation is more than enough
> for our organization to use for at least the next 5-10 years
> assuming that this can be farmed out to our multiple sites. What
> makes this complicated for us is that we are operating on a multiple
> sites (geographically) with each site is doing multi-homing and
> having a /48 in each site would be very big waste of IP resources.

If you've got island networks w/o links between you SHOULD request a /48 per 
site. 

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
Pardon me, but do you know what it means to be TRULY ONE with your BOOTH!


signature.asc
Description: Digital signature

Re: minimum IPv6 announcement size

[Måns Nilsson]

Subject: Re: minimum IPv6 announcement size Date: Tue, Sep 24, 2013 at 
08:00:44AM -1000 Quoting Randy Bush (ra...@psg.com):
> > I am running a network that is operating on multiple sites and
> > currently rolling out our IPv6 on the perimeter level.  Having to
> > get our /48 allocation from our RIR
> 
> excuse, but which rir handed out a /48 under which policy?

Any of them?

% Information related to '2001:67c:d8::/48'

inet6num:   2001:67c:d8::/48
netname:SR-V6
descr:  Sveriges Radio AB
country:SE
org:ORG-SR18-RIPE
admin-c:MN1334-RIPE
admin-c:LEW3-RIPE
tech-c: MN1334-RIPE
tech-c: LEW3-RIPE
status: ASSIGNED PI
mnt-by: RIPE-NCC-END-MNT
mnt-lower:  RIPE-NCC-END-MNT
mnt-by: SR-MNT
mnt-routes: SR-MNT
mnt-domains:SR-MNT
source: RIPE # Filtered



-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
Now, let's SEND OUT for QUICHE!!


signature.asc
Description: Digital signature

Re: minimum IPv6 announcement size

[Nathanael C. Cariaga]

I'll revisit our application then. Thank you for the info.

-nathan

On 9/25/2013 12:11 PM, Nurul Islam wrote:

I believe you can get multiple /48 from APNIC. You will not be evaluated
under HD ratio but as discrete network (no iBGP running among them). Here
it is the policy [http://www.apnic.net/policy/ipv6-address-policy#5.5.2]

Regards

Roman




On 25/09/13 11:42 AM, "Nathanael C. Cariaga" 
wrote:


We got our /48 from APNIC..

-nathan

On 9/25/2013 2:18 AM, Owen DeLong wrote:

On Sep 24, 2013, at 11:00 AM, Randy Bush  wrote:


I am running a network that is operating on multiple sites and
currently rolling out our IPv6 on the perimeter level.  Having to
get our /48 allocation from our RIR

excuse, but which rir handed out a /48 under which policy?

randy

ARIN will give out /48s to end users.

AfriNIC will give out /48s to end users.

I believe (but haven't verified) that this is also possible from APNIC
and LACNIC.

Someone else mentioned that RIPE will as well.

Owen

Re: minimum IPv6 announcement size

[Nurul Islam]

I believe you can get multiple /48 from APNIC. You will not be evaluated
under HD ratio but as discrete network (no iBGP running among them). Here
it is the policy [http://www.apnic.net/policy/ipv6-address-policy#5.5.2]

Regards

Roman

   

On 25/09/13 11:42 AM, "Nathanael C. Cariaga" 
wrote:

>We got our /48 from APNIC..
>
>-nathan
>
>On 9/25/2013 2:18 AM, Owen DeLong wrote:
>> On Sep 24, 2013, at 11:00 AM, Randy Bush  wrote:
>>
 I am running a network that is operating on multiple sites and
 currently rolling out our IPv6 on the perimeter level.  Having to
 get our /48 allocation from our RIR
>>> excuse, but which rir handed out a /48 under which policy?
>>>
>>> randy
>> ARIN will give out /48s to end users.
>>
>> AfriNIC will give out /48s to end users.
>>
>> I believe (but haven't verified) that this is also possible from APNIC
>>and LACNIC.
>>
>> Someone else mentioned that RIPE will as well.
>>
>> Owen
>>
>
>

Re: minimum IPv6 announcement size

[Mikael Abrahamsson]

On Wed, 25 Sep 2013, Nathanael C. Cariaga wrote:

doing multi-homing and having a /48 in each site would be very big waste 
of IP resources.


IPv6 was designed with an expectation of having /48 per geographical site 
and this is perfectly fine.


I have a /48 at home.

What is more of a concern is to do aggregation in the DFZ, if every size 
got itself a /48 PI and announced it in the DFZ then the routing system 
would not be very happy...


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

Re: minimum IPv6 announcement size

[joel jaeggli]

On 9/24/13 8:10 PM, Nathanael C. Cariaga wrote:
> Hi,
> 
> I raised actually this concern during our IP resource application.
> 
> On a personal note, I think /48 IPv6 allocation is more than enough for
> our organization to use for at least the next 5-10 years assuming that
> this can be farmed out to our multiple sites. What makes this
> complicated for us is that we are operating on a multiple sites
> (geographically) with each site is doing multi-homing and having a /48
> in each site would be very big waste of IP resources.

It's not waste and you should adjust the expectations somewhat.

With a /48 You typically have enough bits to do hierachical addressing
plans, prefix delegation and other things which you may need but are not
currently planning for.

> -nathan
> 
> On 9/25/2013 2:36 AM, Bryan Socha wrote:
>> Everyone is following the same policies.   a /48 PER SITE.did you
>> request enough addresses from your RIR?
>>
>> Bryan Socha
>>
> 
> 

Re: minimum IPv6 announcement size

[Nathanael C. Cariaga]

Hi,

I raised actually this concern during our IP resource application.

On a personal note, I think /48 IPv6 allocation is more than enough for 
our organization to use for at least the next 5-10 years assuming that 
this can be farmed out to our multiple sites. What makes this 
complicated for us is that we are operating on a multiple sites 
(geographically) with each site is doing multi-homing and having a /48 
in each site would be very big waste of IP resources.


-nathan

On 9/25/2013 2:36 AM, Bryan Socha wrote:

Everyone is following the same policies.   a /48 PER SITE.did you
request enough addresses from your RIR?

Bryan Socha

Re: minimum IPv6 announcement size

[Nathanael C. Cariaga]

Hi All,

Thank you for these insights.  We'll look into all of these and review 
again our options on how we can further proceed in our IPv6 deployment.



Regards,

-nathan

On 9/25/2013 2:33 AM, William Herrin wrote:

On Tue, Sep 24, 2013 at 9:49 AM, Nathanael C. Cariaga
 wrote:

I've been Google-ing about if there is such a standard that sets the minimum
IPv6 advertisement on BGP.  My concern is that I am running a network that
is operating on multiple sites and currently rolling out our IPv6 on the
perimeter level.  Having to get our /48 allocation from our RIR, I figured
out I would it would be best for us to break down the /48 into smaller
chunks (i.e /56s) and farm it out to our sites since a single /48 will be
very big for our single site.

Hi Nathanael,

Many if not most networks set a limit at /48. Verizon was the last
player of consequence to filter at /32, and they moved to /48 a couple
years ago. A few also try to limit advertisements within ISP space
nearer to /32. Usually not at /32, but a /48 announcement within space
allocated to an ISP won't necessarily be honored.

If you have distinct networks with distinct routing policies (or can
make a reasonable claim to such) and your RIR is ARIN, you can request
a block size large enough to provide a /48 to each distinct network. A
/44 or whatever. Search through the ARIN NRPM for details. I don't
know about the other RIRs; someone in your region (Asia Pacific?) will
know.

Regards,
Bill Herrin

Re: minimum IPv6 announcement size

[Nathanael C. Cariaga]

We got our /48 from APNIC..

-nathan

On 9/25/2013 2:18 AM, Owen DeLong wrote:

On Sep 24, 2013, at 11:00 AM, Randy Bush  wrote:


I am running a network that is operating on multiple sites and
currently rolling out our IPv6 on the perimeter level.  Having to
get our /48 allocation from our RIR

excuse, but which rir handed out a /48 under which policy?

randy

ARIN will give out /48s to end users.

AfriNIC will give out /48s to end users.

I believe (but haven't verified) that this is also possible from APNIC and 
LACNIC.

Someone else mentioned that RIPE will as well.

Owen

RE: minimum IPv6 announcement size

[Steve Bertrand]

> -Original Message-
> From: Owen DeLong [mailto:o...@delong.com]
> Sent: September-24-13 12:19
> To: Randy Bush
> Cc: NANOG Mailing List
> Subject: Re: minimum IPv6 announcement size
> 
> 
> On Sep 24, 2013, at 11:00 AM, Randy Bush  wrote:
> 
> >> I am running a network that is operating on multiple sites and
> >> currently rolling out our IPv6 on the perimeter level.  Having
> to get
> >> our /48 allocation from our RIR
> >
> > excuse, but which rir handed out a /48 under which policy?
> >
> > randy
> 
> ARIN will give out /48s to end users.
> 
> AfriNIC will give out /48s to end users.
> 
> I believe (but haven't verified) that this is also possible from
> APNIC and LACNIC.

APNIC:

7.2.1. Initial Assignments

"APNIC will allocate a minimum of a /48 to organizations that can 
demonstrate..."

LACNIC:

4.5.4. Direct Assignments to End Sites

In a couple of subsections: "Assignments will be made in blocks smaller than or 
equal to a /32 but always greater than or equal to a /48."

Steve

Re: minimum IPv6 announcement size

[Bryan Socha]

Everyone is following the same policies.   a /48 PER SITE.did you
request enough addresses from your RIR?

Bryan Socha

Re: minimum IPv6 announcement size

[William Herrin]

On Tue, Sep 24, 2013 at 9:49 AM, Nathanael C. Cariaga
 wrote:
> I've been Google-ing about if there is such a standard that sets the minimum
> IPv6 advertisement on BGP.  My concern is that I am running a network that
> is operating on multiple sites and currently rolling out our IPv6 on the
> perimeter level.  Having to get our /48 allocation from our RIR, I figured
> out I would it would be best for us to break down the /48 into smaller
> chunks (i.e /56s) and farm it out to our sites since a single /48 will be
> very big for our single site.

Hi Nathanael,

Many if not most networks set a limit at /48. Verizon was the last
player of consequence to filter at /32, and they moved to /48 a couple
years ago. A few also try to limit advertisements within ISP space
nearer to /32. Usually not at /32, but a /48 announcement within space
allocated to an ISP won't necessarily be honored.

If you have distinct networks with distinct routing policies (or can
make a reasonable claim to such) and your RIR is ARIN, you can request
a block size large enough to provide a /48 to each distinct network. A
/44 or whatever. Search through the ARIN NRPM for details. I don't
know about the other RIRs; someone in your region (Asia Pacific?) will
know.

Regards,
Bill Herrin



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

Re: minimum IPv6 announcement size

[Owen DeLong]

On Sep 24, 2013, at 11:00 AM, Randy Bush  wrote:

>> I am running a network that is operating on multiple sites and
>> currently rolling out our IPv6 on the perimeter level.  Having to
>> get our /48 allocation from our RIR
> 
> excuse, but which rir handed out a /48 under which policy?
> 
> randy

ARIN will give out /48s to end users.

AfriNIC will give out /48s to end users.

I believe (but haven't verified) that this is also possible from APNIC and 
LACNIC.

Someone else mentioned that RIPE will as well.

Owen

Re: minimum IPv6 announcement size

[Edward Dore]

RIPE will give you a /48 of IPv6 PI

http://www.ripe.net/ripe/docs/ripe-552#IPv6_PI_Assignments

Edward Dore 
Freethought Internet 

On 24 Sep 2013, at 19:00, Randy Bush wrote:

>> I am running a network that is operating on multiple sites and
>> currently rolling out our IPv6 on the perimeter level.  Having to
>> get our /48 allocation from our RIR
> 
> excuse, but which rir handed out a /48 under which policy?
> 
> randy
> 

Re: minimum IPv6 announcement size

[Randy Bush]

> I am running a network that is operating on multiple sites and
> currently rolling out our IPv6 on the perimeter level.  Having to
> get our /48 allocation from our RIR

excuse, but which rir handed out a /48 under which policy?

randy

Re: minimum IPv6 announcement size

[Ben]

On 24/09/2013 14:49, Nathanael C. Cariaga wrote:

Hi,

Just wondering if anyone could shed light on my concern.

I've been Google-ing about if there is such a standard that sets the
minimum IPv6 advertisement on BGP.



You need to work on your google-fu then ...

https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-ipv6-48-filtering

Happy bed time reading ;-)

Re: minimum IPv6 announcement size

[joel jaeggli]

On 9/24/13 6:47 AM, Otis L. Surratt, Jr. wrote:
> -Original Message-
> From: Nathanael C. Cariaga [mailto:nccari...@stluke.com.ph] 
> Sent: Tuesday, September 24, 2013 8:50 AM
> To: NANOG Mailing List
> Subject: minimum IPv6 announcement size
> 
>> Hi,
>>
>> Just wondering if anyone could shed light on my concern.
>>
>> I've been Google-ing about if there is such a standard that sets the
> minimum IPv6 advertisement on BGP.  My concern is that I am running a
> network that is operating on multiple sites and currently rolling >out
> our IPv6 on the perimeter level.  Having to get our /48 allocation from
> our RIR, I figured out I would it would be best for us to break down the
>> /48 into smaller chunks (i.e /56s) and farm it out to our sites since a
> single /48 will be very big for our single site.

Your RIR ought to make a minimum allocation based on the number of sites
you need to deploy to, so something shorter than a /48. clearly you
should aim for the highest acheiveable aggregation but that's not always
possible.

the fact that it is "large for your site" isn't germain to the
discussion of what's the minimally accepted size prefix.

>> Any advise will be very much appreciated.
>>
>>
>> Regards,
>>
>> --
>> -nathan
> 
> Minimum announcement for IPv6 as I recall is /48. Some providers might
> accept less for their networks.

I've seen providers accept longer but not propigate them. we apply
filters at the /48 level, That appears to be sufficiently common that it
confers herd immunity to shorter prefixes.

> -Otis
> 
> 

RE: minimum IPv6 announcement size

[Otis L. Surratt, Jr.]

-Original Message-
From: Nathanael C. Cariaga [mailto:nccari...@stluke.com.ph] 
Sent: Tuesday, September 24, 2013 8:50 AM
To: NANOG Mailing List
Subject: minimum IPv6 announcement size

>Hi,
>
>Just wondering if anyone could shed light on my concern.
>
>I've been Google-ing about if there is such a standard that sets the
minimum IPv6 advertisement on BGP.  My concern is that I am running a
network that is operating on multiple sites and currently rolling >out
our IPv6 on the perimeter level.  Having to get our /48 allocation from
our RIR, I figured out I would it would be best for us to break down the
>/48 into smaller chunks (i.e /56s) and farm it out to our sites since a
single /48 will be very big for our single site.
>
>Any advise will be very much appreciated.
>
>
>Regards,
>
>--
>-nathan

Minimum announcement for IPv6 as I recall is /48. Some providers might
accept less for their networks.

-Otis

minimum IPv6 announcement size

[Nathanael C. Cariaga]

Hi,

Just wondering if anyone could shed light on my concern.

I've been Google-ing about if there is such a standard that sets the 
minimum IPv6 advertisement on BGP.  My concern is that I am running a 
network that is operating on multiple sites and currently rolling out 
our IPv6 on the perimeter level.  Having to get our /48 allocation from 
our RIR, I figured out I would it would be best for us to break down the 
/48 into smaller chunks (i.e /56s) and farm it out to our sites since a 
single /48 will be very big for our single site.


Any advise will be very much appreciated.


Regards,

--
-nathan