geo-based routing [Re: IPv6 news]

[Pekka Savola]

On Mon, 17 Oct 2005 [EMAIL PROTECTED] wrote:

http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt
will be quite of your liking.


Not at all. This proposal is all about allocating addresses
based on country boundaries and I reject this model. The
Internet is a network of cities, not countries.  The national
boundaries are completely random in technical terms, but
the cities are not random. The cities are where the people
are, where the railways and roads are, where the channels
of trade and communication begin and end.


Uhh, I'd say the internet is a network of networks, not a network of 
cities. :)


But you bring a good point about railways.  But are there enough 
privately-owned railways to make a good analogue?  (This certainly 
doesn't apply to roads)  I.e., when a dozen different railway 
companies want to provide transport, do each and every one of them 
build (parallel) tracks, stations, and trains on each city?  I do not 
think so, but I do not know if any sort of "roaming" agreements exist.


Or are you arguing that the basic infra (like the fibers) should be 
city/government/etc. controlled so it could be used in more 
cost-effective ways by all providers?



--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Tony Li]

True enough, but unfortunately, it's not done in a way that we can  
make use of the identifier in the routing subsystem or in the  
transport protocols.




The transport protocols, well they generally act on behalf of  
something which can do the lookup and supply transport with right  
address, as long the DNS server does not require "who"->"where"  
indirection ;).



The transport protocols unfortunately need the identifier in the  
packet to demux connections.


Tony

Re: IPv6 news

[Paul Jakma]

On Mon, 17 Oct 2005, Andre Oppermann wrote:

We all know how well carrier phone number routing and number 
portability works, don't we?


EWORKSFORME (and everyone else here). Took a good bit of very firm 
pressure from ComReg, the telecoms wathdog/regulator here, to 
overcome negative reaction from the operators though.


(There's no such pressure which could be applied on IP operators, but 
same processes essentially could be applied at least for IP 
connectivity at national regulatory levels at least - trade /32's at 
INEX, the IX here and figure out billing. If only ComReg had the 
authority.. ;) ).


regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
"When people are least sure, they are often most dogmatic."
-- John Kenneth Galbraith

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Paul Jakma]

On Mon, 17 Oct 2005, Mikael Abrahamsson wrote:

Also, if everybody got their equal size subnet delegation from each 
ISP then it shouldnt be that much of a problem to run two 
"networks" side-by-side by using the subnet part of the delegation 
equal to both networks, but keep the prefix separate. If you switch 
providers you change the prefix part. This means we need new 
mechanisms to handle this,


Hmm, one thing that would be nice would be to seperate the prefix 
from the host identifier in DNS, oh... wait..



but I feel that's better than doing the routing mistake again.


It's all routing, just shifting different portions of it to different 
places.


regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
panic ("Splunge!");
linux-2.2.16/drivers/scsi/psi240i.c

Re: IPv6 daydreams

[Paul Jakma]

On Mon, 17 Oct 2005, David Barak wrote:

Wrong issue.  What I'm unhappy about is not the size of the address 
- you'll notice that I didn't say "make the whole address space 
smaller."  What I'm unhappy about is the exceedingly sparse 
allocation policies


You can allocate to 100% density on the network identifier if you 
want, right down to /64.


The host identifier simply is indivisible, and just happens to be 
64bit.


regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
If swimming is so good for your figure, how do you explain whales?

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Paul Jakma]

On Mon, 17 Oct 2005, Tony Li wrote:

True.  Even better, you get to change this binding (mobility) or 
have multiple bindings (multihoming).


Indeed.

True enough, but unfortunately, it's not done in a way that we can 
make use of the identifier in the routing subsystem or in the 
transport protocols.


Well, if the idea is that the global routing subsystem should not 
have to burdened with the overwhelming details of "who"->"where", 
then this mightn't matter much - all routing needs to know is 
"where".


The transport protocols, well they generally act on behalf of 
something which can do the lookup and supply transport with right 
address, as long the DNS server does not require "who"->"where" 
indirection ;).


The other way of course is to carry "who"->"where" as routes in our 
current routing system. Then we just have to figure out how to 
confine things topologically. Would require changes in how providers 
peer though, but it is possible.


And has been done in other networks, eg GSM in Ireland. We have 
provider-assigned, but provider-mobile prefixes. Just as with IP 
multihoming there was much protest that it couldn't be done, would be 
too problematic, would be too burdensome. However the regulator told 
the operators "I don't care, you have till X to figure it out and 
implement". The operators did figure out, presumably including how to 
do billing for the differentials of any traffic carried for customers 
who had moved to other providers... The rest of the world has no clue 
that a large set of Irish GSM telephone numbers are essentially "/32 
routed" between Irish providers. ;)


A possibility anyway (but whether it's the least worst way - i don't 
know ;) ). It does though keep operators fully involved in all 
aspects of routing.


Otherwise end-hosts will just work around the 'dumb' providers 
themselves, if there's no solution operators like. (Not a bad thing 
either really).



Tony


regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
Money isn't everything -- but it's a long way ahead of what comes next.
-- Sir Edmond Stockdale

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Paul Vixie]

[EMAIL PROTECTED] (Tony Li) writes:

> Specifically, the IAB should call for a halt to IPv6 deployment until  
> consensus is reached on a scalable routing architecture.  I realize  
> that this is painful, but continuing to deploy is simply creating a  
> v6 mortgage that we cannot afford to pay off.

well, maybe so.  but IAB could never make deployment start, and IAB cannot
make deployment stop.  deployment happens on its own terms.  leadership has
a built in time delay and a couple layers of indirection between intent and
action and results.  if you want IAB to lead somehow, give them some runway.
-- 
Paul Vixie

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Tony Li]

Fred,

So the routing problem was looked at, and making a fundamental  
routing change was rejected by both the operational community and  
the routing folks.


No, IPv6 doesn't fix (or even change) the routing of the system,  
and that problem will fester until it becomes important enough to  
change.



From this end of the elephant, we looked at Nimrod and saw potential  
there, but did not buy off on it.  We also looked at GSE and the  
routing folks at the very least seemed bought into that, but it died,  
under what I would characterize as a purely political hailstorm.


Yes, the lack of a scalable routing architecture will continue to  
fester until it has sufficient political visibility that it exceeds  
our pain threshold and we decide to make the change.  The problem  
with this model is that the pain of change grows daily.  Each and  
every v6 system that is deployed is yet another bit of installed base  
that will need to be updated someday.


The Internet community needs the IETF leadership to understand this  
very clearly and to take action to resolve this issue sooner, not  
later.  As others have said, this is a pay now or pay later  
situation, and the pay later portion is MUCH more expensive.   
Specifically, the IAB should call for a halt to IPv6 deployment until  
consensus is reached on a scalable routing architecture.  I realize  
that this is painful, but continuing to deploy is simply creating a  
v6 mortgage that we cannot afford to pay off.


Regards,
Tony

Re: And Now for Something Completely Different (was Re: IPv6 news)

[bmanning]

> What we need is an interdomain routing system that can either (a) 
> drastically reduce the incremental cost of additional prefixes in the DFZ, 
> or (b) move the exist cost out of the DFZ to the people who want to 
> multihome.  Both probably mean ditching BGP4 and moving to some sort of 
> inter-AS MPLS scheme, but it will never see the light of day unless it 
> allows leaving hosts and intra-site routing intact (i.e. hop-by-hop routing 
> and a single prefix per site).  This last is why shim6 is DOA.

or...  drop the idea of "A"/"THE" default free zone and 
recognize that the concept is based on a flawed assumption.

--bill


> 
> S
> 
> Stephen Sprunk"Stupid people surround themselves with smart
> CCIE #3723   people.  Smart people surround themselves with
> K5SSS smart people who disagree with them."  --Aaron Sorkin 

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Stephen Sprunk]

Thus spake "Fred Baker" <[EMAIL PROTECTED]>
The RIRs have been trying pretty hard to make IPv6 allocations be one 
prefix per ISP, with truly large edge networks being treated as 
functionally equivalent to an ISP (PI addressing without admitting it  is 
being done). Make the bald assertion that this is equal to one  prefix per 
AS (they're not the same statement at all, but the number  of currently 
assigned AS numbers exceeds the number of prefixes under  discussion, so 
in my mind it makes a reasonable thumb-in-the-wind- guesstimate), that is 
a reduction of the routing table size by an  order of magnitude.


If we are able to reduce the routing table size by an order of  magnitude, 
I don't see that we have a requirement to fundamentally  change the 
routing technology to support it. We may *want* to (and  yes, I would like 
to, for various reasons), but that is a different  assertion.


If we reduce the average number of prefixes per AS by an order of magnitude, 
IMHO the result will be that there will be an order of magnitude growth in 
the number of ASes.  We're just going to trade one problem for another.


What we need is an interdomain routing system that can either (a) 
drastically reduce the incremental cost of additional prefixes in the DFZ, 
or (b) move the exist cost out of the DFZ to the people who want to 
multihome.  Both probably mean ditching BGP4 and moving to some sort of 
inter-AS MPLS scheme, but it will never see the light of day unless it 
allows leaving hosts and intra-site routing intact (i.e. hop-by-hop routing 
and a single prefix per site).  This last is why shim6 is DOA.


S

Stephen Sprunk"Stupid people surround themselves with smart
CCIE #3723   people.  Smart people surround themselves with
K5SSS smart people who disagree with them."  --Aaron Sorkin 

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Stephen Sprunk]

- Original Message - 
From: "Fred Baker" <[EMAIL PROTECTED]>

To: "Per Heldal" <[EMAIL PROTECTED]>
Cc: 
Sent: Monday, October 17, 2005 15:12
Subject: Re: And Now for Something Completely Different (was Re: IPv6 news)




That is an assumption that I haven't found it necessary to make. I  
have concluded that there is no real debate about whether the  
Internet will have to change to something that gives us the ability  
to directly address (e.g. not behind a NAT, which imposes some  
"interesting" requirements at the application layer and gateways of  
the sort which were what the Internet came about to not need) a whole  
lot more things than it does today. The debate is about how and when.  
"when" seems pretty solidly in the 3-10 year timeframe, exactly where  
in that timeframe being a point of some discussion, and "how" comes  
down to a choice of "IPv6" or "something else".


Fleming's IPv8 was a non-stupid idea that has a fundamental flaw in  
that it re-interprets parts of the IPv4 header as domain identifiers  
- it effectively extends the IP address by 16 bits, which is good,  
but does so in a way that is not backward compatible. If we could  
make those 16 bits be AS numbers (and ignoring for the moment the  
fact that we seem to need larger AS numbers), the matter follows  
pretty quickly. If one is going to change the header, though, giving  
up fragmentation as a feature sees a little tough; one may as well  
change the header and manage to keep the capability. One also needs  
to change some other protocols, such as routing AS numbers and  
including them in DNS records as part of the address.


From my perspective, we are having enough good experience with IPv6  
that we should simply choose that approach; there isn't a real good  
reason to find a different one. Yes, that means there is a long  
coexistence period yada yada yada. This is also true of any other  
fundamental network layer protocol change.


The RIRs have been trying pretty hard to make IPv6 allocations be one  
prefix per ISP, with truly large edge networks being treated as  
functionally equivalent to an ISP (PI addressing without admitting it  
is being done). Make the bald assertion that this is equal to one  
prefix per AS (they're not the same statement at all, but the number  
of currently assigned AS numbers exceeds the number of prefixes under  
discussion, so in my mind it makes a reasonable thumb-in-the-wind- 
guesstimate), that is a reduction of the routing table size by an  
order of magnitude.


If we are able to reduce the routing table size by an order of  
magnitude, I don't see that we have a requirement to fundamentally  
change the routing technology to support it. We may *want* to (and  
yes, I would like to, for various reasons), but that is a different  
assertion.


On Oct 17, 2005, at 12:42 PM, Per Heldal wrote:


mon, 17,.10.2005 kl. 11.29 -0700, Fred Baker:

OK. What you just described is akin to an enterprise network with  
a  default route. It's also akin to the way DNS works.


No default, just one or more *potential* routes.

Your input is appreciated, and yes I'm very much aware that many  
people who maintain solutions that assume full/total control of the  
entire routing-table will be screaming bloody murder if that is  
going to change. Further details about future inter-domain-routing  
concepts belong in other fora (e.g. ietf's inter-domain-routing wg).


The long-term operational impact is that the current inter-domain- 
routing concepts (BGP etc) don't scale indefinitely and will have  
to be changed some time in the future. Thus expect the size of the  
routing-table to be eliminated from the list of limiting factors,  
or that the bar is considerably raised.


---

Note that I'm not saying that nothing should be done to preserve  
and optimise the use of the resources that are available today just  
because there will be something better available in a distant  
future. I'm in favor of the most restrictive allocation policies in  
place today. The development of the internet has for a long time  
been based on finding better ways to use available resources (CIDR  
anyone). To me a natural next-step in that process is for RIR's to  
start reclaiming unused v4 address-blocks, or at least start  
collect data to document that space is not being used (if they're  
not already doing so). E.g prevously announced address-blocks that  
has disappeared from the global routing-table for more than X  
months should go back to the RIR-pool (X<=6).



//Per

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Gordon Cook]

Wasn't Noel Chiappa  Nimrods "father" ?

He explained his philosophy to me in an interview a decade ago as  
well as why he believed that BGP was not sustainable.


yet here we are  still chugging along

meanwhile back to your operational flows  ;-)

=
The COOK Report on Internet Protocol, 431 Greenway Ave, Ewing, NJ  
08618 USA
609 882-2572 (PSTN) 415 651-4147 (Lingo) [EMAIL PROTECTED]  
Subscription

info: http://cookreport.com/subscriptions.shtml IMS and  an Internet
Economic  & Business Model  at: http://cookreport.com/14.09.shtml
=




On Oct 17, 2005, at 5:58 PM, Fred Baker wrote:

now, the proposal put forward lo these many moons ago to avoid any  
possibility of a routing change was, as I recall, Nimrod, and the  
Nimrod architecture called for variable length addresses in the  
network layer protocol and the use of a flow label (as in "IPv6  
flow label") as a short-form address in some senses akin to a  
virtual circuit ID.

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Marshall Eubanks]

On Mon, 17 Oct 2005 14:24:08 -0700
 Tony Li <[EMAIL PROTECTED]> wrote:


Dear Tony et al.;

This is beginning to sound like an IETF or IRTF mail list, and, lo!, I get an 
email today 
from Leslie Daigle :

A new mailing list has been created to provide a forum for general
discussion of Internet architectural issues:

   [EMAIL PROTECTED]
   https://www1.ietf.org/mailman/listinfo/architecture-discuss

The architecture-discuss list serves as a technical discussion forum for
all members of the IETF community that are interested in larger
architectural issues. It is meant to be an open discussion forum for
all long and/or wide range architectural concerns related to the
Internet Architecture. In particular, it may be used to discuss and
bring forth different points of view on controversial architectural
questions. Discussions that drill down and dwell on specifics of
individual protocols or technologies are to be discouraged, redirected
to appropriate other fora, or re-cast to discussions of broader
implications for Internet architecture.

Maybe this  conversation should move there. Maybe a lot of operators should 
join that
list. Probably couldn't hurt.


Regards
Marshall Eubanks

> 
> 
> Daniel,
> 
> >> If we're going to put the world thru the pain of change, it seems
> >> that we should do our best to ensure that it never, ever has to
> >> happen again.
> >
> > That's the goal here? To ensure we'll never have another protocol
> > transition? I hope you realize what a flawed statement that is. We  
> > can't see
> > into the future. However, assuming that IPv6 is the Last Protocol  
> > seems a
> > bit short sighted. If we get 20 years out of IPv6, that will be  
> > just peachy.
> 
> 
> I see that as a worthy goal and no, I don't see that as flawed.   
> While we certainly cannot guarantee that v6 will be the last  
> protocol, we should certainly be designing for it to be the best that  
> we can possibly make it.  Just how many times do you think that we  
> will replace all implementations?
> 
> This change is simply fundamental to the way the Internet works.   
> There is almost as much pain associated with this change as if we  
> were to change the electric outlet voltage in every single country to  
> a mutually incompatible standard.  Can you imagine power companies  
> making that change and then telling consumers to expect another such  
> change in 20 years?
> 
> To not even *attempt* to avoid future all-systems changes is nothing  
> short of negligent, IMHO.
> 
> 
> > Of course, if we can't get PI address space for enterprises and real
> > multihoming, there won't be any real IPv6 deployment. Lots of  
> > (possibly
> > illegitimate) IPv4 trading and NAT, but not IPv6.
> >
> > These aren't nice to haves. Even if it shortens the life of IPv6,  
> > that is an
> > acceptable trade-off.
> >
> > IPv6 is not the Last Protocol.
> 
> 
> If you do get PI space for multihoming, then by definition, it cannot  
> be the last protocol.  In fact, it will have cemented v6's lifetime  
> as just 10 more years.
> 
> Tony
> 

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Fred Baker]

On Oct 17, 2005, at 2:24 PM, Tony Li wrote:
To not even *attempt* to avoid future all-systems changes is  
nothing short of negligent, IMHO.



On Oct 17, 2005, at 2:17 PM, Randy Bush wrote:

and that is what the other v6 ivory tower crew said a decade ago.
which is why we have the disaster we have now.


and there I would agree, on both points.

now, the proposal put forward lo these many moons ago to avoid any  
possibility of a routing change was, as I recall, Nimrod, and the  
Nimrod architecture called for variable length addresses in the  
network layer protocol and the use of a flow label (as in "IPv6 flow  
label") as a short-form address in some senses akin to a virtual  
circuit ID. There has been a lot of work on that in rrg among other  
places, but the word from those who would deploy it has been  
uniformly "think in terms of an incremental upgrade to BGP" and  
"maybe MPLS will work as a virtual circuit ID if we really need one".


As you no doubt recall all too well, the variable length address was  
in fact agreed on at one point, but that failed for political  
reasons. Something about OSI. The 16 byte length of an IPv6 address  
derived from that as well - it didn't allow one to represent an NSAP  
in IPv6, which was an objective.


So the routing problem was looked at, and making a fundamental  
routing change was rejected by both the operational community and the  
routing folks.


No, IPv6 doesn't fix (or even change) the routing of the system, and  
that problem will fester until it becomes important enough to change.  
But lets not blame that on the "ivory tower folks", at least not  
wholly. We were all involved.

Re: IPv6 news

[Mark Smith]

On Mon, 17 Oct 2005 07:57:52 -0700
David Meyer <[EMAIL PROTECTED]> wrote:

> On Sun, Oct 16, 2005 at 01:45:40AM -0700, Tony Li wrote:
> > 
> > >

> > 
> > This is probably the most common misunderstanding of the end-to-end  
> > principle out there.  Someone else can dig up the quote, but  
> > basically, the principle says that the network should not replicate  
> > functionality that the hosts already have to perform.  You have to  
> > look at X.25's hop-by-hop data windows to truly grok this point.
> > 
> > Many people pick this up and twist it into ~the network has to be  
> > application agnostic~ and then use this against NATs or firewalls,  
> > which is simply a misuse of the principle.  Really, this is a  
> > separate principle in and of its own right.  It's not one that I  
> > subscribe to, but that's a different conversation...
> 
>   Maybe its time to pull out some of Noel's work on both
>   topics. Reasonable introductions to both the e2e
>   principle and locator/id split topics can be found on 
> 
> http://users.exis.net/~jnc/tech/end_end.html and
> http://users.exis.net/~jnc/tech/endpoints.txt
> 

Tony is right, thinking about it a bit more, I've mixed the two
together. I first came across the end-to-end argument (the "X.25"
example) in "Routing In the Internet". The other stuff (as well as e2e)
was in RFC1958, "Architectural Principles of the Internet", and a few
other places.

I see value in getting rid of NAT and firewalls (protecting host based
functions) out of the network because I've been burned by NAT on a few
occasions (due to its stateful nature, due to its lack of application
protocol support, due to its complexity when public address space would
have been a simpler and cheaper solution), and with hosts starting to
have multiple interfaces i.e. wired and wireless, it makes sense to me
that firewalling on the host itself is a better way to protect them,
rather than relying on a network topology located firewall that only
protects against attacks coming upstream from the firewall. We've
already pretty much evolved to the host based firewalling model anyway,
with all major desktop/server OSes coming out of the box already with
one. I think the major component missing is scalable policy deployment,
although I've been told that they are being developed as well.

I'm practical about NATs and network-located firewalls though, and
although I don't necessarily like doing it much, will suggest the
"conventional" NAT/firewall models/solutions when necessary.


Regards,
Mark.

-- 

The Internet's nature is peer to peer.

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Fred Baker]

we agree that at least initially every prefix allocated should belong  
to a different AS (eg, no AS gets more than one); the fly in that is  
whether there is an ISP somewhere that is so truly large that it  
needs two super-sized blocks. I don't know if such exists, but one  
hopes it is very much the exception.


The question is "does every AS get a prefix". Under current rules,  
most AS's assigned to edge networks to support multihoming will not  
get a prefix. I personally think that's probably the wrong answer  
(eg, you and I seem to agree on PI space for networks that would  
warrant an AS number does to size, connectivity, and use of BGP to  
manage their borders), but it is the current answer.


On Oct 17, 2005, at 2:06 PM, Per Heldal wrote:

The RIRs have been trying pretty hard to make IPv6 allocations be  
one prefix per ISP, with truly large edge networks being treated  
as functionally equivalent to an ISP (PI addressing without  
admitting it is being done). Make the bald assertion that this is  
equal to one prefix per AS (they're not the same statement at all,  
but the number of currently assigned AS numbers exceeds the number  
of prefixes under discussion, so in my mind it makes a reasonable  
thumb-in-the-wind- guesstimate), that is a reduction of the  
routing table size by an order of magnitude.


I wouldn't even characterise that as being bald. Initial  
allocations of more than one prefix per AS should not be allowed.  
Further; initial allocations should differentiate between network  
of various sizes into separate address-blocks to simplify and  
promote strict prefix-filtering policies. Large networks may make  
arrangements with their neighbors to honor more specifics, but that  
shouldn't mean that the rest of the world should accept those.

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Tony Li]

Daniel,


If we're going to put the world thru the pain of change, it seems
that we should do our best to ensure that it never, ever has to
happen again.


That's the goal here? To ensure we'll never have another protocol
transition? I hope you realize what a flawed statement that is. We  
can't see
into the future. However, assuming that IPv6 is the Last Protocol  
seems a
bit short sighted. If we get 20 years out of IPv6, that will be  
just peachy.



I see that as a worthy goal and no, I don't see that as flawed.   
While we certainly cannot guarantee that v6 will be the last  
protocol, we should certainly be designing for it to be the best that  
we can possibly make it.  Just how many times do you think that we  
will replace all implementations?


This change is simply fundamental to the way the Internet works.   
There is almost as much pain associated with this change as if we  
were to change the electric outlet voltage in every single country to  
a mutually incompatible standard.  Can you imagine power companies  
making that change and then telling consumers to expect another such  
change in 20 years?


To not even *attempt* to avoid future all-systems changes is nothing  
short of negligent, IMHO.




Of course, if we can't get PI address space for enterprises and real
multihoming, there won't be any real IPv6 deployment. Lots of  
(possibly

illegitimate) IPv4 trading and NAT, but not IPv6.

These aren't nice to haves. Even if it shortens the life of IPv6,  
that is an

acceptable trade-off.

IPv6 is not the Last Protocol.



If you do get PI space for multihoming, then by definition, it cannot  
be the last protocol.  In fact, it will have cemented v6's lifetime  
as just 10 more years.


Tony

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Daniel Senie]

At 04:51 PM 10/17/2005, Tony Li wrote:



Fred,


If we are able to reduce the routing table size by an order of
magnitude, I don't see that we have a requirement to fundamentally
change the routing technology to support it. We may *want* to (and
yes, I would like to, for various reasons), but that is a different
assertion.



There is a fundamental difference between a one-time reduction in the
table and a fundamental dissipation of the forces that cause it to
bloat in the first place.  Simply reducing the table as a one-off
only buys you linearly more time.  Eliminating the drivers for bloat
buys you technology generations.

If we're going to put the world thru the pain of change, it seems
that we should do our best to ensure that it never, ever has to
happen again.


But wasn't that the rationale for originally putting the kitchen sink 
into IPv6, rather than fixing the address length issue? I think we 
missed a lot of opportunities. Extended addressing may well have been 
possible to integrate in the mid 1990's ahead of much of the massive 
Internet expansion. Too late.


We're 10 years on, and talking about whether there will need to be 
more than one massive pain of migration, because the kitchen sink 
didn't take into account multihoming. Now we're talking about a 
solution that appear to be an even worse Rube Goldberg than token 
ring source-route bridging. Moore will likely have to continue to 
produce the solution. 

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Randy Bush]

>> There is a fundamental difference between a one-time reduction in the
>> table and a fundamental dissipation of the forces that cause it to
>> bloat in the first place.  Simply reducing the table as a one-off
>> only buys you linearly more time.  Eliminating the drivers for bloat
>> buys you technology generations.
>> 
>> If we're going to put the world thru the pain of change, it seems
>> that we should do our best to ensure that it never, ever has to
>> happen again.
> 
> That's the goal here? To ensure we'll never have another protocol
> transition? I hope you realize what a flawed statement that is.

tony probably did not think about it because that's not what he
said at all.  he was speaking of routing table bloat, not 
transitions.

and he was spot on.

randy

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Randy Bush]

> works for me - I did say I'd like to change the routing protocol -  
> but I think the routing protocol can be changed asynchronously, and  
> will have to.

and that is what the other v6 ivory tower crew said a decade ago.
which is why we have the disaster we have now.

randy

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Per Heldal]

It doesn't look like were talking about the same thing.

A. Address conservation and aggregation (IPv4 and IPv6) is very
important to get the most out of what we've got. Read; limit the
combined routing-table to a manageable size whatever that may be.

B. There seems to be widespread fear that the global routing-table will
grow to a non-manageable size sooner or later regardless of the efforts
under A. So the limit has to be removed.

What you address below mostly belong under A (and I mostly agree),
whereas I so far have focused on B.


On Mon, 2005-10-17 at 13:12 -0700, Fred Baker wrote:
> That is an assumption that I haven't found it necessary to make. I  
> have concluded that there is no real debate about whether the  
> Internet will have to change to something that gives us the ability  
> to directly address (e.g. not behind a NAT, which imposes some  
> "interesting" requirements at the application layer and gateways of  
> the sort which were what the Internet came about to not need) a whole  
> lot more things than it does today. The debate is about how and when.  
> "when" seems pretty solidly in the 3-10 year timeframe, exactly where  
> in that timeframe being a point of some discussion, and "how" comes  
> down to a choice of "IPv6" or "something else".

Sure, something has to replace IPv4 sooner or later and IPv6 is almost
certainly the thing. Personally I belive the most trustworthy
projections points towards 2010 as the time we'll run out of addresses
in V4 with an additional 2-3 years if we can manage to reclaim up to 90%
of those previously allocated addressblocks which are not used or not
announced to the public internet.

> 
> Fleming's IPv8 was a non-stupid idea that has a fundamental flaw in  
> that it re-interprets parts of the IPv4 header as domain identifiers  
> - it effectively extends the IP address by 16 bits, which is good,  
> but does so in a way that is not backward compatible. If we could  
> make those 16 bits be AS numbers (and ignoring for the moment the  
> fact that we seem to need larger AS numbers), the matter follows  
> pretty quickly. If one is going to change the header, though, giving  
> up fragmentation as a feature sees a little tough; one may as well  
> change the header and manage to keep the capability. One also needs  
> to change some other protocols, such as routing AS numbers and  
> including them in DNS records as part of the address.

For the record: You brought up IPv8. Nothing of what I've mentioned
requires any change to transport protocols wether implemented on top of
IPv4 or 6.

> 
>  From my perspective, we are having enough good experience with IPv6  
> that we should simply choose that approach; there isn't a real good  
> reason to find a different one. Yes, that means there is a long  
> coexistence period yada yada yada. This is also true of any other  
> fundamental network layer protocol change.
> 
> The RIRs have been trying pretty hard to make IPv6 allocations be one  
> prefix per ISP, with truly large edge networks being treated as  
> functionally equivalent to an ISP (PI addressing without admitting it  
> is being done). Make the bald assertion that this is equal to one  
> prefix per AS (they're not the same statement at all, but the number  
> of currently assigned AS numbers exceeds the number of prefixes under  
> discussion, so in my mind it makes a reasonable thumb-in-the-wind- 
> guesstimate), that is a reduction of the routing table size by an  
> order of magnitude.

I wouldn't even characterise that as being bald. Initial allocations of
more than one prefix per AS should not be allowed. Further; initial
allocations should differentiate between network of various sizes into
separate address-blocks to simplify and promote strict prefix-filtering
policies. Large networks may make arrangements with their neighbors to
honor more specifics, but that shouldn't mean that the rest of the world
should accept those.
> 
> If we are able to reduce the routing table size by an order of  
> magnitude, I don't see that we have a requirement to fundamentally  
> change the routing technology to support it. We may *want* to (and  
> yes, I would like to, for various reasons), but that is a different  
> assertion.

Predictions disagree. 


//Per

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Fred Baker]

works for me - I did say I'd like to change the routing protocol -  
but I think the routing protocol can be changed asynchronously, and  
will have to.


On Oct 17, 2005, at 1:51 PM, Tony Li wrote:



Fred,


If we are able to reduce the routing table size by an order of  
magnitude, I don't see that we have a requirement to fundamentally  
change the routing technology to support it. We may *want* to (and  
yes, I would like to, for various reasons), but that is a  
different assertion.





There is a fundamental difference between a one-time reduction in  
the table and a fundamental dissipation of the forces that cause it  
to bloat in the first place.  Simply reducing the table as a one- 
off only buys you linearly more time.  Eliminating the drivers for  
bloat buys you technology generations.


If we're going to put the world thru the pain of change, it seems  
that we should do our best to ensure that it never, ever has to  
happen again.


Regards,
Tony

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Daniel Golding]

On 10/17/05 4:51 PM, "Tony Li" <[EMAIL PROTECTED]> wrote:
> Fred,
> 
>> If we are able to reduce the routing table size by an order of
>> magnitude, I don't see that we have a requirement to fundamentally
>> change the routing technology to support it. We may *want* to (and
>> yes, I would like to, for various reasons), but that is a different
>> assertion.
> 
> 
> There is a fundamental difference between a one-time reduction in the
> table and a fundamental dissipation of the forces that cause it to
> bloat in the first place.  Simply reducing the table as a one-off
> only buys you linearly more time.  Eliminating the drivers for bloat
> buys you technology generations.
> 
> If we're going to put the world thru the pain of change, it seems
> that we should do our best to ensure that it never, ever has to
> happen again.

That's the goal here? To ensure we'll never have another protocol
transition? I hope you realize what a flawed statement that is. We can't see
into the future. However, assuming that IPv6 is the Last Protocol seems a
bit short sighted. If we get 20 years out of IPv6, that will be just peachy.

Of course, if we can't get PI address space for enterprises and real
multihoming, there won't be any real IPv6 deployment. Lots of (possibly
illegitimate) IPv4 trading and NAT, but not IPv6.

These aren't nice to haves. Even if it shortens the life of IPv6, that is an
acceptable trade-off.

IPv6 is not the Last Protocol.

> 
> Regards,
> Tony
> 

Dan

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Tony Li]

Fred,

If we are able to reduce the routing table size by an order of  
magnitude, I don't see that we have a requirement to fundamentally  
change the routing technology to support it. We may *want* to (and  
yes, I would like to, for various reasons), but that is a different  
assertion.



There is a fundamental difference between a one-time reduction in the  
table and a fundamental dissipation of the forces that cause it to  
bloat in the first place.  Simply reducing the table as a one-off  
only buys you linearly more time.  Eliminating the drivers for bloat  
buys you technology generations.


If we're going to put the world thru the pain of change, it seems  
that we should do our best to ensure that it never, ever has to  
happen again.


Regards,
Tony

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Fred Baker]

That is an assumption that I haven't found it necessary to make. I  
have concluded that there is no real debate about whether the  
Internet will have to change to something that gives us the ability  
to directly address (e.g. not behind a NAT, which imposes some  
"interesting" requirements at the application layer and gateways of  
the sort which were what the Internet came about to not need) a whole  
lot more things than it does today. The debate is about how and when.  
"when" seems pretty solidly in the 3-10 year timeframe, exactly where  
in that timeframe being a point of some discussion, and "how" comes  
down to a choice of "IPv6" or "something else".


Fleming's IPv8 was a non-stupid idea that has a fundamental flaw in  
that it re-interprets parts of the IPv4 header as domain identifiers  
- it effectively extends the IP address by 16 bits, which is good,  
but does so in a way that is not backward compatible. If we could  
make those 16 bits be AS numbers (and ignoring for the moment the  
fact that we seem to need larger AS numbers), the matter follows  
pretty quickly. If one is going to change the header, though, giving  
up fragmentation as a feature sees a little tough; one may as well  
change the header and manage to keep the capability. One also needs  
to change some other protocols, such as routing AS numbers and  
including them in DNS records as part of the address.


From my perspective, we are having enough good experience with IPv6  
that we should simply choose that approach; there isn't a real good  
reason to find a different one. Yes, that means there is a long  
coexistence period yada yada yada. This is also true of any other  
fundamental network layer protocol change.


The RIRs have been trying pretty hard to make IPv6 allocations be one  
prefix per ISP, with truly large edge networks being treated as  
functionally equivalent to an ISP (PI addressing without admitting it  
is being done). Make the bald assertion that this is equal to one  
prefix per AS (they're not the same statement at all, but the number  
of currently assigned AS numbers exceeds the number of prefixes under  
discussion, so in my mind it makes a reasonable thumb-in-the-wind- 
guesstimate), that is a reduction of the routing table size by an  
order of magnitude.


If we are able to reduce the routing table size by an order of  
magnitude, I don't see that we have a requirement to fundamentally  
change the routing technology to support it. We may *want* to (and  
yes, I would like to, for various reasons), but that is a different  
assertion.


On Oct 17, 2005, at 12:42 PM, Per Heldal wrote:


mon, 17,.10.2005 kl. 11.29 -0700, Fred Baker:

OK. What you just described is akin to an enterprise network with  
a  default route. It's also akin to the way DNS works.


No default, just one or more *potential* routes.

Your input is appreciated, and yes I'm very much aware that many  
people who maintain solutions that assume full/total control of the  
entire routing-table will be screaming bloody murder if that is  
going to change. Further details about future inter-domain-routing  
concepts belong in other fora (e.g. ietf's inter-domain-routing wg).


The long-term operational impact is that the current inter-domain- 
routing concepts (BGP etc) don't scale indefinitely and will have  
to be changed some time in the future. Thus expect the size of the  
routing-table to be eliminated from the list of limiting factors,  
or that the bar is considerably raised.


---

Note that I'm not saying that nothing should be done to preserve  
and optimise the use of the resources that are available today just  
because there will be something better available in a distant  
future. I'm in favor of the most restrictive allocation policies in  
place today. The development of the internet has for a long time  
been based on finding better ways to use available resources (CIDR  
anyone). To me a natural next-step in that process is for RIR's to  
start reclaiming unused v4 address-blocks, or at least start  
collect data to document that space is not being used (if they're  
not already doing so). E.g prevously announced address-blocks that  
has disappeared from the global routing-table for more than X  
months should go back to the RIR-pool (X<=6).



//Per

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Randy Bush]

> --bill (checking citesear...)

does that only yield rare papers :-)

and citeseer does not have the paper, only a few cites to it

randy

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Randy Bush]

>> check out "The Landmark Hierarchy: A New Hierarchy for Routing in Very
>> Large Networks"; Paul Tsuchiya; 1989.
> great stuff... i have a hardcopy. is it online yet?

dunno if i would say great.  but certainly good.



randy

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Per Heldal]

mon, 17,.10.2005 kl. 11.29 -0700, Fred Baker:
> OK. What you just described is akin to an enterprise network with a  
> default route. It's also akin to the way DNS works.

No default, just one or more *potential* routes.

Your input is appreciated, and yes I'm very much aware that many people
who maintain solutions that assume full/total control of the entire
routing-table will be screaming bloody murder if that is going to
change. Further details about future inter-domain-routing concepts
belong in other fora (e.g. ietf's inter-domain-routing wg).

The long-term operational impact is that the current
inter-domain-routing concepts (BGP etc) don't scale indefinitely and
will have to be changed some time in the future. Thus expect the size of
the routing-table to be eliminated from the list of limiting factors, or
that the bar is considerably raised. 

---

Note that I'm not saying that nothing should be done to preserve and
optimise the use of the resources that are available today just because
there will be something better available in a distant future. I'm in
favor of the most restrictive allocation policies in place today. The
development of the internet has for a long time been based on finding
better ways to use available resources (CIDR anyone). To me a natural
next-step in that process is for RIR's to start reclaiming unused v4
address-blocks, or at least start collect data to document that space is
not being used (if they're not already doing so). E.g prevously
announced address-blocks that has disappeared from the global
routing-table for more than X months should go back to the RIR-pool
(X<=6).

//Per

Re: And Now for Something Completely Different (was Re: IPv6 news)

[bmanning]

On Mon, Oct 17, 2005 at 09:03:45AM -1000, Randy Bush wrote:
> 
> > Imagine a situation with no access to any means of direct communication
> > (phone etc). You've got a message to deliver to some person, and have no
> > idea where to find that person. Chances are there's a group of people
> > nearby you can ask. They may know how to find the one you're looking
> > for. If not they may know others they can ask on your behalf. Several
> > iterations later the person is located and you've established a path
> > through which you can pass the information you wanted.
> > 
> > Translated into cisco terms this mean that the FIB is just a partial
> > routing database, enough to start the search and otherwise handle
> > communications in the neighborhood (no more than X router-hops, maybe
> > AS-hops away). When the destination is located you keep that information
> > for a while in case there are more packets going to the same place,
> > similar to what you do with traditional route-cache.
> 
> check out "The Landmark Hierarchy: A New Hierarchy for Routing in Very Large
> Networks"; Paul Tsuchiya; 1989.

great stuff... i have a hardcopy. is it online yet?

--bill (checking citesear...)

> 
> randy

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Randy Bush]

> Imagine a situation with no access to any means of direct communication
> (phone etc). You've got a message to deliver to some person, and have no
> idea where to find that person. Chances are there's a group of people
> nearby you can ask. They may know how to find the one you're looking
> for. If not they may know others they can ask on your behalf. Several
> iterations later the person is located and you've established a path
> through which you can pass the information you wanted.
> 
> Translated into cisco terms this mean that the FIB is just a partial
> routing database, enough to start the search and otherwise handle
> communications in the neighborhood (no more than X router-hops, maybe
> AS-hops away). When the destination is located you keep that information
> for a while in case there are more packets going to the same place,
> similar to what you do with traditional route-cache.

check out "The Landmark Hierarchy: A New Hierarchy for Routing in Very Large
Networks"; Paul Tsuchiya; 1989.

randy

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Per Heldal]

man, 17,.10.2005 kl. 19.16 +0200, skrev Peter Dambier:
> That reminds me of anycasting or routing issues.
> 
> Hackers did use this technique to make use of ip addresses not
> really allocated. There would be no need for IPv6 if this was
> more widespread.
> 
> How about claiming to be f.root-servers.net and setting up our
> own root :)

Yeah, you'd love that, wouldn't you? ;)

Trust that security considerations would be an important part of the
design of any replacement for current routing protocols.

//Per

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Per Heldal]

man, 17,.10.2005 kl. 15.47 +, skrev Mikael Abrahamsson:
> On Mon, 17 Oct 2005, Per Heldal wrote:
> 
> > Well, let's try to turn the problem on its head and see if thats
> > clearer; Imagine an internet where only your closest neighbors know you
> > exist. The rest of the internet knows nothing about you, except there
> > are mechanisms that let them "track you down" when necessary. That is
> > very different from today's full-routing-table.
> 
> Yes, it's true that it's different, but is it better?

This thread, as well as most messages on this mailinglist in the last 2
days says so. Everyone uses all their energy trying to work within the
limits of the current scheme. Common sense says it would be to eliminate
the problem. What happens to policies if there's no limit to the size of
the routing-table?

> 
> > It does not provide 100% provider-indepence to begin with. Depending on
> > who you ask that alone is a show-stopper.
> 
> Well, the reason for people wanting to stick to their "own" IP adresses 
> are administrative and technical. If we solve that then hopefully, it wont 
> be such a big hassle to renumber to go to another provider.

I'm not so sure it will be that easy to get the flexibility you want.
How do you for example enforce rules of flexibilty on *all*
dns-providers.

> 
> Also, if everybody got their equal size subnet delegation from each ISP 
> then it shouldnt be that much of a problem to run two "networks" 
> side-by-side by using the subnet part of the delegation equal to both 
> networks, but keep the prefix separate. If you switch providers you change 
> the prefix part. This means we need new mechanisms to handle this, but I 
> feel that's better than doing the routing mistake again.

True, but it creates unnecessary complexity for end-systems. It still
doesn't help for scaleability on the next level up.

> 
> > The internet shouldn't need to know anything about individual users to
> > begin with, provided there are mechanisms avilable track them down. By
> > that I mean that algorithms to locate end-nodes may include mechanisms
> > to "interrogate" a large number of nodes to find the desired location as
> > opposed to looking it up in a locally stored database (routing-table).
> 
> So what is it you're proposing? I understand what shim6 tries to do (since 
> it basically keeps most of todays mechanisms) but I do not understand your 
> proposal. Could you please elaborate?

What I've got can't be called a proposal. There's no solution to
propose. I just think that network complexity should be handled in the
network and not by exporting the problem to connected clients. BGP and
its related path-selection algorithms have served us well for many
years, but there's a need for alternatives and somebody have to get
involved. 

> 
> > I thought DNS only provided a name for an address ;) How does DNS tell
> > us that e.g. 193.10.6.6 is part of a subnet belonging to AS2838 and how
> > to get there?
> 
> Should end users really care for that level of routing information? 

I never said so. Their equipment, their upstream, or the upstream's
upstream may need to know to get there though.

> 
> Also, your proposal seems to indicate that we need something that sounds 
> like a proxy server that actually do know more about the internet and who 
> needs to keep state, this doesn't sound scalable?

There's no proxy server involved unless you count forwarding of route
location requests between inter-domain routers as proxy. If so, all
intra-domain routers would be proxies. Data transport along an
established forwarding path would not change. 

This mailinglist isn't really the place to discuss future concepts and
further discussion should move to the IETF Inter-Domain-Routing
working-group or other suitable forum. 

//Per

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Fred Baker]

OK. What you just described is akin to an enterprise network with a  
default route. It's also akin to the way DNS works.


The big question becomes not only "who knows what I need to know",  
but "how do I know that they actually know it?". For example, let's  
postulate that the concept is that each ISP advertises some sort of  
routing service that will install routes on demand, but requires that  
someone initiate a request for the route, and requires either the  
target system or the edge router in that domain that is closest to  
the target respond with a route.


Simplistically, perhaps I am trying to route from my edge network  
("A") towards your edge network ("B"), and we are both customers of  
some ISP ("C"). The host A' that is trying to get to your host B'  
initiates a request. Lets presume that this goes to some name in  
domain A that lists all border routers, or some multicast group that  
they are members of. Presumably every border router does this, but  
for present discussion the border router in A connecting to router C'  
in C asks all of his peers (POPs?) for the route, and some other  
router C" asks B's border router. B's border router has the route,  
and so replies; C" replies to C', C' to A's border router, and that  
router to A'. A' can now send a message.


Presumably, if someone else now ask C about the route, either C' or  
C", or if the route was multicast to all of C's edge routers then any  
router in C would be able to respond directly.


This becomes more interesting if C is in fact a succession of peer  
ISPs or ISPs that purchase transit from other ISPs. It also becomes  
very interesting if some router D' is misconfigured to advertise  
itself as B.


It's not dissimilar to ant routing. For that, there is a variety of  
literature; Google is your friend. In manet and sensor networks, it  
works pretty well, especially in the sense that once it finds a route  
it keeps using it while it continues working even if other routes are  
changing around it, and it can use local repair to deal with local  
changes.


At least as the researchers have described it, it doesn't do "policy"  
very well, and in networks that tend to be stable (such as wired  
networks) its load and convergence properties can be improved on.


I'll let you read there.


On Oct 17, 2005, at 9:20 AM, Per Heldal wrote:


man, 17,.10.2005 kl. 07.25 -0700, skrev Fred Baker:


is that anything like using, in Cisco terms, a "fast-switching cache"
vs a "FIB"?



I'll bite as I wrote the paragraph you're quoting;

Actually, hanging on to the old concepts may be more confusing than
trying to look at it in completely new ways.

Imagine a situation with no access to any means of direct  
communication
(phone etc). You've got a message to deliver to some person, and  
have no

idea where to find that person. Chances are there's a group of people
nearby you can ask. They may know how to find the one you're looking
for. If not they may know others they can ask on your behalf. Several
iterations later the person is located and you've established a path
through which you can pass the information you wanted.

Translated into cisco terms this mean that the FIB is just a partial
routing database, enough to start the search and otherwise handle
communications in the neighborhood (no more than X router-hops, maybe
AS-hops away). When the destination is located you keep that  
information

for a while in case there are more packets going to the same place,
similar to what you do with traditional route-cache.




On Oct 17, 2005, at 6:47 AM, Mikael Abrahamsson wrote:


Well, let's try to turn the problem on its head and see if thats
clearer; Imagine an internet where only your closest neighbors
know you exist. The rest of the internet knows nothing about you,
except there are mechanisms that let them "track you down" when
necessary. That is very different from today's full-routing-table.

Re: IPv6 news

[Christopher L. Morrow]

On Mon, 17 Oct 2005 [EMAIL PROTECTED] wrote:
> > I'm not sure I agree that the end state is 100% multihoming. I can
> > certainly agree that more multihoming is coming. Many more people are
> > pushing for multihoming today than in previous years, apparently telco
> > instability (financial not technical) is/has driven this :) (among other
> > things I'm sure)
>
> I agree that the end state is *NOT* 100% multihoming. It is
> too complex for most people and there is no business
> justification for it. But an awful lot of business customers
> will be able to justify multihoming. That is part and parcel
> of the "mission critical" Internet.

It'd be interesting to see how many 'providers' can't qualify for a /32
and will have multihomed in v6 and will thus have more than 1 /48 assigned
and thus more than 1 /64 per customer... Say someone like Covad or Rythyms
or perhaps even a cable-isp? In these instances each consumer will
actually be multihomed, yes? The complexity just landed on your
grandmama's doorstep.

-Chris

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Peter Dambier]

That reminds me of anycasting or routing issues.

Hackers did use this technique to make use of ip addresses not
really allocated. There would be no need for IPv6 if this was
more widespread.

How about claiming to be f.root-servers.net and setting up our
own root :)


Regards,
Peter and Karin Dambier



>is that anything like using, in Cisco terms, a "fast-switching cache"
>vs a "FIB"?

On Oct 17, 2005, at 6:47 AM, Mikael Abrahamsson wrote:
Well, let's try to turn the problem on its head and see if thats  
clearer; Imagine an internet where only your closest neighbors  
know you exist. The rest of the internet knows nothing about you,  
except there are mechanisms that let them "track you down" when  
necessary. That is very different from today's full-routing-table.

Re: IPv6 news

[Gary E. Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yo Michael!

On Mon, 17 Oct 2005, [EMAIL PROTECTED] wrote:

> Here, the suggestion is that netblocks should
> be allocated to cities, not to providers. Within
> a city, providers would get a subset of the city
> address block to meet their local infrastructure
> needs. They would interconnect with each other
> a local exchange points to exchange local traffic

And who is going to force the ISPs to interconnect at the city level?
For competitive reasons there is no peering in my city.  The nearest
peering points are several hundred miles away, in different directions,
and even those are not shared in common by the local ISPs.

RGDS
GARY
- ---
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
[EMAIL PROTECTED]  Tel:+1(541)382-8588 Fax: +1(541)382-8676
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDU9eq8KZibdeR3qURAnBfAKC4ZBCUrGq9HgW80FJxIGqfbR7mowCgi4GD
ykujmYnq/FPv6MA1nKdf49A=
=aUG/
-END PGP SIGNATURE-

The exhaustion of IPv4 address space

[Vicky Rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

well, if the existing discussion is not enough, cisco has an interesting
article out...see /. for more information.

http://www.cisco.com/en/US/about/ac123/ac147/archived_issues/ipj_8-3/ipv4.html


wearing my flame suite :-)

regards,
/virendra
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDU9cKpbZvCIJx1bcRAoNWAKC5UUyUqfPcAEKJ8GX5Iky2y1qbxwCeMdUM
TkjJ1xoc4NK+y8Bv3YnZCjU=
=kVtG
-END PGP SIGNATURE-

Re: shim6 (was Re: IPv6 news)

[Bill Woodcock]

  On Mon, 17 Oct 2005, Tony Li wrote:
> CIDR also changed allocation policies and created the notions of PA and PI
> space.

Hm.  I guess I never thought of them as being causally related.  And I 
remember the whole "portable/non-portable" issue as predating CIDR...  I 
(perhaps mistakenly) remember having had that argument with customers when 
we were still knocking Cs for them out of our service-provision Bs...

-Bill

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Tony Li]

Paul,

This is completely orthogonal to a real identifier/locator split,  
which would divide what we know of as the 'address' into two  
separate spaces, one which says "where" the node is,  
topologically, and one which says "who" the node is.


Hmm, no idea whether it's a good idea or not, but from POV of  
scaling while it might make 'where' scaleable, you still have to  
find a way to tie "who" to "where".



True.  Even better, you get to change this binding (mobility) or have  
multiple bindings (multihoming).




Some might say we already have this split though, DNS.



True enough, but unfortunately, it's not done in a way that we can  
make use of the identifier in the routing subsystem or in the  
transport protocols.


Tony

Re: shim6 (was Re: IPv6 news)

[Tony Li]

...the necessary evil called CIDR.  evil because it locked customers
into their providers, entrenched the existing large providers
against future providers, and made it hard or impossible for the
average endusing company to multihome.


Uh, perhaps I'm being dense, but how does moving masking off byte
boundaries have any of the above effects?



Bill,

CIDR also changed allocation policies and created the notions of PA  
and PI space.


Tony

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Per Heldal]

man, 17,.10.2005 kl. 07.25 -0700, skrev Fred Baker:
> is that anything like using, in Cisco terms, a "fast-switching cache"  
> vs a "FIB"?

I'll bite as I wrote the paragraph you're quoting; 

Actually, hanging on to the old concepts may be more confusing than
trying to look at it in completely new ways.

Imagine a situation with no access to any means of direct communication
(phone etc). You've got a message to deliver to some person, and have no
idea where to find that person. Chances are there's a group of people
nearby you can ask. They may know how to find the one you're looking
for. If not they may know others they can ask on your behalf. Several
iterations later the person is located and you've established a path
through which you can pass the information you wanted.

Translated into cisco terms this mean that the FIB is just a partial
routing database, enough to start the search and otherwise handle
communications in the neighborhood (no more than X router-hops, maybe
AS-hops away). When the destination is located you keep that information
for a while in case there are more packets going to the same place,
similar to what you do with traditional route-cache.

> 
> On Oct 17, 2005, at 6:47 AM, Mikael Abrahamsson wrote:
> >> Well, let's try to turn the problem on its head and see if thats  
> >> clearer; Imagine an internet where only your closest neighbors  
> >> know you exist. The rest of the internet knows nothing about you,  
> >> except there are mechanisms that let them "track you down" when  
> >> necessary. That is very different from today's full-routing-table.

Re: shim6 (was Re: IPv6 news)

[Bill Woodcock]

  On Sat, 15 Oct 2005, Paul Vixie wrote:
> ...the necessary evil called CIDR.  evil because it locked customers 
> into their providers, entrenched the existing large providers 
> against future providers, and made it hard or impossible for the 
> average endusing company to multihome.

Uh, perhaps I'm being dense, but how does moving masking off byte 
boundaries have any of the above effects?

-Bill

Re: IPv6 news

[David Meyer]

On Sun, Oct 16, 2005 at 01:45:40AM -0700, Tony Li wrote:
> 
> >
> >Doesn't NAT, or more specifically the most commonly used, NAPT, create
> >hard state within the network, which then makes it violate the
> >end-to-end argument ? Also, because it has to understand transport and
> >application layer protocols, to be able to translate embedded  
> >addresses,
> >doesn't this also make it violate end-to-end ? I've understood the
> >fundamental benefit of following the end-to-end argument is that  
> >you end
> >up with a application agnostic network, which therefore doesn't create
> >future constraints on which applications can then be used over that
> >network. In an end-to-end "compliant" network, any new transport layer
> >protocols, such as SCTP or DCCP, and new user applications, only  
> >require
> >an upgrade of the end or edge node software, which can be performed in
> >an incremental, per edge node as needed basis. In other words, there
> >isn't any whole of network upgrade cost or functionality deployment
> >delay to support new applications, which was the drawback of  
> >application
> >specific networks, such as the traditional POTS network.
> >
> >Have I somehow misunderstood the intent or benefits of the end-to-end
> >argument ?
> 
> 
> Mark,
> 
> This is probably the most common misunderstanding of the end-to-end  
> principle out there.  Someone else can dig up the quote, but  
> basically, the principle says that the network should not replicate  
> functionality that the hosts already have to perform.  You have to  
> look at X.25's hop-by-hop data windows to truly grok this point.
> 
> Many people pick this up and twist it into ~the network has to be  
> application agnostic~ and then use this against NATs or firewalls,  
> which is simply a misuse of the principle.  Really, this is a  
> separate principle in and of its own right.  It's not one that I  
> subscribe to, but that's a different conversation...

Maybe its time to pull out some of Noel's work on both
topics. Reasonable introductions to both the e2e
principle and locator/id split topics can be found on 

  http://users.exis.net/~jnc/tech/end_end.html and
  http://users.exis.net/~jnc/tech/endpoints.txt

respectively. 

Dave


pgpA3Ia5xQxIC.pgp
Description: PGP signature

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Fred Baker]

is that anything like using, in Cisco terms, a "fast-switching cache"  
vs a "FIB"?


On Oct 17, 2005, at 6:47 AM, Mikael Abrahamsson wrote:
Well, let's try to turn the problem on its head and see if thats  
clearer; Imagine an internet where only your closest neighbors  
know you exist. The rest of the internet knows nothing about you,  
except there are mechanisms that let them "track you down" when  
necessary. That is very different from today's full-routing-table.

Re: IPv6 news

[Michael . Dillon]

> so, if we had a free hand and ignored the dogmas, what would we
> change about the v6 architecture to make it really deployable
> and scalable and have compatibility with and a transition path
> from v4 without massive kludging, complexity, and long term
> cost?

Isn't that GENI already out of the bottle?
http://www.nsf.gov/cise/geni/
http://www.ana.lcs.mit.edu/papers/PDF/Rethinking_2001.pdf
http://cfp.mit.edu/docs/overview.pdf
http://cfp.mit.edu/groups/internet/internet.html

Seems like there is enough interest in this to plan something 
for NANOG 36 early next year.

--Michael Dillon

Re: IPv6 news

[Per Heldal]

man, 17,.10.2005 kl. 14.22 +0200, skrev Jeroen Massar:
> On Tue, 2005-10-18 at 01:07 +1300, Simon Lyall wrote:
> 
> > My son tells me that is what I want so I setup a payment of $5 per month
> > to him. In 10 minutes from start to finish my house's /54 is "multi-homed",
> > whatever that means.
> 
> You cover the payment part, partially. But now the fun parts:

This story may be a lot closer to reality in 2011 than you seem able to
accept. It's a mere illusion given limitations in current (2005)
routing-protocols, but those protocols may also be nothing more than a
distant memory by 2011.

>  - which prefix

Why shouldn't it be his own?

>  - where did you get the prefix

Maybe it's assigned to him?

>  - who says you are you and thus that you are allowed to use
>that prefix (someone has a working PKI available? :)

The allocating entity should be able to authorise that

>  - routing table size?

Who says everybody has to know about everybody else all the time. Maybe
it's enough to know where to go when you need to get there. (more in
other thread).

>  - is the other end of the possible communication going to
>be able to reach this prefix?

ditto

>  - will everybody accept you as being the endpoint?

Why not. As long as it is unique.

>  - what about a broken prefix 'upstream'
>(you just said your primary link goes down, thus it might
> be a misconfig 'upstream')

Yeah. There will probably be many failure modes in future networks too.

>  - insert various other "2011" stories...

... and get some vision about the future. Don't assume the world will
stop.


//Per

Re: IPv6 news

[Michael . Dillon]

> > I think we need a researcher to sit down and 
> > figure out exactly what this would look like
> > in a sample city and a sample national provider.

> especially:
> http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt
> 
> will be quite of your liking.

Not at all. This proposal is all about allocating addresses
based on country boundaries and I reject this model. The
Internet is a network of cities, not countries. The national
boundaries are completely random in technical terms, but
the cities are not random. The cities are where the people
are, where the railways and roads are, where the channels
of trade and communication begin and end.

> Which indeed seems quite reasonable. The problem with this is:
>  'who is paying for which traffic and to whom'

Customers pay for all the traffic on their link and they
pay their money to their Internet access provider. But that
is beside the point.

> Notez bien, though this solves multihoming, it doesn't solve relocation,
> thus if your company moves it has to renumber, and renumbering is no 
fun,

Not true. If a company moves across the city and connects to
a different access provider, they don't have to renumber. After
all, they are still in the same city. It just means that inside
that city, the providers will carry an additional longer prefix
in their routing tables. But the global view will be unchanged. 
In fact, the smaller global table allows for much more detail to
be carried locally, given the same constraints of RAM and processing
power in routers.

--Michael Dillon

Re: IPv6 news

[Michael . Dillon]

> > There are 437 cities of 1 million or more population. There are
> > roughly 5,000 cities of over 100,000 population. And there are
> > 3,047,000 named communities in the world. 
> > 
> > Seems to me that the number of routes in the global routing
> > table should logically be closer to 5,000 than to 3,000,000.
> 
> If there is an exchange point per city over 100,000 (the route goes to
> the IXP and then to the actual provider)... Otherwise, there is a flaw
> in your calculation.

I didn't calculate those numbers. They come from various
demographic sources. And I would expect that many of these
cities will have more than one exchange point. In fact, one
could argue that a city should have no less than 3 central
switching points for resiliency, and that major intercity
providers should have no less than three paths into each city.

However, if the addresses for everything in the city come
from a single netblock, then sites in a neighboring city
will only need one aggregate route route in the majority
of cases. Even if there are enough special cases for an
average of 5 routes per city, you still have only 25,000
global routes. It is still far from the projection of
one million routes that some people have made and it is
still less than today's routing table size.

--Michael Dillon

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Mikael Abrahamsson]

On Mon, 17 Oct 2005, Per Heldal wrote:


Well, let's try to turn the problem on its head and see if thats
clearer; Imagine an internet where only your closest neighbors know you
exist. The rest of the internet knows nothing about you, except there
are mechanisms that let them "track you down" when necessary. That is
very different from today's full-routing-table.


Yes, it's true that it's different, but is it better?


It does not provide 100% provider-indepence to begin with. Depending on
who you ask that alone is a show-stopper.


Well, the reason for people wanting to stick to their "own" IP adresses 
are administrative and technical. If we solve that then hopefully, it wont 
be such a big hassle to renumber to go to another provider.


Also, if everybody got their equal size subnet delegation from each ISP 
then it shouldnt be that much of a problem to run two "networks" 
side-by-side by using the subnet part of the delegation equal to both 
networks, but keep the prefix separate. If you switch providers you change 
the prefix part. This means we need new mechanisms to handle this, but I 
feel that's better than doing the routing mistake again.



The internet shouldn't need to know anything about individual users to
begin with, provided there are mechanisms avilable track them down. By
that I mean that algorithms to locate end-nodes may include mechanisms
to "interrogate" a large number of nodes to find the desired location as
opposed to looking it up in a locally stored database (routing-table).


So what is it you're proposing? I understand what shim6 tries to do (since 
it basically keeps most of todays mechanisms) but I do not understand your 
proposal. Could you please elaborate?



I thought DNS only provided a name for an address ;) How does DNS tell
us that e.g. 193.10.6.6 is part of a subnet belonging to AS2838 and how
to get there?


Should end users really care for that level of routing information?

Also, your proposal seems to indicate that we need something that sounds 
like a proxy server that actually do know more about the internet and who 
needs to keep state, this doesn't sound scalable?


--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Per Heldal]

man, 17,.10.2005 kl. 12.55 +, skrev Mikael Abrahamsson:
[snip]
> > MPLS on its own won't solve anything. Although MPLS has its uses,
> > it smells too much like another desperate attempt from the telco-heads
> > in the ITU crowd to make a packet-switched network look and behave like
> > a circuit-switched network.
> 
> Why? The initial argument for MPLS was that it would solve the core 
> problem and put intelligence at the edge. You would have a core that only 
> needed to know about hundreds of nodes instead of 100.000:nds of nodes.

My comment about MPLS wasn't directed specifically at this problem.
Re-encapsulation may or may not be part of a future solution. If so,
what mechanism is tbd.

A true scalable solution will equire that the problem is distributed.
Isolation of the problem in one place (core or edge) is no solution. 

> 
> > Growth can't be eliminated. In the future network you'll have routers
> > that may know a lot about their "local region" of the network but have
> > to rely on nodes that are several hops (even AS-hops) away to pass the
> > packets to more remote destinations. These trust-relationships have to
> 
> Yes, that is what's being proposed. Know your internal nodes, announce 
> single big prefix externally. With ISPs only having a single prefix and no 
> "single customer" prefixes, routing table can be kept low. Redundancy can 
> be solved with for instance shim6.

What I suggested above is not what is being proposed. Current proposals
are limited to quirks to make your network appear less complex to the
world. Ok in the short term, but doesn't scale.

Well, let's try to turn the problem on its head and see if thats
clearer; Imagine an internet where only your closest neighbors know you
exist. The rest of the internet knows nothing about you, except there
are mechanisms that let them "track you down" when necessary. That is
very different from today's full-routing-table.

> 
> > alternative. Without improved routing protocols, all we can do is to
> > pray that the development of routing hardware in terms of memory and
> > processing capability outpaces the growth of the routing table.
> 
> We have done this for 15 years or so, what good has it brought us? Yes, 
> TCAM size etc has been fairly good in keeping up with routing table size, 
> but at quite high cost.

True, but there's no law saying that current routing protocols and
path-selection algorithms have to stay unchanged forever.

> 
> > Initiatives like shim6 that changes the behaviour of leaf-nodes are only
> > a supplement and won't replace the need for true multi-homing for
> > end-sites. Here we have to adapt to business needs, and businesses have
> 
> Why? What problem does multihoming with single prefix solve that a fully 
> working shim6 doesn't?

It does not provide 100% provider-indepence to begin with. Depending on
who you ask that alone is a show-stopper. 

>  What is the argument that the "internet" needs to 
> know about a lot of end-users, instead of the end-user knowing that each 
> end user might have n number of IP addresses and that there are n^2 
> combinations to send packets?

The internet shouldn't need to know anything about individual users to
begin with, provided there are mechanisms avilable track them down. By
that I mean that algorithms to locate end-nodes may include mechanisms
to "interrogate" a large number of nodes to find the desired location as
opposed to looking it up in a locally stored database (routing-table).

Note that I'm all for shim6 as a principle, just not in this context.
It's perfect for future communications devices that may need to switch
between GSM-UMTS, GSM-EDGE, WLAN, WIMAX, ethernet w/charging-power for
mobile units and whatever else is available by then. 

> 
> Convergence time in the real world today is in the minutes, with shim6 it 
> would for the end user be much quicker to "route around" the problem. 
> Shouldn't be any problem to have failover in the subsecond timeframe, even 
> thought that might need some kind of hello mechanism that is suboptimal 
> because it sends traffic not carrying any data.
> 
> > single provider. Besides, shim6 doesn't eliminate the need for a
> > mechanism to locate any globally unique address. What if there's
> 
> I thought DNS solved that?

I thought DNS only provided a name for an address ;) How does DNS tell
us that e.g. 193.10.6.6 is part of a subnet belonging to AS2838 and how
to get there?

> 
> > suddenly 10M LIR's, or otherwise a trend towards a market with very
> > small providers each handling only a small number of customers? Who gets
> > to decide who may peer with whom, or decide which providers will be
> > denied the ability to build redundant connectivity with multiple
> > upstreams?
> 
> It costs money to maintain a LIR which limits the number of LIRs 
> economically viable in the world.

True, but it's just another artificial limit. It doesn't address the
real problem of limitations in current core networking pr

Re: IPv6 news

[Michael . Dillon]

> Many people pick this up and twist it into ~the network has to be 
> application agnostic~ and then use this against NATs or firewalls, 
> which is simply a misuse of the principle.

Personally, I think that NAT's interference with the
communication between hosts is similar to the way in
which error-detection and retransmission interfere
with realtime voice communication, as described in
Saltzer's end-to-end paper:
http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.txt

It seems that the end-to-end principle is more
of a metaphor for how to look at the design problem
rather than a hard and fast rule.

http://www.postel.org/pipermail/end2end-interest/2002-March/001848.html

--Michael Dillon

Re: IPv6 news

[Michael . Dillon]

> Is VJ compression considered a violation of the "end-to-end" principle?

VJ compression happens in the middle of the network, between
two routers/gateways. End-to-end refers to the hosts, i.e. 
the computers which "host" the end users' applications. Of
course, in the old days, many of these "hosts" also carried
out the function of a gateway using a dialup modem, but that
is still not violating the end-to-end model because the end
user application never knows about the VJ compression.

NAT is different because it causes some end-user applications
to fail entirely. For instance an application which sends
its IP address to another host with the instructions "call
me back when something interesting happens". The NAT box
in the middle causes the callback to fail in most cases.

And end-to-end multihoming solution that is consistent
with the end-to-end model will allow any application to
communicate with another host even when one of the hosts
moves to a different network location. BGP multihoming
achieves this by announcing the small number of possible
locations where a particular netblock can be found. The 
telephone system solves this by providing a central directory
service where the network looks up an 800 number (or any
portable number) to find the current location of the destination.
Some people have used DNS techniques to do a similar sort
of IPv4 multihoming, notably Paul Vixie and an Israeli
box vendor whose name escapes me at the moment.

Theoretically, in a network, a router/gateway could
have some intelligence/state so that it does not simply
forward packets based on destination addresses in the routing
table. Instead it does some kind of query/lookup to identify
the real destination location. If you stick this functionality
directly in the end hosts themselves, then you have SHIM6. 
If you stick the functionality in the provider edge router
then you have MPLS.

--Michael Dillon

Re: IPv6 news

[Jeroen Massar]

On Tue, 2005-10-18 at 01:07 +1300, Simon Lyall wrote:

> My son tells me that is what I want so I setup a payment of $5 per month
> to him. In 10 minutes from start to finish my house's /54 is "multi-homed",
> whatever that means.

You cover the payment part, partially. But now the fun parts:
 - which prefix
 - where did you get the prefix
 - who says you are you and thus that you are allowed to use
   that prefix (someone has a working PKI available? :)
 - routing table size?
 - is the other end of the possible communication going to
   be able to reach this prefix?
 - will everybody accept you as being the endpoint?
 - what about a broken prefix 'upstream'
   (you just said your primary link goes down, thus it might
be a misconfig 'upstream')
 - insert various other "2011" stories...

Greets,
 Jeroen



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

Re: IPv6 news

[Jeroen Massar]

On Mon, 2005-10-17 at 11:39 +0100, [EMAIL PROTECTED] wrote:
> > Another alternative is to force-align allocation and topology in some 
> > way /other/ than by "Providers" (geographical allocation in whatever 
> > hierarchy, IX allocation, whatever), such that networks were easily 
> > aggregatable. Lots of objections though (the "providers and geography 
> > don't align" one though is ultimately slightly bogus, because with 
> > non-provider-aligned allocation policies in place it would be in 
> > providers interests to align their peering to match the allocation 
> > policy).
> 
> I think we need a researcher to sit down and 
> figure out exactly what this would look like
> in a sample city and a sample national provider.

There has been quite some research on it, there where ideas, there was
even talk of a vendor going to implement it, but it never happened. It
won't work because of cash reasons (read: telco/transit don't want it)

For your 'city data' check:
http://unstats.un.org/unsd/demographic/default.htm

or for pre-processed files:
http://arneill-py.sacramento.ca.us/ipv6mh/ under "Geographical data".

especially:
http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt

will be quite of your liking.
8<-
Allocation: IANA   block = 2346::/16
Ratio in use: one /48 site for 4 persons
Allocation: 6bone   block = 3FFE:FB00::/24
Ratio in use: one /48 site for 1024 persons
>8

Which indeed seems quite reasonable. The problem with this is:
 'who is paying for which traffic and to whom'

One solution is an overlay network

Notez bien, though this solves multihoming, it doesn't solve relocation,
thus if your company moves it has to renumber, and renumbering is no fun,
then again, you can most likely start from mostly scratch in the new location
and you might be able to tunnel (parts of) the old allocation to the new site
depending on which subnets/hosts one has moved already.

Greets,
 Jeroen



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

Re: IPv6 news

[Simon Lyall]

On Mon, 17 Oct 2005 [EMAIL PROTECTED] wrote:
> I agree that the end state is *NOT* 100% multihoming. It is
> too complex for most people and there is no business
> justification for it. But an awful lot of business customers
> will be able to justify multihoming. That is part and parcel
> of the "mission critical" Internet.

"
The year is 2011. Last week my DSL provider died for 6 hours and my
family was unable to get to the Internet. A friend suggests I try
Suparoute11 (tm), I download the program and install on my Xbox 5.

A few seconds later it uses my Xbox's 802.66 wireless port to contact
several other people running the program within a few blocks of my house.
Options are displayed on my screen, one guy's hub is offering a "backup
10Mb/s home link, tunneled and advertised to TIX" across a large cable
provider.

My son tells me that is what I want so I setup a payment of $5 per month
to him. In 10 minutes from start to finish my house's /54 is "multi-homed",
whatever that means.
"


-- 
Simon J. Lyall  |  Very Busy  |  Web: http://www.darkmere.gen.nz/
"To stay awake all night adds a day to your life" - Stilgar | eMT.

Re: IPv6 daydreams

[Jeroen Massar]

On Mon, 2005-10-17 at 04:43 -0700, David Barak wrote:

> What I'm unhappy
> about is the exceedingly sparse allocation policies
> which mean that any enduser allocation represents a
> ridiculously large number of possible hosts.

See the HD ration + proposals about sizing it down to a /56 as mentioned
in my previous mail to this list.

> The only
> possible advantage I could see from this is the
> protection against random scanning finding a user -
> but new and fun worms will use whatever mechanism the
> hosts use to find each other: I guarantee that the
> "find a printer" function won't rely on a sequential
> probe of all of the possible host addresses in a /64
> either...

SDP, uPnP, DNSSD etc and most likely also using ff02::1 and other
multicast tricks.

The important thing here though is that you already have
a local address

> Also, the 64-bit addressing scheme is sized to include
> the MAC address, right?  Why would encoding L2 data
> into L3 be a good thing?

Because this gives you an automatic unique IP address.
Also some L2's (firewire comes to mind) have 64 bit EUI's.

> The conceptual problem that
> I have had with v6 from the beginning is that it's not
> trying to optimize a single layer, it's really trying
> to merge several layers into one protocol.  Ugh.

One could, at least in theory and afaik not tried yet, run IPv6 as L2 :)

Greets,
 Jeroen



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

Re: IPv6 news

[Stephane Bortzmeyer]

On Mon, Oct 17, 2005 at 12:08:38PM +0100,
 [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote 
 a message of 28 lines which said:

> There are 437 cities of 1 million or more population. There are
> roughly 5,000 cities of over 100,000 population. And there are
> 3,047,000 named communities in the world. 
> 
> Seems to me that the number of routes in the global routing
> table should logically be closer to 5,000 than to 3,000,000.

If there is an exchange point per city over 100,000 (the route goes to
the IXP and then to the actual provider)... Otherwise, there is a flaw
in your calculation.

Re: IPv6 news

[Andre Oppermann]

[EMAIL PROTECTED] wrote:
Another alternative is to force-align allocation and topology in some 
way /other/ than by "Providers" (geographical allocation in whatever 
hierarchy, IX allocation, whatever), such that networks were easily 
aggregatable. Lots of objections though (the "providers and geography 
don't align" one though is ultimately slightly bogus, because with 
non-provider-aligned allocation policies in place it would be in 
providers interests to align their peering to match the allocation 
policy).


I think we need a researcher to sit down and 
figure out exactly what this would look like

in a sample city and a sample national provider.

This is one of those inversion situations where
we are turning the existing model inside out. Some
people may be familiar with the inversion of 
control in user interfaces that came about when

Windows/Macintosh became the standard UI.

Here, the suggestion is that netblocks should
be allocated to cities, not to providers. Within
a city, providers would get a subset of the city
address block to meet their local infrastructure
needs. They would interconnect with each other
a local exchange points to exchange local traffic
as Paul Vixie is suggesting here:
http://news.com.com/5208-1028-0.html?forumID=1&threadID=10554&messageID=77189&start=-1

Addresses from other cities would be viewed as
a single aggregate for that city and these could
be even further aggregated at some regional level
such as Northwest, Southwest, Midwest, Southeast
and Northeast.


Err...  Sounds awfully like E.164.  Why don't we use phone number instead
of IP numbers?  We all know how well carrier phone number routing and number
portability works, don't we?


It's different than what we have now, but not
extremely different. It is doable with IPv6 without
any protocol changes because there is sufficient
reserve address space available. It meets the concept
of Internet as utility or mission-critical Internet
because it mandates local interconnect. The customer
point of view is that low latency and consistent
latency is best and that mandates local interconnect.


I'm sorry, but your geographical approach is broken by design.

--
Andre

Re: IPv6 daydreams

[David Barak]

--- Mark Smith
<[EMAIL PROTECTED]>
wrote:

> Why have people, who are unhappy about /64s for
> IPv6, been happy enough
> to accept 48 bit addresses on their LANs for at
> least 15 years? Why
> aren't people complaining today about the overheads
> of 48 bit MAC
> addresses on their 1 or 10Gbps point-to-point links,
> when none of those
> bits are actually necessary to identify "the other
> end" ? Maybe because
> they have unconsciously got used to the convenience,
> and, if they've
> thought about it, realise that the byte
> overhead/cost of that
> convenience is not worth worrying about, because
> there are far higher
> costs elsewhere in the network (including
> administration of it) that
> could be reduced.

Wrong issue.  What I'm unhappy about is not the size
of the address - you'll notice that I didn't say "make
the whole address space smaller."  What I'm unhappy
about is the exceedingly sparse allocation policies
which mean that any enduser allocation represents a
ridiculously large number of possible hosts.  The only
possible advantage I could see from this is the
protection against random scanning finding a user -
but new and fun worms will use whatever mechanism the
hosts use to find each other: I guarantee that the
"find a printer" function won't rely on a sequential
probe of all of the possible host addresses in a /64
either...

Also, the 64-bit addressing scheme is sized to include
the MAC address, right?  Why would encoding L2 data
into L3 be a good thing?  The conceptual problem that
I have had with v6 from the beginning is that it's not
trying to optimize a single layer, it's really trying
to merge several layers into one protocol.  Ugh.

-David Barak-
-Fully RFC 1925 Compliant-

David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com



__ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/

Re: IPv6 news

[Paul Jakma]

On Mon, 17 Oct 2005, [EMAIL PROTECTED] wrote:

I agree that the end state is *NOT* 100% multihoming. It is too 
complex for most people and there is no business justification for 
it. But an awful lot of business customers will be able to justify 
multihoming. That is part and parcel of the "mission critical" 
Internet.


Portability is another aspect. You mightn't need multihoming for 
failover (don't know about you, but my ISP is plenty reliable), but 
you might want the ability to be "multihomed over time".


Course, IPv6 makes renumbering really easy, so maybe that argument is 
moot.


regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
The secret source of humor is not joy but sorrow; there is no humor in Heaven.
-- Mark Twain

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Paul Jakma]

On Sun, 16 Oct 2005, Tony Li wrote:

This is completely orthogonal to a real identifier/locator split, 
which would divide what we know of as the 'address' into two 
separate spaces, one which says "where" the node is, topologically, 
and one which says "who" the node is.


Hmm, no idea whether it's a good idea or not, but from POV of scaling 
while it might make 'where' scaleable, you still have to find a way 
to tie "who" to "where".


Some might say we already have this split though, DNS.


Tony


regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
Robotic tape changer mistook operator's tie for a backup tape.

Re: IPv6 news

[Michael . Dillon]

> They've been asking for that as well I think. I certainly don't want to
> have 1M+ routes for JUST the Internet to worry about anytime soon, I'd
> hate to see over 300k for real Internet routes anytime soon :( Much of
> today's hardware doesn't seem so happy around that number :( Operators 
and
> IETF need to hit a middle ground.

There are 437 cities of 1 million or more population. There are
roughly 5,000 cities of over 100,000 population. And there are
3,047,000 named communities in the world. 

Seems to me that the number of routes in the global routing
table should logically be closer to 5,000 than to 3,000,000.

> I'm not sure I agree that the end state is 100% multihoming. I can
> certainly agree that more multihoming is coming. Many more people are
> pushing for multihoming today than in previous years, apparently telco
> instability (financial not technical) is/has driven this :) (among other
> things I'm sure)

I agree that the end state is *NOT* 100% multihoming. It is 
too complex for most people and there is no business 
justification for it. But an awful lot of business customers
will be able to justify multihoming. That is part and parcel
of the "mission critical" Internet.

--Michael Dillon

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Mikael Abrahamsson]

On Mon, 17 Oct 2005, Per Heldal wrote:


man, 17,.10.2005 kl. 07.17 +0200, skrev Mikael Abrahamsson:

Both MPLS and any tunneled VPN over IP means the core won't have to know
about all those prefixes (think aggregation of addresses regionally in the
IP case and outer label in the MPLS case).


Hope you don't imply NAT and private addresses like it is usually
associated with VPN in the IPv4 world ;)


No, no NAT and RFC1918 implied, even though it might be part of it.


Then of course I guess the argument can be made to put everything on MPLS
to avoid the core knowing about anything but outer labels.


MPLS on its own won't solve anything. Although MPLS has its uses,
it smells too much like another desperate attempt from the telco-heads
in the ITU crowd to make a packet-switched network look and behave like
a circuit-switched network.


Why? The initial argument for MPLS was that it would solve the core 
problem and put intelligence at the edge. You would have a core that only 
needed to know about hundreds of nodes instead of 100.000:nds of nodes.



Growth can't be eliminated. In the future network you'll have routers
that may know a lot about their "local region" of the network but have
to rely on nodes that are several hops (even AS-hops) away to pass the
packets to more remote destinations. These trust-relationships have to


Yes, that is what's being proposed. Know your internal nodes, announce 
single big prefix externally. With ISPs only having a single prefix and no 
"single customer" prefixes, routing table can be kept low. Redundancy can 
be solved with for instance shim6.



alternative. Without improved routing protocols, all we can do is to
pray that the development of routing hardware in terms of memory and
processing capability outpaces the growth of the routing table.


We have done this for 15 years or so, what good has it brought us? Yes, 
TCAM size etc has been fairly good in keeping up with routing table size, 
but at quite high cost.



Initiatives like shim6 that changes the behaviour of leaf-nodes are only
a supplement and won't replace the need for true multi-homing for
end-sites. Here we have to adapt to business needs, and businesses have


Why? What problem does multihoming with single prefix solve that a fully 
working shim6 doesn't? What is the argument that the "internet" needs to 
know about a lot of end-users, instead of the end-user knowing that each 
end user might have n number of IP addresses and that there are n^2 
combinations to send packets?


Convergence time in the real world today is in the minutes, with shim6 it 
would for the end user be much quicker to "route around" the problem. 
Shouldn't be any problem to have failover in the subsecond timeframe, even 
thought that might need some kind of hello mechanism that is suboptimal 
because it sends traffic not carrying any data.



single provider. Besides, shim6 doesn't eliminate the need for a
mechanism to locate any globally unique address. What if there's


I thought DNS solved that?


suddenly 10M LIR's, or otherwise a trend towards a market with very
small providers each handling only a small number of customers? Who gets
to decide who may peer with whom, or decide which providers will be
denied the ability to build redundant connectivity with multiple
upstreams?


It costs money to maintain a LIR which limits the number of LIRs 
economically viable in the world.


--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

Re: IPv6 news

[Gregory Edigarov]

Just my 5 cents to the  topic:

Don't you all think that IPv6 would not be so neccessary for the very 
long time yet, if the IPv4 allocation scheme would be done right from 
the very very beginning?
If the allocation policies would be something like the ones for ASn's. 
I.e. when you ask for IP space allocation you must be in the need to set 
your own routing policies.
In any other cases you should use private network space with only one IP 
shown outside the network. Yes, this would be a headache for some 
appplications like IP telephony,
but, I don't see any problems in making the _correct_  protocols so they 
could work through NAT.


As what I see now is that a very large address blocks are allocated  to 
large companies,  what companies do with them? Correct, they ae 
installing them as IP's of workstations, when, if IPs 
would be treated as a very valuable resource from the beggining, they 
would have to use  at max /24 (well, may be 2 or three /24) for access 
routers.


When they are proposing  /48 allocation scheme for  IPv6 they  must be 
out of their mind, because in case such allocation will be ineffect, 
IPv6 address space will end shortly too.


Again, IPv6 is creating more problems then solve. Better solution would 
be to freeze IPv4 allocation, then force big IPv4 users to return the 
addresses to the "public pool",  and start

allocation from the white piece of paper, doing the things right.
 


--
With best regards,
GRED-RIPE

Re: IPv6 news

[Michael . Dillon]

> Another alternative is to force-align allocation and topology in some 
> way /other/ than by "Providers" (geographical allocation in whatever 
> hierarchy, IX allocation, whatever), such that networks were easily 
> aggregatable. Lots of objections though (the "providers and geography 
> don't align" one though is ultimately slightly bogus, because with 
> non-provider-aligned allocation policies in place it would be in 
> providers interests to align their peering to match the allocation 
> policy).

I think we need a researcher to sit down and 
figure out exactly what this would look like
in a sample city and a sample national provider.

This is one of those inversion situations where
we are turning the existing model inside out. Some
people may be familiar with the inversion of 
control in user interfaces that came about when
Windows/Macintosh became the standard UI.

Here, the suggestion is that netblocks should
be allocated to cities, not to providers. Within
a city, providers would get a subset of the city
address block to meet their local infrastructure
needs. They would interconnect with each other
a local exchange points to exchange local traffic
as Paul Vixie is suggesting here:
http://news.com.com/5208-1028-0.html?forumID=1&threadID=10554&messageID=77189&start=-1

Addresses from other cities would be viewed as
a single aggregate for that city and these could
be even further aggregated at some regional level
such as Northwest, Southwest, Midwest, Southeast
and Northeast.

It's different than what we have now, but not
extremely different. It is doable with IPv6 without
any protocol changes because there is sufficient
reserve address space available. It meets the concept
of Internet as utility or mission-critical Internet
because it mandates local interconnect. The customer
point of view is that low latency and consistent
latency is best and that mandates local interconnect.

--Michael Dillon

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Per Heldal]

man, 17,.10.2005 kl. 07.17 +0200, skrev Mikael Abrahamsson:
> Both MPLS and any tunneled VPN over IP means the core won't have to know 
> about all those prefixes (think aggregation of addresses regionally in the 
> IP case and outer label in the MPLS case).

Hope you don't imply NAT and private addresses like it is usually
associated with VPN in the IPv4 world ;)

> 
> So if you're building a 100G capable platform that'll do IPv6 and MPLS, 
> how much difference would it be if you only had to support 16000 labels 
> and 16000 IPv6 prefixes, rather than 2 million?
> 
> Then of course I guess the argument can be made to put everything on MPLS 
> to avoid the core knowing about anything but outer labels.
> 

MPLS on its own won't solve anything. Although MPLS has its uses,
it smells too much like another desperate attempt from the telco-heads
in the ITU crowd to make a packet-switched network look and behave like
a circuit-switched network.

What this discussion boils down to is that a long term solution has to
remove the size of the routing-table as a limiting factor in internet
routing.  Something must eliminate the need for every node in the
default-free transit-network to know how to reach every allocated
address-block at all times. Allocation policies, operational agreements
on filtering, BCPs etc can only slow the growth of the routing-table.
Growth can't be eliminated. In the future network you'll have routers
that may know a lot about their "local region" of the network but have
to rely on nodes that are several hops (even AS-hops) away to pass the
packets to more remote destinations. These trust-relationships have to
be built and maintained automatically (may involve packet tagging /
tunnelling etc), similar to current route-cache mechanisms, but will
require a whole new set of routing protocols. Despite lots of research
there's no such solution today or anytime soon. Just think of the added
complexity. How do you build trust with remote nodes given the problems
you see in trusting your direct peers in the BGP world today? How can
routing loops be prevented in such a network? All we know is that if
there is no such solution, at some point in time the network will
fragment due to its size and complexity.

In the meantime we have to manage with what we've got, and treat v6 just
like we've done with v4 - multihoming and all. We know we'll run out of
v4 addresses at some point, and that v6 is the only realistic
alternative. Without improved routing protocols, all we can do is to
pray that the development of routing hardware in terms of memory and
processing capability outpaces the growth of the routing table.
Initiatives like shim6 that changes the behaviour of leaf-nodes are only
a supplement and won't replace the need for true multi-homing for
end-sites. Here we have to adapt to business needs, and businesses have
made it pretty clear that it is unacceptable to them to be tied to any
single provider. Besides, shim6 doesn't eliminate the need for a
mechanism to locate any globally unique address. What if there's
suddenly 10M LIR's, or otherwise a trend towards a market with very
small providers each handling only a small number of customers? Who gets
to decide who may peer with whom, or decide which providers will be
denied the ability to build redundant connectivity with multiple
upstreams?




//Per

Re: IPv6 daydreams

[Peter Dambier]

Mohacsi Janos wrote:





On Mon, 17 Oct 2005, Peter Dambier wrote:



From an end-user:

I dont know what I should need an /64 for but it's barf, barf anyhow.

My routing table is telling me I have got a /124 only:

The tunnel (network) *::0
The end of the tunnel *::1
Me *::2
The tunnel broadcast *::3



What? Broadcast?


Well, it is singlecast :)

ping *::3 and 1 answers.

ping *::1 ok 1 answers.

ping *::2 nobody answers - that is my configuration problem.

ping *::0 nobody answers





Right now I have the impression we are only enusers.
Right now I have the impression we are all connected to the same
university PC running BSD something.

Ok, today I have some NATted stuff that would be fond of its own
ip. Kicking my NAT-box out I could grow my hair again. No more
worring who needs what port and why.

Beware!

Who is printing all those bank listings on my new printer. It
was a wholesale networkprinter. Just plug it into the power
and print. Must have been stolen from the bank of china because
it is all chines companies.

And why is that van with the ice cream waiting in front of my
neighour? It is me who ordered the icream. They have thrown
out their freecer. I dont know why. It was working perfectly.
I had no problems connecting it to my wlan and ordering. They
did not even care about my bank account beeing empty. They told
me I had enough credit to by their company.

Sorry I have to stop now. Some policemen want to talk with me
about a major fraud done with my IPv6 tunnel.

See you later :)




Janos Mohacsi
Network Engineer, Research Associate
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE  21A2 9F52 0D1F 00F9 AF98




Jeroen Massar wrote:


On Mon, 2005-10-17 at 02:52 +, Christopher L. Morrow wrote:


On Sat, 15 Oct 2005, Tony Li wrote:


Hopefully, that will reach a point where the operators show up and
participate at IETF, rather than the IETF coming to NANOG.



agreed.




Full ack. Ops should really realize that they can have a lot of
influence in the processes and what is actually being standardized.
Which really helps the ops a lot as they then have an extra foot in
the door at the Vendors, as the IETF is also known as the IVTF as some
people like to call it :)

On Mon, 2005-10-17 at 09:15 +0530, Suresh Ramasubramanian wrote:


On 17/10/05, David Barak <[EMAIL PROTECTED]> wrote:


I'd change the allocation approach: rather than give
every customer a /64, which represents an IPv4
universe full of IPv4 universes, I'd think that any
customer can make do with a single IPv4-size universe,
and make the default end-customer allocation a /96.



I personally am in favor of reducing minimum allocations like this -
and as was discussed quite extensively in the "botnet of toasters and
microwave ovens when you ipv6 enable the lot" thread a few weeks back,
it usually ends up that there's just one host in a /48 or /64 so that
the sparsely populated v6 address space means bots cant go scanning IP
space for vulnerable hosts like they do in v4




There is a current document out for trying to get this stepped back to
a /56 for _enduser_ sites. Corporate / Organisational / Business sites
should then still get a /48.

HD ratio docs:
http://www.ripe.net/ripe/policies/proposals/2005-1.html
http://www.ripe.net/ripe/policies/proposals/2005-08.html

Endsite definition:
http://www.ripe.net/ripe/policies/proposals/2005-4.html

As a note, out of my IPv6 /48, at home, I only use one /64 as I bridged
the wireless and wired networks. This was easier than having Samba do
remote announces to the other /64 and also allows me to re-attach my
laptop and plug it into the wired without it changing the IP, very cheap
'mobility' :) A /56 for 'home usage', thus having 2^8 = 256 /64's or
subnets would IMHO (force me to drink beer when this ever turns out to
be wrong :) be enough for most home usages. I really don't see people
installing 200+ routed networks in a home. Most people don't even have
more than 4 rooms and one /64 already contains 2^64 addresses, unless we
go for the IP-per-carpet-fiber approach, just give the carpet in your
house a single /64 and you still have 255 subnets to go...



It also means that when Vint Cerf's research about extending the
internet into outer space comes through (or when we finally start
exchanging email, http or whatever traffic with aliens), there's
sooner or later going to be an intergalactic assembly of some sort
where delegations from Betelgeuse and Magrathea will complain about
how those @^$^$#^$^ earthlings hogged all the v6 space thinking
there's more than enough v6 IP space to allot a /48 to every single
molecule on earth, so now they're not getting enough IP space to
network a group of computers that'll plot the answer to life, the
universe and everything.




They don't need to, this computer is already there, it is Earth.
there just ain't no plotter installed and we will be destroyed for that
superhighway and then re-built as Earth 2, but we won't notice t

Re: IPv6 daydreams

[Paul G]

- Original Message - 
From: "Peter Dambier" <[EMAIL PROTECTED]>

To: "Jeroen Massar" <[EMAIL PROTECTED]>
Cc: "Suresh Ramasubramanian" <[EMAIL PROTECTED]>; "Tony Li" 
<[EMAIL PROTECTED]>; "Daniel Roesen" <[EMAIL PROTECTED]>; "Christoper L. Morrow" 
<[EMAIL PROTECTED]>; 

Sent: Monday, October 17, 2005 5:43 AM
Subject: Re: IPv6 daydreams


--- snip ---


Sorry I have to stop now. Some policemen want to talk with me
about a major fraud done with my IPv6 tunnel.

See you later :)


no, they're just there to help out the guys in the white lab coats holding 
an odd-looking jacket. better late than never, i guess. we'll come visit 
(not really).


;)

---
paul galynin 

Re: IPv6 news

[Michael . Dillon]

> > there is no hope in having operators explain to ietf that the current 
path
> > is fruitless? certainly they can be made to see the light, yes?
> 
> you have not spent much time with the ivtf, have you?

In case you have never heard of the IVTF, Randy eloquently
summarizes it here:
https://rip.psg.com/~randy/050721.ccr-ivtf.html

--Michael Dillon

Re: 6to4 gateways

[Perry Lorier]

> 
> This seems like a problem that could be solved in the
> style of the CIDR report. Regular weekly reports of 
> v6 relays and locations as seen from various major ASes.

>From my "tr" website I can see a few 6to4 gateways:
http://tr.meta.net.nz/output/2005-10-17_22:41_192.88.99.1.png
(beware, the image is extremely large, and can kill some browsers on
lower end machines).

Most of my source nodes are in NZ unfortunately which limits the number
of relays seen.

Re: IPv6 daydreams

[Peter Dambier]

From an end-user:

I dont know what I should need an /64 for but it's barf, barf anyhow.

My routing table is telling me I have got a /124 only:

The tunnel (network) *::0
The end of the tunnel *::1
Me *::2
The tunnel broadcast *::3

Right now I have the impression we are only enusers.
Right now I have the impression we are all connected to the same
university PC running BSD something.

Ok, today I have some NATted stuff that would be fond of its own
ip. Kicking my NAT-box out I could grow my hair again. No more
worring who needs what port and why.

Beware!

Who is printing all those bank listings on my new printer. It
was a wholesale networkprinter. Just plug it into the power
and print. Must have been stolen from the bank of china because
it is all chines companies.

And why is that van with the ice cream waiting in front of my
neighour? It is me who ordered the icream. They have thrown
out their freecer. I dont know why. It was working perfectly.
I had no problems connecting it to my wlan and ordering. They
did not even care about my bank account beeing empty. They told
me I had enough credit to by their company.

Sorry I have to stop now. Some policemen want to talk with me
about a major fraud done with my IPv6 tunnel.

See you later :)


Jeroen Massar wrote:
On Mon, 2005-10-17 at 02:52 +, Christopher L. Morrow wrote: 


On Sat, 15 Oct 2005, Tony Li wrote:


Hopefully, that will reach a point where the operators show up and
participate at IETF, rather than the IETF coming to NANOG.



agreed.



Full ack. Ops should really realize that they can have a lot of
influence in the processes and what is actually being standardized.
Which really helps the ops a lot as they then have an extra foot in
the door at the Vendors, as the IETF is also known as the IVTF as some
people like to call it :)

On Mon, 2005-10-17 at 09:15 +0530, Suresh Ramasubramanian wrote:


On 17/10/05, David Barak <[EMAIL PROTECTED]> wrote:


I'd change the allocation approach: rather than give
every customer a /64, which represents an IPv4
universe full of IPv4 universes, I'd think that any
customer can make do with a single IPv4-size universe,
and make the default end-customer allocation a /96.


I personally am in favor of reducing minimum allocations like this -
and as was discussed quite extensively in the "botnet of toasters and
microwave ovens when you ipv6 enable the lot" thread a few weeks back,
it usually ends up that there's just one host in a /48 or /64 so that
the sparsely populated v6 address space means bots cant go scanning IP
space for vulnerable hosts like they do in v4



There is a current document out for trying to get this stepped back to
a /56 for _enduser_ sites. Corporate / Organisational / Business sites
should then still get a /48.

HD ratio docs:
http://www.ripe.net/ripe/policies/proposals/2005-1.html
http://www.ripe.net/ripe/policies/proposals/2005-08.html

Endsite definition:
http://www.ripe.net/ripe/policies/proposals/2005-4.html

As a note, out of my IPv6 /48, at home, I only use one /64 as I bridged
the wireless and wired networks. This was easier than having Samba do
remote announces to the other /64 and also allows me to re-attach my
laptop and plug it into the wired without it changing the IP, very cheap
'mobility' :) A /56 for 'home usage', thus having 2^8 = 256 /64's or
subnets would IMHO (force me to drink beer when this ever turns out to
be wrong :) be enough for most home usages. I really don't see people
installing 200+ routed networks in a home. Most people don't even have
more than 4 rooms and one /64 already contains 2^64 addresses, unless we
go for the IP-per-carpet-fiber approach, just give the carpet in your
house a single /64 and you still have 255 subnets to go...



It also means that when Vint Cerf's research about extending the
internet into outer space comes through (or when we finally start
exchanging email, http or whatever traffic with aliens), there's
sooner or later going to be an intergalactic assembly of some sort
where delegations from Betelgeuse and Magrathea will complain about
how those @^$^$#^$^ earthlings hogged all the v6 space thinking
there's more than enough v6 IP space to allot a /48 to every single
molecule on earth, so now they're not getting enough IP space to
network a group of computers that'll plot the answer to life, the
universe and everything.



They don't need to, this computer is already there, it is Earth.
there just ain't no plotter installed and we will be destroyed for that
superhighway and then re-built as Earth 2, but we won't notice that :)



Well, I know that sounds silly, but people were handing out class A, B
and C space for years thinking nobody at all would run out of v4
space, there's lots of it so why not just parcel it out with open
hands.



The Huitema-Durand / Host-Density (HD) ratio RFC3194 it explains quite a
number of these issues and covers most of them.

Next to that note that 2000::/3 is only 1/8th of the total IPv6 addre

Re: IPv6 daydreams

[Kevin Loch]

Mark Smith wrote:

We didn't
get 48 bits because we needed them (although convenience is a need, if
it wasn't we'd still be hand winding our car engines to start them ). We
got them because it made doing other things much easier, such as (near)
guarantees of world wide unique NIC addresses, allowing "plug-and-play",
at least a decade before the term was invented.


This is not a scientific opinion but I think you can pick a random host
id from 32 bit space on most lans without having to retry very often.

- Kevin

Re: IPv6 news

[Kevin Loch]

Paul Jakma wrote:


And 6to4 obviously won't fly for long after the 4 tank runs dry.


Hopefully it won't need to at that point as it is only intended as
a transitional step.

I like the simplicity of 6to4 and the way it preserves end-to-end
addresses.   If only there was a way to adapt it's stateless
automatic tunneling to solve the IPv6 multihoming/PI problem.

I took a quick hack at it and the result is interesting though
far from perfect:

http://kl.net/ipv6/pi-in-6.txt

- Kevin

Re: IPv6 daydreams

[Mark Smith]

Hi Randy,

On Sun, 16 Oct 2005 23:08:49 -1000
Randy Bush <[EMAIL PROTECTED]> wrote:

> 
> > If we're going to do that, we may as well also start reclaiming
> > those 48 bit MAC addresses that come with ethernet cards. After
> > all, nobody would need anymore than say 12 to 13 bits to address
> > their LANs.
> 
> so you think that layer-2 lans scale well above 12-13 bits?
> which ones in particular?
>

Maybe you've missed my point. Nobody (at least that I'm aware of)
_needs_ 48 bits of address space to address nodes their LANs. We didn't
get 48 bits because we needed them (although convenience is a need, if
it wasn't we'd still be hand winding our car engines to start them ). We
got them because it made doing other things much easier, such as (near)
guarantees of world wide unique NIC addresses, allowing "plug-and-play",
at least a decade before the term was invented.

I've read somewhere that the original ethernet address was only 16 bits
in size. So why was it expanded to 48 bits ? Obviously people in the 80s
weren't running LANs with 2^48 devices on them, just like they aren't
today.

Why have people, who are unhappy about /64s for IPv6, been happy enough
to accept 48 bit addresses on their LANs for at least 15 years? Why
aren't people complaining today about the overheads of 48 bit MAC
addresses on their 1 or 10Gbps point-to-point links, when none of those
bits are actually necessary to identify "the other end" ? Maybe because
they have unconsciously got used to the convenience, and, if they've
thought about it, realise that the byte overhead/cost of that
convenience is not worth worrying about, because there are far higher
costs elsewhere in the network (including administration of it) that
could be reduced.

Regards,
Mark.

-- 

The Internet's nature is peer to peer.

Re: IPv6 daydreams

[Randy Bush]

> If we're going to do that, we may as well also start reclaiming
> those 48 bit MAC addresses that come with ethernet cards. After
> all, nobody would need anymore than say 12 to 13 bits to address
> their LANs.

so you think that layer-2 lans scale well above 12-13 bits?
which ones in particular?

randy

Re: IPv6 daydreams

[Mark Smith]

Hi David,

On Sun, 16 Oct 2005 16:49:25 -0700 (PDT)
David Barak <[EMAIL PROTECTED]> wrote:

> 

> 
> I'd change the allocation approach: rather than give
> every customer a /64, which represents an IPv4
> universe full of IPv4 universes, I'd think that any
> customer can make do with a single IPv4-size universe,
> and make the default end-customer allocation a /96. 
> ISPs could still get gigantic prefixes (like a /23 or
> something), to make sure that an ISP would never need
> more than one prefix.
> 

If we're going to do that, we may as well also start reclaiming those 48
bit MAC addresses that come with ethernet cards. After all, nobody would
need anymore than say 12 to 13 bits to address their LANs.

Hmm, so what do 48 bit addresses give us that 12 bits don't ? How about
convenience. It is convenient to be able to plug in an ethernet card,
and, excepting the very rare occasions when a manufacturer has stuffed
up, be assured that you can just plug it in and it works. No jumpering,
no maintaining a LAN address registry per segment, no address
collisions, or at least extremely rare ones.

>From what I understand, it is considered that 48 bit MAC addresses will
be too small for our convenience needs of the future, so IEEE have
invented 64 bit ones (EUI-64s).

Wouldn't it be nice to the same sort of convenience in a new layer 3
protocol that we've had since 802.3 was first published (and since I
started working in networking 1993) ? I'd like it, and I'm willing to
pay a few bytes in the src and dst addresses in my layer 3 protocol
header for it.

/64s in IPv6 for multi-access segments (i.e. everything other than
single address loopbacks) is convenient and useful, and I think should
be kept.


Regards,
Mark.

-- 

The Internet's nature is peer to peer.

Re: IPv6 news

[Michael . Dillon]

> RFC 3068 also has another problem -- not enough relays, or at least not 
> enough in logical locations.  From my home in Texas, a traceroute shows 
the 
> topologically "closest" instance of 192.88.99.1 to be in France.  Nice 
to 
> see that GBLX's "native" IPv6 network doesn't have any 6to4 relays in 
the 
> US, and that AT&T doesn't have any at all. (Or if they do, they need 
serious 
> anycast tuning)

This seems like a problem that could be solved in the
style of the CIDR report. Regular weekly reports of 
v6 relays and locations as seen from various major ASes.

--Michael Dillon

RE: Choosing new transit: software help?

[Michael . Dillon]

> > A top AS and top prefix talkers would be really useful.
> 
> Flowscan will do the top AS, out of the box.
> It could be hacked to go further.

And guess what we find elsewhere on that nifty set
of pages referred to by Bill Manning?

http://www.caida.org/tools/

--Michael Dillon

Re: Level 3's side of the story

[Daniel Karrenberg]

On 16.10 16:04, Simon Leinen wrote:
> 
> Kevin Loch writes:
> > Does anyone have reachability data for c-root during this episode?
> 
> The RIPE NCC "DNSMON" service has some:
> 
> http://dnsmon.ripe.net/dns-servmon/server/plot?server=c.root-servers.net&type=drops&tstart=1128246543&tstop=1128972253

If there is anyone with more comprehensive  data I'd like to hear about it ;-) !

> According to BGPlay for that particular prefix from Route-Views data
> (for some reason the RIPE RIS server used by BGPlay seems to be down
> at the moment), the "episode" seems to be between these times (UTC):

It is up now. Of the two routes to c.root-servers.net via Level 3 in that 
data set one stayed up during the period and the other got healed immediateely 
via AS286. It flipped back later.

> ...

> The interval in the URL above starts 72 hours before the start of the
> episode and ends 72 hours after its end.  I cannot see any particular
> problems that would coincide with the episode, from that set of probes
> (RIPE TTM).

I agree that there is nothing really significant here. It is mostly noise.
What one is looking for in these graphs is strong vertical 
patterns.  dnsmon did not detect anything significant concerning
reachability of c.root-servers.net.

> As someone else said, partial unreachability of a particular root
> nameserver isn't that much of an issue.  

Indeed.

> But it's an interesting question nevertheless.

A red instance of a fish from the northern seas ?

Daniel

Re: IPv6 daydreams

[Jeroen Massar]

On Mon, 2005-10-17 at 02:52 +, Christopher L. Morrow wrote: 
> 
> On Sat, 15 Oct 2005, Tony Li wrote:
> > Hopefully, that will reach a point where the operators show up and
> > participate at IETF, rather than the IETF coming to NANOG.
> >
> 
> agreed.

Full ack. Ops should really realize that they can have a lot of
influence in the processes and what is actually being standardized.
Which really helps the ops a lot as they then have an extra foot in
the door at the Vendors, as the IETF is also known as the IVTF as some
people like to call it :)

On Mon, 2005-10-17 at 09:15 +0530, Suresh Ramasubramanian wrote:
> On 17/10/05, David Barak <[EMAIL PROTECTED]> wrote:
> > I'd change the allocation approach: rather than give
> > every customer a /64, which represents an IPv4
> > universe full of IPv4 universes, I'd think that any
> > customer can make do with a single IPv4-size universe,
> > and make the default end-customer allocation a /96.
> 
> I personally am in favor of reducing minimum allocations like this -
> and as was discussed quite extensively in the "botnet of toasters and
> microwave ovens when you ipv6 enable the lot" thread a few weeks back,
> it usually ends up that there's just one host in a /48 or /64 so that
> the sparsely populated v6 address space means bots cant go scanning IP
> space for vulnerable hosts like they do in v4

There is a current document out for trying to get this stepped back to
a /56 for _enduser_ sites. Corporate / Organisational / Business sites
should then still get a /48.

HD ratio docs:
http://www.ripe.net/ripe/policies/proposals/2005-1.html
http://www.ripe.net/ripe/policies/proposals/2005-08.html

Endsite definition:
http://www.ripe.net/ripe/policies/proposals/2005-4.html

As a note, out of my IPv6 /48, at home, I only use one /64 as I bridged
the wireless and wired networks. This was easier than having Samba do
remote announces to the other /64 and also allows me to re-attach my
laptop and plug it into the wired without it changing the IP, very cheap
'mobility' :) A /56 for 'home usage', thus having 2^8 = 256 /64's or
subnets would IMHO (force me to drink beer when this ever turns out to
be wrong :) be enough for most home usages. I really don't see people
installing 200+ routed networks in a home. Most people don't even have
more than 4 rooms and one /64 already contains 2^64 addresses, unless we
go for the IP-per-carpet-fiber approach, just give the carpet in your
house a single /64 and you still have 255 subnets to go...

> It also means that when Vint Cerf's research about extending the
> internet into outer space comes through (or when we finally start
> exchanging email, http or whatever traffic with aliens), there's
> sooner or later going to be an intergalactic assembly of some sort
> where delegations from Betelgeuse and Magrathea will complain about
> how those @^$^$#^$^ earthlings hogged all the v6 space thinking
> there's more than enough v6 IP space to allot a /48 to every single
> molecule on earth, so now they're not getting enough IP space to
> network a group of computers that'll plot the answer to life, the
> universe and everything.

They don't need to, this computer is already there, it is Earth.
there just ain't no plotter installed and we will be destroyed for that
superhighway and then re-built as Earth 2, but we won't notice that :)

> Well, I know that sounds silly, but people were handing out class A, B
> and C space for years thinking nobody at all would run out of v4
> space, there's lots of it so why not just parcel it out with open
> hands.

The Huitema-Durand / Host-Density (HD) ratio RFC3194 it explains quite a
number of these issues and covers most of them.

Next to that note that 2000::/3 is only 1/8th of the total IPv6 address
space. If we peep up, we can do that 8 times before the address space is
full and I am quite sure if 2000::/3 runs out that people will start
having some really loud discussions. Indeed 2000::/3 would then be
similar to 'class A' space...

> Back to operations - there was this interesting proposal - well, two
> proposals as it turned out - at apnic 20 -
> http://www.apnic.net/meetings/20/report.html

Similar to the one done above in the RIPE region :)

Greets,
 Jeroen



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