Re: Why IPv6 is a must?

[Keith Moore]

> Note that to some degree, for some people, in some topologies, MPLS does
> exactly what you suggest. 

yes, indeed.  of course, the devil is in the details.  

having a separate pseudo-header with routing locator, for use by the 
routing system seems like a useful approach (though not the only 
possible approach).  OTOH, based on what I've heard I've formed
the impression that there are scaling limitations with the way that 
MPLS tends to be used.

Keith

Re: Why IPv6 is a must?

[Joel M. Halpern]

Note that to some degree, for some people, in some topologies, MPLS does 
exactly what you suggest.  It provides a modest size space of identifiers 
(which are local, an advantage) which can be used for forwarding by many 
devices.  For some situations, all the large table processing can be moved 
to the network edge. Unfortunately, the utilization and application is 
rather more complex.  But this kind of system does have many scaling 
advantages in that for most parts of the system the locator is indeed a 
separate and manageable piece of information.
Signalled systems also have the advantage that the setup can use large 
tables that are NOT in the fast path and therefore can tolerate worse 
scaling behaviors.  Of course, such systems also introduce interesting 
limtations and problems.  For example, scaling the number of paths that are 
setup can be a new and interesting way to choke.

Yours,
Joel M. Halpern

At 06:46 PM 11/12/01 -0500, Keith Moore wrote:
> > | at present our locators are AS numbers.
> >
> > No, Keith, they are not.
> >
> > The AS number does not describe a location in any sort of topology.
> > It is simply a representation of a set of routers with the same
> > routing policy, that should not receive via eBGP NLRI which
> > have originated from or passed through said routers.
> >
> > The AS number is otherwise completely meaningless, although
> > the AS path itself is a funny sort of non-scalar metric.
> > (See the work of Ahuja and Labovitz for details on that).
> >
> > A locator by definition must describe a precise location within
> > a network, such that any router will be able to forward traffic
> > towards that network using only the information in locator.
> >
> > In IPv4, the locator *is* the IPv4 address, independent of
> > what inter- or intra-domain routing system is being used.
>
>thanks for the clarification.  I don't pretend to be a routing
>expert;  I just get into these discussions in an effort to
>keep the proposed solutions for routing scalability problems
>from harming applications.
>
>but if AS#s aren't usable as locators, it seems like
>it should be possible to use BGP to advertise mappings from
>IP address prefixes to some other kind of locator, and to
>base route computations on *those* locators rather than
>on address prefixes.  that would allow routers to
>effectively aggregate routes for dissimilar prefixes,
>at least for the purpose of route computations.
>(even if the forwarding table still had to be indexed
>by address prefix)
>
> > | if we change the system to use a different kind of locator we still
> > | need stable addresses, we still have to maintain the mapping
> > | function from addresses to locators, and we still need that mapping
> > | function to be current and reliable.
> >
> > End-to-end/globally-unique identifiers are very convenient indeed.
> > However, identifiers and locators are different.
> > There is no reason to overload them, and it's a bad habit.
>
>there are plenty of reasons why they are overloaded, it's just that
>folks tend to overloook those reasons because they are focusing
>on a single problem.  some of them are outlined in another message
>that I sent to the IETF list today.
>
> > It's also a bad habit to think that locators need to be
> > end-to-end or globally (rather than contextually) unique.
>
>they don't have to be.  it's just that if the locators are
>context-specific then you can only use them for routing
>within the context in which they're valid.  (and you want
>to make really sure they don't get confused with locators
>from other contexts)
>
> > | what we are arguing about is the appropriate granularity of the
> > | mapping function, and the appropriate place to maintain that mapping.
> >
> > No, we are not arguing about that, but these are indeed issues.
>
>I think that's the fundamental issue - at least, given the other
>constraints on the problem that seem to be imposed.
>
>Keith

Re: ipv6 adoption....

[Perry E. Metzger]

Dave Crocker <[EMAIL PROTECTED]> writes:
> The phrase "damning with faint praise" comes to mind.  Given how long
> IPv6 has been in the pipeline, the fact that it is available at an
> essentially production level in a minuscule level, so far, says that
> we are looking at a 10-20 year adoption cycle.

I'm really not sure that this is very bad at all seeing it from the
"inside". Two years ago there was nary an OS that came with v6. Now I
think the only significant one that is missing v6 support is MacOS X,
and that's only because they haven't figured out the right ways to
wrap the calls for the application layer (the kernel bits are
easy). Without any OS support, how could anyone run it, even people
who wanted to? The fact that we've moved so fast from a standing start
is pretty impressive. Consider how slowly IPv4 grew by comparison.

I think realistically speaking, mid 2000 was the beginning of
deployment in any real sense at all, and in terms of desktop OSes used
by the bulk of consumers, we've only had availability in a stock
OS for a few weeks now.

My opinion is that ten years is on the high side. Unlike v4
deployment, it is much easier to deploy v6 in a v4 world than it was
to deploy v4 with no internet around. However, anyone who thought this
could be done in less than years was not thinking clearly about the
problem.

> IPv6 seeks to change an existing infrastructure.  That means that its
> adoption is vastly slower than an end-point change, such as adoption
> of MIME.  And it took MIME 5 years to become seriously available, and
> at least 8 years before it was reliably available.

I disagree -- it is mostly an endpoint change, and the endpoints are
the hard part. The extant v6 network functions fine over tunnels on
most of its connections. Some of the biggest uses of v6 I see in the
short run are in overlay networks to get around v4 NAT hells for
network management.

The other thing to keep in mind is that it is perfectly useful to run
v6 machines in a v4 world -- it isn't like you won't be able to look
at cnn.com until cnn.com runs v6. The v4 universe forces me to use
translator boxes anyway, so there is no giant reason to use NAT boxes
instead of v4<->v6 gateways, but one has the advantage that one gets
real address space and can actually get at the individual machines
over v6, which is very hard to do in nested NAT world.

--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/

Re: Why is IPv6 a must?

[Keith Moore]

> | there is another important difference between v4 and v6 - we don't have
> | enough addresses for everyone to use v4.
> (... at the same time)
> 
> That is, either some subset of everyone can use v4 with addresses
> which are changed relatively infrequently, or everyone can use
> v4 with addresses with relatively short leases that expire as
> soon as possible as a device goes dormant.

"some subset of everyone" doesn't work well.  either you have to
find some way of deciding who can use the internet at a particular
time, or you have to divide the internet up (rather arbitrarily) 
into discrete subsets, which gives you the suite of NAT problems.

short leases don't work for applications whose run times overlap
the lease expirations.  

> | there is another important difference between v4 and v6 - we don't have
> | enough addresses for everyone to use v4 [classic].
> (... to talk to everyone else)
> 
> Or, some subset of everyone can use v4 with globally unique addresses,
> or everyone can use v4 with addresses which are only locally unique
> (and must therefore use translators to talk to things in other locations).

and since translators only work for pairwise connections, this severely
constrains the kinds of applications that can be run.

> Unfortunately, the overloading of locator and identifier, and
> the bad habits that this overloading has engendered in people's
> minds, 

one of the worst habits here is the failure to analyze the effects 
of such constraints on all aspects of the Internet - not just 
routing but also management, and applications, and users.

> means that neither of these is particularly palatable
> at the moment, but neither are they impossible.

it's not the bad habits that you are referring to that make NATs
unpalatable.  it's the fact that they break applications, make 
networks more fragile and more difficult to configure, and 
increase the difficulty of diagnosing problems. 

nor is it clear to me that merely having had separate locators and endpoint
identifiers in IPv4  (from day one) would have solved the routing 
scalability problem.  

- having a separate endpoint identifier would have allowed applications
to deal with changes in locator only if the endpoint identifiers were
globally usable to reach the endpoint, and only if changes in the locator
were transparent to the applications.  in other words, whenever the
locator for an endpoint changes you have to have some way of quickly
and reliably informing everyone who is using that locator.

- being able to route to a host via multiple  locators doesn't help
unless the guy who is making the routing decision actually has
reliable information on which to base that decision.  this is why
the notion of v6 multihoming using DNS isn't terribly useful - because
the host or application that is making the decision typically doesn't
have the information it needs to make that decision.

- being able to renumber frequently to reflect changes in topology
would help.  but the difficulty in renumbering isn't just due to those 
addresses being wired into DNS and host stacks - they're also wired into 
routers, firewalls, network management stations, etc.making renumbering 
painless also involves tackling some thorny authentication issues that still 
haven't been addressed in BGP.  separating locators from endpoint identifiers 
might have been part of the solution, but it seems more likely that we would 
have needed a complete renumbering architecture.  otherwise there would have 
been nearly as much resistance  to renumbering as there is now.

> I agree that locator- and identifier-sharing are both non-ideal,
> but they may be more practical than moving to a system which
> still overloads locator and identifier in a flat address anyway.

I strongly suspect that if/when we find a solution to this constraint 
set that it will involve some separation of identifiers relative to
what we have now.  but I also strongly suspect that a solution to the
whole constraint set (not just the routing problem but also the management
problem and still having a network that can support many kinds of 
applications) is one that mostly uses locators internally to the routing 
system and mostly insulates locators from end hosts.   most of the
ideas I've seen expect the locator to live in the field now occupied by the 
IP address, at least as seen by the host. 

and even if we implemented that separation in IPv4, I sincerely doubt we 
could manage delegation and assignment within a 32-bit wide endpoint 
identifier space efficiently enough to be able to assign endpoint 
identifiers to everyone that needed them.

Keith

Re: ipv6 adoption....

[Dave Crocker]

At 04:10 PM 11/12/2001 -0500, Perry E. Metzger wrote:
>Hell, I roamed onto a university campus wireless network not that long
>ago, and for the hell of it sent out a router discovery message and
>found myself on the 6bone. No, not quite the same as finding my
>dentist using v6, but an astonishing trend, even from the point of
>view of my wildest dreams.

The phrase "damning with faint praise" comes to mind.  Given how long IPv6 
has been in the pipeline, the fact that it is available at an essentially 
production level in a minuscule level, so far, says that we are looking at 
a 10-20 year adoption cycle.

IPv6 seeks to change an existing infrastructure.  That means that its 
adoption is vastly slower than an end-point change, such as adoption of 
MIME.  And it took MIME 5 years to become seriously available, and at least 
8 years before it was reliably available.

d/


--
Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464

Re: Why is IPv6 a must?

[Sean Doran]

| Who says you need to use the IP addresses for that purpose? There is
| plenty of precedent -- for a a long time we've had this notion of the
| routing protocols adding labels on that had nothing to do per se with
| the IP address. See the "AS" notion, for example, in which we label
| various clouds with AS numbers, which are never seen by end users. It
| would be straightforward enough to build a labeling scheme that was
| used inside the routing protocol that stayed inside the routing
| protocol. You could happily label the nodes of the routing cloud with
| whatever numbering/labeling scheme you like.

Map-and-encap systems can work quite well; it's mostly a question
of making sure the various mapping points can coordinate with various
things (and each other), and making sure they can cope with 
the map-encap-decap-process operations they have to perform.

One of the systems you have rubbished in this thread is
heavily influenced by, and even reliant upon, map-and-encap,
and several smart people believe it would work OK.

Peter Lothberg (whom I find myself agreeing with alot) is
the progenitor of an interesting map-and-encap system which
allows for (among other things) separating end-to-end identity
from topological location.

Unfortunately, map-and-encap systems can also be like MPLS...

Anyway, if you are going to use the same encapsulated
payload and are going to have a common globally unique
identifier inside that payload, why not integrate the inside
and outside headers, rather than use encapsulation and
information pull-up/push-down, which are inevitably more expensive?

Again, Peter once proposed putting a stack of MPLS-style labels
(or IPv4 addresses, a la LSRR) into the first bytes of an 8+8-like system.
You will see more of this later.

| In other words, v6 has neither helped nor hurt the routing problem --
| it is orthogonal.

Well, yes, that's what we've been saying all along!

Sean.

Re: Why IPv6 is a must?

[Keith Moore]

> | at present our locators are AS numbers.
> 
> No, Keith, they are not.
> 
> The AS number does not describe a location in any sort of topology.
> It is simply a representation of a set of routers with the same
> routing policy, that should not receive via eBGP NLRI which
> have originated from or passed through said routers.
> 
> The AS number is otherwise completely meaningless, although
> the AS path itself is a funny sort of non-scalar metric.
> (See the work of Ahuja and Labovitz for details on that).
> 
> A locator by definition must describe a precise location within
> a network, such that any router will be able to forward traffic
> towards that network using only the information in locator.
> 
> In IPv4, the locator *is* the IPv4 address, independent of
> what inter- or intra-domain routing system is being used.

thanks for the clarification.  I don't pretend to be a routing
expert;  I just get into these discussions in an effort to 
keep the proposed solutions for routing scalability problems
from harming applications. 

but if AS#s aren't usable as locators, it seems like 
it should be possible to use BGP to advertise mappings from 
IP address prefixes to some other kind of locator, and to 
base route computations on *those* locators rather than 
on address prefixes.  that would allow routers to 
effectively aggregate routes for dissimilar prefixes,
at least for the purpose of route computations.
(even if the forwarding table still had to be indexed
by address prefix)

> | if we change the system to use a different kind of locator we still
> | need stable addresses, we still have to maintain the mapping
> | function from addresses to locators, and we still need that mapping
> | function to be current and reliable.
> 
> End-to-end/globally-unique identifiers are very convenient indeed.
> However, identifiers and locators are different.
> There is no reason to overload them, and it's a bad habit.

there are plenty of reasons why they are overloaded, it's just that
folks tend to overloook those reasons because they are focusing
on a single problem.  some of them are outlined in another message
that I sent to the IETF list today.

> It's also a bad habit to think that locators need to be
> end-to-end or globally (rather than contextually) unique.

they don't have to be.  it's just that if the locators are 
context-specific then you can only use them for routing
within the context in which they're valid.  (and you want
to make really sure they don't get confused with locators
from other contexts)

> | what we are arguing about is the appropriate granularity of the
> | mapping function, and the appropriate place to maintain that mapping.
> 
> No, we are not arguing about that, but these are indeed issues.

I think that's the fundamental issue - at least, given the other
constraints on the problem that seem to be imposed.

Keith

Re: Why is IPv6 a must?

[Sean Doran]

Perry Metzger writes:

| Ah, but then what's your method for mapping between the two, and how
| fast must *it* run and how well does *it* scale? 
...
| I'm not saying such a thing doesn't exist. I'm just saying that I
| haven't seen a worked example I can believe in.

Stay tuned to multi6.   

We are in the process of describing the requirements and the way
IPv4 site multihoming works today precisely enough that the various
proposals that have been mooted can be adapted to support some 
superset (ideally a proper one, if possible) of those.

Please feel free to try to make sure your excellent questions and
concerns are reflected in the requirements document.   The draft
authors/editors are happy with input, and of course so are the WG chairs.

If the reqs document ends up providing a means of determining
whether a given proposal is something you can believe in,
everyone in this standards organization should be very happy.

Sean.

Re: Why is IPv6 a must?

[Sean Doran]

Keith Moore writes:

| there is another important difference between v4 and v6 - we don't have 
| enough addresses for everyone to use v4.
    (... at the same time)

That is, either some subset of everyone can use v4 with addresses
which are changed relatively infrequently, or everyone can use
v4 with addresses with relatively short leases that expire as
soon as possible as a device goes dormant.

This is locator-sharing.

| there is another important difference between v4 and v6 - we don't have 
| enough addresses for everyone to use v4 [classic].
    (... to talk to everyone else)

Or, some subset of everyone can use v4 with globally unique addresses,
or everyone can use v4 with addresses which are only locally unique
(and must therefore use translators to talk to things in other locations).

This is identifier-sharing.

Unfortunately, the overloading of locator and identifier, and
the bad habits that this overloading has engendered in people's
minds, means that neither of these is particularly palatable
at the moment, but neither are they impossible.

I agree that locator- and identifier-sharing are both non-ideal,
but they may be more practical than moving to a system which
still overloads locator and identifier in a flat address anyway.

Sean.

Re: Why IPv6 is a must?

[Sean Doran]

| at present our locators are AS numbers.

No, Keith, they are not.

The AS number does not describe a location in any sort of topology.
It is simply a representation of a set of routers with the same
routing policy, that should not receive via eBGP NLRI which 
have originated from or passed through said routers.

The AS number is otherwise completely meaningless, although
the AS path itself is a funny sort of non-scalar metric.
(See the work of Ahuja and Labovitz for details on that).

A locator by definition must describe a precise location within 
a network, such that any router will be able to forward traffic
towards that network using only the information in locator.

In IPv4, the locator *is* the IPv4 address, independent of
what inter- or intra-domain routing system is being used.

| if we change the system to use a different kind of locator we still
| need stable addresses, we still have to maintain the mapping 
| function from addresses to locators, and we still need that mapping
| function to be current and reliable.

End-to-end/globally-unique identifiers are very convenient indeed.
However, identifiers and locators are different.
There is no reason to overload them, and it's a bad habit.
It's also a bad habit to think that locators need to be
end-to-end or globally (rather than contextually) unique.

| what we are arguing about is the appropriate granularity of the 
| mapping function, and the appropriate place to maintain that mapping.

No, we are not arguing about that, but these are indeed issues.

Sean.

RE: Why IPv6 is a must?

[Sean Doran]

Peter Ford writes:

| It must change: "eventually".  For short duration changes you have
| Mobile IP.  For changes that have longer time horizon you have host
| renumbering, which by the design of v6 is now fairly trivial.   Seems
| like this base might be adequately covered, no?=20

I would love a demonstration of a painless renumbering of a large IPv6 site
over various timescales using these or other mechanisms which might
be brought forward onto the IETF standards track, and would personally
try to help get a successful demonstrator some good press attention.
Perhaps you know of some organization that could use some of that
from a Mac-wielding BSD nerd who votes in the European Union?

Small qualifier: large should be something like MIT[v4] (which has
not renumbered out of 18/8[v4], for example), rather than the largest
IPv6 sites in existence today, which I bet are somewhat smaller.

Sean.

Re: Why is IPv6 a must?

[Perry E. Metzger]

[EMAIL PROTECTED] (Sean Doran) writes:
> This link-hiding implies lots of levels [Kleinrock & Kamoun], which means 
> that either you have the same problem as Geoff in his most recent message
> (i.e., you have to do a lookup and keep the result along with the
> packet, or lots of lookups, or both), or you need a way to encode
> per-level information in the address such that it looks something
> like [.].  
> 
> The problem is that 128 bits or about 64 bits, depending on what
> semantics you put onto the addresses, is not very much room to
> encode *anything near* the number of levels K&K hierarchical network
> optimality calls for in the Internet,

Who says you need to use the IP addresses for that purpose? There is
plenty of precedent -- for a a long time we've had this notion of the
routing protocols adding labels on that had nothing to do per se with
the IP address. See the "AS" notion, for example, in which we label
various clouds with AS numbers, which are never seen by end users. It
would be straightforward enough to build a labeling scheme that was
used inside the routing protocol that stayed inside the routing
protocol. You could happily label the nodes of the routing cloud with
whatever numbering/labeling scheme you like.

If you find yourself wanting to add information like that to the
packets to help them wind their way through the network rather than
simply having the routers keep that information in hand, v6 will
happily let you tag on an option with such information as you enter a
routing cloud that needs it, or one could use encapsulation
mechanisms, putting the data "around" the packet.

In other words, v6 has neither helped nor hurt the routing problem --
it is orthogonal.

--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/

Re: ipv6 adoption....

[Keith Moore]

> these machines will have v4 but it will be a very long time
> before they have v6.  why? because they are very resource
> constrained, nobody will spend money near-term for dual-stack,
> and a v4 product you can ship today.

you can also ship v6 today, with the v4 sites using 6to4.  the main 
barrier is not lack of hardware to support such a configuration, but 
lack of mindshare.  it will come.

Keith

Re: Why IPv6 is a must?

[Keith Moore]

> I disagree with Keith on some basic assumptions.  IPv6 is not a software
> upgrade in its' dominant mode.   

actually, I think we do agree.  *existing* systems can migrate to IPv6 
with a software upgrade, and it's important to have a story for existing
systems.. but my guess is that the vast majority of IPv6 systems in the 
long run will not be general-purpose computers (existing or new), but 
fixed-function appliances that will ship with IPv6 built-in.

Keith

Re: Why is IPv6 a must?

[Sean Doran]

Perry Metzger writes:

| You seem to dismiss link state offhand, but it
| isn't clear that link state couldn't help out a lot here. (Neither is
| it clear that it could but it appears to be an interesting area for
| some experiments.)

Actually, I'm a fan of link state (ask Sue Hares or Dave Ward & company),
but unfortunately there are lots of links in the Internet, so you
have to hide them.  If you don't, your graph-sort takes forever.

This link-hiding implies lots of levels [Kleinrock & Kamoun], which means 
that either you have the same problem as Geoff in his most recent message
(i.e., you have to do a lookup and keep the result along with the
packet, or lots of lookups, or both), or you need a way to encode
per-level information in the address such that it looks something
like [.].  

The problem is that 128 bits or about 64 bits, depending on what
semantics you put onto the addresses, is not very much room to
encode *anything near* the number of levels K&K hierarchical network
optimality calls for in the Internet, let alone the sort of disjoint
hierarchies and confederations thereof that one would want in a
more policy-rich Internet.   But, a variable-length field means
new syntax means it's not IPv6 or IPv4 at all.

Sean.

Re: Why is IPv6 a must?

[Keith Moore]

> I was merely pointing out that your catechismic canard about "no fully worked
> out example of separating location and identity" is ludicrous on its face,

usually when people talk of the problem as one of separating location and
identity, they haven't clearly defined the problem, or they're only
looking at one part of the problem (whereas someone else using the
same problem description may be looking at a different part of the problem)

The IP address is commonly used as, or as part of, at least the following:

- host identity 
- host-to-network interface identity
- location of the host's network interface relative to the network topology
- application rendezvous point (socket or process identity)
- service identity (where the service can consist of multiple hosts)
- TCP connection state identity
- remote host identity (for rtt estimation)

this is just off the top of my head, and it doesn't even consider mobile IP
or most kinds of NATs.

the problems caused by the overloading are mostly that it is very 
difficult for any of these identities to change relative to the others -
the mapping function between them is assumed to be the identity, and 
this assumption is wired into countless pieces of code.

but if you build a "solution" that lets you separate one of these functions
from another, it gives you only one additional degree of freedom - it 
doesn't "solve" the problems resulting from the other kinds of overloading.
for instance you can separate "host identity" from location for the purpose
of authentication, but it still doesn't let you change the host's address
without breaking the utility of that address as a rendezvous point in a 
distributed system. 

and yet you clearly don't want separate values for each of these - 
this would add a tremendous amount of complexity and overhead.  

nor does it appear to be a good idea to assume that these values will
always be separate - for instance, there's an argument that stationary
hosts are common enough that you want to optimize for that case - 
you want to support mobile hosts but you don't want to pay for the 
extra layer of indirection/lookup when sending packets to stationary hosts.


Keith

Re: Why is IPv6 a must?

[Sean Doran]

Geoff Huston writes:

| If you look away from an address -based hierarchy and define other objects 
| as the 'atoms' of a routing system then there may be some benefit. Even 
| today, with some 105,000 objects in the routing table (*) there are only 
| some 12,000 AS's (*) and 15,500 AS paths selected (*). This tends to 
| indicate that grouping addresses not by bit boundaries, but by origin AS's 
| has some potential, in my view (*). 

Unfortunately, a view of the universe of AS paths is anisotropic.
Your view and mine differ.   Moreover, your view has benefited from
filtering done by people with closer views of things far away from
you, who then pass along information in a way reminiscent of the
children's game of "broken telephone".   In that game, a complicated
message is whispered from child to child until the last child to
hear the message is asked to try to reconstruct the original message.
The results are often funny.   Try it at home.

While some good comes from "broken telephone" (passing along what
you select, rather than what you hear) in the global routing system,
in the form of information hiding, the grim news is that the atoms
are far from indivisible.   Some split pretty regularly, with a prefix
heard along one AS path at one moment, and then along another -- shorter
or longer, perhaps -- at another moment.   Not to mention the prefixes
which grow (revealing more, often longer AS paths) and shrink (aggregating
which eliminates AS paths).

While it is tempting to consider a message that says, "this AS Path is
invalid for all prefixes", it is not computationally practical to 
compress the on-the-wire message (saving space) in favour of
maintaining an association between AS paths and prefixes (requiring
space and/or computation), and dealing with prefixes which share
AS paths but which do not share other attributes (e.g. communities,
or in some implementations, origins).  

Moreover, it would be another example of overloading of the AS path,
which is already used as a funny sort of metric as well as an announcement-
loop-prevention mechanism.   Using it as a tag to consolidate
reachability information may not seem s different from AS-path
filtering (e.g., ignore ^3561 174_), but such filters are static
and local, and really are used to constrain metric-exploration in
the event of a failure (of e.g. ^174_, which we don't want to try
to find behind 3561 when the direct link(s) fail).

| there are other ways to look at the network that also provide 
| some tractable level of grouping that could make interdomain routing scale. 

That's good to know, but I haven't seen them described that I remember.
Do you have pointers, please?

| Some approaches, like an AS-based approach, 
| attempt to bypass an effort to structure the address space as the 
| aggregateable element of the routing system, and the corollary is that the 
| approach has pretty much the same leverage in a V4 world, a V6 world, or a 
| heterogeneous world.

I think you are trying to say that it should be possible to
use a lookup on the IP (whatever v number) address and find
some description of a location in the network.   This is
a good idea, and is part of separating location and identity,
but unfortunately you would have to do the lookup at each
hop, or throw away the hop-by-hop model and use "aggregate flows"
along the lines of MPLS LSPs (or some other tunnel/map-and-encap system),  
or rewrite the addresses into a form that does not need
to be looked up at subsequent hops (but which can be rewritten
back to the original form at/near the destination), along the lines
of 8+8.  Note that I ranked those three options by increasing amount
of difficulty of implementation and operation, from my perspective.

| * Your mileage may vary.

My mileage is kilometreage. :-)

Sean.

Re: Why IPv6 is a must?

[Keith Moore]

> The problem of maintaining hierarchical routing is identical with
> ANY way of describing a device in ANY network: the locator MUST
> change with a change in location.

perhaps, but the locator doesn't have to be exposed in the address.
if you expose the locator in the address then every time the location
changes you have to somehow inform all parties that are using that 
location that there's a new location for that address.

at present our locators are AS numbers.  they are not exposed in the
address or to hosts; instead there is a mapping function from address 
prefixes to AS numbers that is maintained by routers.

if we change the system to use a different kind of locator we still
need stable addresses, we still have to maintain the mapping 
function from addresses to locators, and we still need that mapping
function to be current and reliable.

what we are arguing about is the appropriate granularity of the 
mapping function, and the appropriate place to maintain that mapping.

Keith

RE: Why IPv6 is a must?

[Peter Ford]

> the locator MUST change with a change in location.

It must change: "eventually".  For short duration changes you have
Mobile IP.  For changes that have longer time horizon you have host
renumbering, which by the design of v6 is now fairly trivial.   Seems
like this base might be adequately covered, no? 

> unfortunately, variable-length addresses are not supported by IPv6.

The good news here is that IPV6 picked worst case length viz the
original CLNS addressing design when you factor out length, AFI and
country codes, so you are covered.  The biggest reasons to have variable
length addresses is: 1) so you can have short packets!, and 2) because
2**128 is not enough hosts!  We gave up on (1) and (2) is just another
opportunity for NATs and Proxies in the 22nd century.

I suspect the addressing plan for the Internet will go through it's
bumps and grinds.   Again, the good news here is that IPv6 has plenty of
addressing bits for "routing" so that people can screw up and recover,
something that IPv4 no longer has.  

>   Sean.

Cheers, peterf

RE: Why IPv6 is a must?

[Sean Doran]

Peter Ford post ROAD writes:

| I concur that the routing guys have some work in front of them.   May I
| suggest people take a closer look at hierarchical routing, combined
| provider and geographic hierarchies, and adult supervision?

All of these have been well-studied with IPv4.

Unfortunately, there is no known (to the IETF) way of preserving
hierarchy in the absence of host renumbering (of locator-part), 
careful use of multiple locators by hosts, or NAT, which is a way a 
middle-box can  "spoof" one of the previous two options.

The problem of maintaining hierarchical routing is identical with
ANY way of describing a device in ANY network: the locator MUST
change with a change in location.

Keeping the location independent of the identity of a device
makes this task much easier, especially when a minimal number
of things running on the host have to know about the location
at all.  (i.e., it's great if the host doesn't need to know its
location at all, at any time, thus allowing in-flight mutations
of the locator at will as the network changes shape -- the host
should not reject packets meant for itself (identity) just because
they have been sent to a "surprising" (to the host) location).

There are alternatives to a complete separation of identity and
location, but most of them result in NAT-like localization of
identity (i.e., identity is not end-to-end) or things like UUCP bang
paths or vaguely CLNS-style names, and unfortunately, variable-length
addresses are not supported by IPv6.

Sean.

Re: Why is IPv6 a must?

[Perry E. Metzger]

[EMAIL PROTECTED] (Sean Doran) writes:
> | My own feeling is that we're just going to have to accept the notion
> | of our routers having millions of routes in them and go for algorithms
> | that scale better than distance vector or path vector so we don't
> | drive them into the ground while doing the computations.
> 
> While I think that you're not exactly using the term "algorithm" right,
> I do think you have a point that another system which is more desirable
> than RIP with funny non-scalar metrics is desirable.   Unfortunately,
> all the ones I know about do have annoying problems with algorithms having
> poor scaling properties as one increases the amount of state known by 
> any node in the distributed computation.   In other words, switching 
> to LS or any other known routing system does not help us: we take a 
> LONG time to compute when there alot of information, and while the 
> side-effects of that vary from system to system, they are pretty much 
> universally unpleasant.

I think algorithm is the right word to use here because we're down at
the complexity theory of the algorithms level, and graph algorithms
are the core of the whole problem. One of the interesting questions
seems to be one of how much preserving partial results of earlier
computations helps in the face of incremental updates arriving. We
need scaling that behaves well not only in the number of nodes but
also in the number of arriving updates. Path vector is badly unstable
as the updates come in. You seem to dismiss link state offhand, but it
isn't clear that link state couldn't help out a lot here. (Neither is
it clear that it could but it appears to be an interesting area for
some experiments.)

> Meanwhile, please accept that separating identity from location is
> a means to allow one to aggressively constrain the amount of global
> knowledge by hiding the topological state of most distant network
> elements, at the cost of maintaining a mapping between _what_ and _where_.

Ah, but then what's your method for mapping between the two, and how
fast must *it* run and how well does *it* scale? I've yet to see
something that seems to sound like it would work well. I've also yet
to see a proposed system that actually reduces the complexity of the
routing portion of the problem either.

I'm not saying such a thing doesn't exist. I'm just saying that I
haven't seen a worked example I can believe in.

> | We can't get
> | rid of the desire to have huge numbers of routes so we have to find
> | ways to avoid nuking ourselves when we have huge numbers of routes.
> 
> You haven't been paying attention to multi6.  That is EXACTLY the desire
> there, and it cuts across provider/researcher/vendor/implementor boundaries.

I have been paying attention, actually. I know what the desire is. I
just don't yet know that it is realizable. Even if we can reduce to
some extent the pressure to inject routes for networks with multiple
connection points, we can't eliminate it, and as the number of
carriers and interconnects rises and the number of "big" end customers
rises it feels like one ultimately is going to have to deal with huge
numbers of routes. Multi6 and such seem like they will at best take a
constant factor off of "huge". We still have to plan for "huge".

> Your noisemaking here on the main IETF list is counter-productive
> and childish.

Your opinion is noted.

--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/

Re: Why is IPv6 a must?

[Keith Moore]

> There is an important difference between v4 and v6 - we've already paid the
> (by now massive) deployment costs of v4.

there is another important difference between v4 and v6 - we don't have 
enough addresses for everyone to use v4.

> It would be nice if going through the immense upheaval and cost of deploying
> 6 (or whatever our next big step is) actually got us a solution to one of
> our most pressing real problems.

yes, it would.  but that has to be balanced against the cost of 
second-system effect.

Keith

Re: Why is IPv6 a must?

[Sean Doran]

Perry -

|  the folks deploying v6 are doing something
| about the problem -- they've got running code and running networks and
| running applications -- and you're bitching in the hotel bar at the IETF.

No, I don't think he is.   In fact, you would be hard pressed
to find Noel showing up at an IETF meeting.

With the hostility towards people who don't accept what you have
to say without some scepticism, I really don't blame him at all.

Frankly, I'm tempted to do the same, only there *are* some sane
and reasonable voices in support of making IPv6 work well enough
that it's deployable on a large scale, when it's seriously needed.

Sean.

P.S.:

| My own feeling is that we're just going to have to accept the notion
| of our routers having millions of routes in them and go for algorithms
| that scale better than distance vector or path vector so we don't
| drive them into the ground while doing the computations.

While I think that you're not exactly using the term "algorithm" right,
I do think you have a point that another system which is more desirable
than RIP with funny non-scalar metrics is desirable.   Unfortunately,
all the ones I know about do have annoying problems with algorithms having
poor scaling properties as one increases the amount of state known by 
any node in the distributed computation.   In other words, switching 
to LS or any other known routing system does not help us: we take a 
LONG time to compute when there alot of information, and while the 
side-effects of that vary from system to system, they are pretty much 
universally unpleasant.

On the other hand, if you have something like a graph-sorting algorithm
that exhibits nearly linear scalability, there are alot of people
here who would like you to describe it in public!

Meanwhile, please accept that separating identity from location is
a means to allow one to aggressively constrain the amount of global
knowledge by hiding  the topological state of most distant network
elements, at the cost of maintaining a mapping between _what_ and _where_.

If you can't accept that, whether it's said by me or by Geoff Huston
the other day, or by any other party, well, then there really is no point in
all this posturing.  It's not going to get you laid.

| We can't get
| rid of the desire to have huge numbers of routes so we have to find
| ways to avoid nuking ourselves when we have huge numbers of routes.

You haven't been paying attention to multi6.  That is EXACTLY the desire
there, and it cuts across provider/researcher/vendor/implementor boundaries.

Your noisemaking here on the main IETF list is counter-productive and childish.

Re: ipv6 adoption....

[Perry E. Metzger]

"Mike O'Dell" <[EMAIL PROTECTED]> writes:
> anyone imagining that ipv6 will get an observable percentage
> of total endpoint penetration any time soon only needs to look
> at the onslaught of microcontrollers starting to ship with
> IPv4 technology integral to them.

Now that I'm in the embedded operating system business, allow me to
mention that IPv6 has started showing up as a customer demand
item. And no, I didn't induce that. (We ship with v6 of course, but
the fact that people have asked us about v6 independently has been an
interesting surprise.)

> also note that a number of chip makers are doing "hardware"
> implementations of ipv4 stacks, up to and through transport
> level crypto.

Not quite. Chips like the various IBM 4xx series CPUs with
pico-processor mixins and and the Intel IXP1200 and such have
significant amounts of stack processing built in, but it isn't really
hardwired to v4. These "picoprocessors" aren't very smart, but they
aren't quite "v4 hardcoded" either.

I've seen tell of other units that have v4 hardwired in for purposes
like the ones you mention (i.e. smart toasters) but mostly what one
finds is that there are units with v4 microcode -- it isn't really in
the metal.

> ipv6 may eventually be visible, but i predict most people
> currently reading this will have grandchildren using ipv4
> technology, whether they want to or not.

Entirely possible. However, there will probably be people still using
X.25 in 20 years. The question is, though, how many.

I would by no means refer to the current number of v6 users as
significant from a global market perspective. It isn't. The number of
v6 users currently is many orders of magnitude smaller than the v4
world. However, nothing like this happens instantly, and the TREND is
pretty damn astonishing. I hadn't even sent a single v6 packet a
couple of years ago, and now many of my geek friends have v6 running
in their homes and offices, and I didn't give them help OR prompt
them. What's more, they've actually got a use for v6 for things like
NAT penetration. They can ssh to a specific machine in their home
network even though the cable modem only has one v4 address to give
out. Now we're talking about a tiny number of systems experts here
who're either using open source OSes or were (before XP) patient
enough to install the MS Research stack, but it is very different from
the days a couple of years ago where even v6 hackers never used v6.

Hell, I roamed onto a university campus wireless network not that long
ago, and for the hell of it sent out a router discovery message and
found myself on the 6bone. No, not quite the same as finding my
dentist using v6, but an astonishing trend, even from the point of
view of my wildest dreams.

I think we're still going to be below "observable user threshold" for
a while to come even while this growth continues. How long? I'm
planning on doing some quantitative analysis for a talk I'm giving in
a few weeks. I'll try posting results when I have them. Off the cuff,
I don't expect anything to show up in network statistics for a year or
two, but I'll know better soon.

--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/

Re: Why is IPv6 a must?

[J. Noel Chiappa]

> From: "Perry E. Metzger" <[EMAIL PROTECTED]>

>> ??? I said nothing about Mobile IPv6 being a solution to the routing
>> problem.

> We were talking about the routing problem. If you just brought it up to
> be clever (which I assume you did), you didn't further the discussion.

I was merely responding to your (incorrect) initial assertion that:

  People frequently propose "endpoint identifiers" and "routing identifiers"
  be separated but no one has ever come up with a worked proposal that was
  less flawed than the current mechanism.

I have no interest in discussing the "routing problem". Been there, done that.

(Also, the business of separating identity in location is really not related
to routing. It happens to be a good thing to do on basic grounds, but it does
also make some routing-related things easier. E.g. it can help with
renumbering and dynamic multi-homing; in certain transition schemes for
deployment of new routing architectures it makes the deployment of new
namespaces for location easier; etc, etc.)


> My own feeling is that we're just going to have to accept the notion of
> our routers having millions of routes in them and go for algorithms
> that scale better than distance vector or path vector

There are no such algorithms, and it's highly unlikely there will ever be a
routing algorithm for flat addresses that scales as O(logN), or anything like
that. The only solution to scaling routing overhead is to use
abstraction/aggregation.

Noel

Re: Why is IPv6 a must?

[Geoff Huston]

>
>Quite simply, a bunch of us *are* searching for a paradigm shift.  Geoff's 
>good work in this area reveals the complexity of the whys and wherefores 
>of the routing system.  Given that 8+8 was a serious consideration (and to 
>some deserves some amount of revisiting -- at least as a starting point), 
>I don't believe we can say that the deployment of v6 is completely 
>divorced from the routing system.  8+8 is merely an existence proof of how 
>the routing system and v6 can be intertwined, for better or worse.

As I tried (probably poorly) to indicate in my last posting on this topic 
there are a number of different directions you can take when searching for 
a lever to use to handle scaleable routing. Our recent experience with V4 
using an address-based hierarchy tends to indicate that the hierarchy leaks 
- i.e. attempting to align the structure of the network into a hierarchy 
and aligning addresses to conform to this same hierarchy is not an easy 
task and it tends to break down in the face of increased interconnectivity 
at the edge (multi-homing) and in the middle (peering and multi-transits). 
If you look away from an address -based hierarchy and define other objects 
as the 'atoms' of a routing system then there may be some benefit. Even 
today, with some 105,000 objects in the routing table (*) there are only 
some 12,000 AS's (*) and 15,500 AS paths selected (*). This tends to 
indicate that grouping addresses not by bit boundaries, but by origin AS's 
has some potential, in my view (*). If you take this AS-based perspective 
the issue of V4 / V6 tends to be less important than if you take an address 
hierarchical perspective. I note the AS-based approach to hierarchies as an 
example - there are other ways to look at the network that also provide 
some tractable level of grouping that could make interdomain routing scale. 
The point is that the degree to with the inter-domain routing issue is 
intrinsically liked to the address structure within the protocol depends on 
the approach used by routing. Some approaches, like an AS-based approach, 
attempt to bypass an effort to structure the address space as the 
aggregateable element of the routing system, and the corollary is that the 
approach has pretty much the same leverage in a V4 world, a V6 world, or a 
heterogeneous world.

Geoff


* Your mileage may vary.

Re: Why is IPv6 a must?

[J. Noel Chiappa]

> From: Robert Elz <[EMAIL PROTECTED]>

>> "no fully worked out example of separating location and identity"
>> ... given the existence of an *IPv6* mechanism that does just that.

> this is really not a very realistic claim.
> Mobile IP doesn't separate location and identity really - the location
> of the home agent is an important part of the identity of the mobile
> node.

The home agent is not involved in the identification of the mobile node,
which is expressed solely by its "home address", in packets sent to it (see
the discussion of sending packets to a mobile host, Section 8.9. of the IPv6
Mobility spec, "Sending Packets to a Mobile Node" - this is the version 12
draft I'm looking it, it may have moved since).

You have an point that the home agent is tied in, but it's only because it is
being used as a rendezvous mechanism (i.e. once a node has "gone mobile", how
do you get in touch with it) - but that's quite a different beast. (The home
agent is also used as an error recovery mechanism, for cases where the
correspondent node loses track of the current location of the mobile node,
but the mechanism works the same in either case.)

In other words, what is being overloaded onto the home address in this case
is nothing to do with the location of node (the other function we were
discussing of the address), but rather a toehold for the rendezvous mechanism.

(It's clear that rendezvous/error-recovery is indeed a separate function,
since some other scheme for separating location and identity could use some
entirely different mechanism for rendezvous and error. Such a mechanism
might, for instance, make it possible to move the rendezvous point to a
location other than the node's "home" location.)

So there are really three functions being served by the IPv6 address - host
identification, rendezvous toehold, and host location. Once a node has gone
mobile, the latter function is indeed fully split off into the care-of
address.


> So, while the location and identity of the mobile node itself may
> have been unlinked, the two concepts haven't been

I'm a bit puzzled as to how you can agree that "the location and identity of
the mobile node ... [has] been unlinked", but still argue that "the two
concepts haven't been". This is some sort of very fine hair-shaving indeed.

Noel

RE: Why IPv6 is a must?

[Peter Ford]

I disagree with Keith on some basic assumptions.  IPv6 is not a software
upgrade in its' dominant mode.   IPv6 was done with the belief that the
raw number of systems will grow huge enough that 2**32 is not enough.
There was this CIDR thing created to solve this other problem.


In terms of raw numbers, IPv6 deployment will take the form of hardware
purchases for IPv6 nodes that do not exist today:

1) Cell phones (historically <2 yr replacement cycle)
2) PCs with IPv6 installed (less than 5 yr replacement cycle)
3) new devices that plug into residential networks (mostly new)

We should note IPv6 has been planned, products have been built and
deployment will occur.  It is being driven by people who have a vested
interest in having a solution to the address run-out problem.

(good news in the last 10 years is that Internet has gotten really good
at deploying HTTP proxies, something we did not really bet on back in
1991/1992.   This is going to aid transition immensely as we move
forward).

I concur that the routing guys have some work in front of them.   May I
suggest people take a closer look at hierarchical routing, combined
provider and geographic hierarchies, and adult supervision?

Regards, peter

ipv6 adoption....

[Mike O'Dell]

Perry,

anyone imagining that ipv6 will get an observable percentage
of total endpoint penetration any time soon only needs to look
at the onslaught of microcontrollers starting to ship with
IPv4 technology integral to them.

the microcontroller universe outnumbers everything else
by a huge margin, so it doesn't take a very large penetration
of that space to make incredible numbers, and at the rate
that's growing, it will be a substantial penetration.

these machines will have v4 but it will be a very long time
before they have v6.  why? because they are very resource
constrained, nobody will spend money near-term for dual-stack,
and a v4 product you can ship today.

also note that a number of chip makers are doing "hardware"
implementations of ipv4 stacks, up to and through transport
level crypto.  i'm not suggesting i think this is unilaterally a great
idea (quite the contrary), but they are being built and getting
designed into things.  some of these are "TCP UARTS", designed
to let really simple systems suddenly become web and internet
enabled, and others are designed to be high-performance devices
to offload some server processing.  again, they are getting
designed into things and once there, essentially immutable.

ipv6 may eventually be visible, but i predict most people
currently reading this will have grandchildren using ipv4
technology, whether they want to or not.

the first window for real volume penetration has been lost.

whether there will be another window is yet to be seen.

this is neither an attack on or defence of anything - it's
just my reading of the forces at work.

cheers,
-mo


=
Office:
Mike O'Dell, President
Compass Rose Labs
3143 Cobb Hill Lane
Oakton VA 22124
v: 703-620-2265
f: 703-620-1779
e: [EMAIL PROTECTED]

Assistant:
Mary Richards
v: 703-754-6338
e: [EMAIL PROTECTED]

Re: Why is IPv6 a must?

[Perry E. Metzger]

"J. Noel Chiappa" <[EMAIL PROTECTED]> writes:
> ??? I said nothing about Mobile IPv6 being a solution to the routing problem.

We were talking about the routing problem. If you just brought it up
to be clever (which I assume you did), you didn't further the
discussion.

Lets deal with the situation on the ground. It is costing
organizations vast amounts of money to deal with NAT. It is causing
serious disruptions in our infrastructure and protocols to deal with
NAT. v6, which is (believe it or not) being deployed lets us get past
the address space exhaustion problem. Whether you like the fact that
it doesn't solve everything or not, it is the only available solution
to a very real problem.

Or to put it another way, the folks deploying v6 are doing something
about the problem -- they've got running code and running networks and
running applications -- and you're bitching in the hotel bar at the
IETF. v6 is even in Windows XP. Deployment wins.

So we are left with the routing problem.

My own feeling is that we're just going to have to accept the notion
of our routers having millions of routes in them and go for algorithms
that scale better than distance vector or path vector so we don't
drive them into the ground while doing the computations. We can't get
rid of the desire to have huge numbers of routes so we have to find
ways to avoid nuking ourselves when we have huge numbers of routes. It
would be nice if we could come up with the perfect new architecture
but no one has yet designed it.

--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/

Re: Why is IPv6 a must?

[Robert Elz]

Date:Mon, 12 Nov 2001 11:14:06 -0500
From:"J. Noel Chiappa" <[EMAIL PROTECTED]>
Message-ID:  <[EMAIL PROTECTED]>

  | I was merely pointing out that your catechismic canard about "no fully
  | worked out example of separating location and identity" is ludicrous
  | on its face, given the existence of an *IPv6* mechanism that does just that.

Aside from mobile IP being just as much v4 as it is v6, this is really
not a very realistic claim.

Mobile IP doesn't separate location and identity really - the location
of the home agent is an important part of the identity of the mobile node.
So, while the location and identity of the mobile node itself may have been
unlinked, the two concepts haven't been, so as a counter example, this is
useless.

It would truly have been nice if IPv6 could have done something to solve the
routing problems - but we don't have the answer to that yet.   And we really
couldn't afford to wait for the answer.

There were two problems facing us 10 years ago - the exhaustion of the
address space, and (recognised a little later) the routing table growth.

The first of those is, unfortunately, a very hard limit - eventually there
will be absolutely no free addresses left at all.  That one simply had to
be solved by a change of the protocols.   No question about it at all.  It
is also, a pretty trivial change to make.   Notwithstanding that, 10 years
later, real deployment is just beginning.

On the other hand, the routing table growth doesn't necessarily need anything
new at all - maybe it will, once a solution is found.   Maybe it won't.
Two things are clear however - first, had we waited until a solution was
found to design the next generation IP, we'd still be waiting (to start).
That is, deployment would be (at least) another 10 years away.   And second,
routing table growth can certainly be handled by simply throwing large
amounts of money at the problem - perhaps prohibitively large, but it is
possible to keep functioning that way (we can build processors with gargantuan
address spaces, we can supply them with monstrous amounts of RAM, we can
install fibre with (close to if not) terrabit rates, to carry the info, and
we can parallelise the routing computations (at least for DV/PV protocols
like BGP) and throw lots of past processors at the problem.   That's a pretty
brutal thing to contemplate, and would make the net much more expensive for
everyone - but at least there is no hard limit out there (note we have
already gone past the routing table sizes that people were claiming would be
too big to handle, back in the early days).

I certainly would have preferred a more radical next generation IP than
the one we're getting, but I certainly wouldn't want to still be waiting
for anything to have been done at all.

kre

Re: Why is IPv6 a must?

[J. Noel Chiappa]

> From: "Perry E. Metzger" <[EMAIL PROTECTED]>

>>> The fact that it does not solve the global routing table meltdown is,
>>> according to such people, an obvious failure of v6 -- never mind that
>>> they are unrelated issues.

>> How does the fact that they are somewhat unrelated issues in any way
>> refute the criticism of IPv6 regarding its lack of a solution to
>> routing issues?

> It is a silly criticism. It is like criticizing antibiotics for only
> curing bacterial infection and not AIDS. "They're obviously useless.
> Lets dump them."
> If v6 is flawed in this regard, well then so is v4.

There is an important difference between v4 and v6 - we've already paid the
(by now massive) deployment costs of v4.

It would be nice if going through the immense upheaval and cost of deploying
v6 (or whatever our next big step is) actually got us a solution to one of
our most pressing real problems.

Noel

Re: Why is IPv6 a must?

[J. Noel Chiappa]

> From: "Perry E. Metzger" <[EMAIL PROTECTED]>

>>> People frequently propose "endpoint identifiers" and "routing
>>> identifiers" be separated but no one has ever come up with a worked
>>> proposal that was less flawed than the current mechanism.

>> the IPv6 protocol suite contains a very nicely worked out mechanism
>> which does *exactly* this!
>> It's called Mobile IPv6, and the "care-of address" in the basic IPv6
>> header is exactly the "routing identifier", whilst the home address in
>> the IPv6 routing header is the "endpoint identifier".

> That doesn't actually fix the problem, Noel. If you don't have an
> underlying functioning network with scalable routing even if all
> systems were running on the mobile protocols it still wouldn't work.

??? I said nothing about Mobile IPv6 being a solution to the routing problem.

I was merely pointing out that your catechismic canard about "no fully worked
out example of separating location and identity" is ludicrous on its face,
given the existence of an *IPv6* mechanism that does just that.

Noel

Re: Why is IPv6 a must?

[Perry E. Metzger]

"J. Noel Chiappa" <[EMAIL PROTECTED]> writes:
> > From: "Perry E. Metzger" <[EMAIL PROTECTED]>
> 
> > People frequently propose "endpoint identifiers" and "routing
> > identifiers" be separated but no one has ever come up with a worked
> > proposal that was less flawed than the current mechanism.
> 
> I always find it incredibly funny when IPv6 proponents roll out this tired,
> worthless canard - because the IPv6 protocol suite contains a very nicely
> worked out mechanism which does *exactly* this!
> 
> It's called Mobile IPv6, and the "care-of address" in the basic IPv6 header
> is exactly the "routing identifier", whilst the home address in the IPv6
> routing header is the "endpoint identifier".

That doesn't actually fix the problem, Noel. If you don't have an
underlying functioning network with scalable routing even if all
systems were running on the mobile protocols it still wouldn't work.

People want to dual home their networks for redundancy and
reliability. This leads to an explosion in the size of the routing
tables. We unfortunately don't know a way to fix that. Even if you
renumbered the whole net ever 10 seconds through some miracle, you'd
still need routes to all those folks to be propagated through the
default free zone. That means if you have 100,000 networks with
multiple ingress paths, you still need that many routes. If you have a
million networks with multiple ingress paths, you need that many
routes. It doesn't matter if everyone uses the mobile addresses as
their "endpoint identifiers". 

> What's especially amusing is that although I keep pointing this wonderfully
> ironic and devastating counter-argument out,

It is ironic and devastating TO YOU. It isn't particularly interesting
to the rest of us.



--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/

Re: Why is IPv6 a must?

[Perry E. Metzger]

"J. Noel Chiappa" <[EMAIL PROTECTED]> writes:
> > The fact that it does not solve the global routing table meltdown is,
> > according to such people, an obvious failure of v6 -- never mind that
> > they are unrelated issues.
> 
> How does the fact that they are somewhat unrelated issues in any way refute
> the criticism of IPv6 regarding its lack of a solution to routing issues?

It is a silly criticism. It is like criticizing antibiotics for only
curing bacterial infection and not AIDS. "They're obviously
useless. Lets dump them."

If v6 is flawed in this regard, well then so is v4.

> The reasoning here is faulty. The fault lies in the assumption that whatever
> fix is found can be deployed in IPv4 (and thus, since the two are so similar,
> in IPv6). In fact, many people see IPv4 as fundamentally flawed in its basic
> structure, when it comes to supporting a true "next generation" routing
> architecture - and so, by extension, IPv6 is equally fundamentally flawed
> (since it's just IPv4 with a large address).

Well, Noel, we've been waiting some years for someone to descend from
heaven with parchment scrolls describing the perfect internet in their
hands, but unfortunately we have to keep the net working now, since we
don't know when they might deign to arrive.

(And yes, Noel, we know that you've already described the complete
solution and if only we would read the documents which we've all
ignored so callously...)

--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/

Re: Why is IPv6 a must?

[Perry E. Metzger]

Keith Moore <[EMAIL PROTECTED]> writes:
> > Quite simply, a bunch of us *are* searching for a paradigm shift.  
> 
> Indeed.  But a satisfactory one hasn't been found yet.  

And, absent one, we have to keep making the net work.

By the way, if the rate of v6 adoption is any indication, v6 is doing
very healthily indeed. It isn't obvious to the greater world, but it
has almost certainly hit an exponential growth phase. Yes, we're still
talking about an infinitesimal fraction of the number of users v4 has,
but I now find it routine to discover that mail or http or ftp
connections to a host I've never heard of before are going over v6
when it used to be a thing that only happened deliberately. There are
a couple of orders of magnitude more users than a year ago -- I'm
going to work on some estimates of numbers and the growth for a talk
I'm giving in December and I'll post them here when I have them.

--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/

Romeo Saverio

[Saverio Romeo]

I'm an italian researcher in Content Delivery Networks. From two weeks I've
started
my work about CDN and I've some doubts about DNS Requesting Routing. I read
the relative draft, but I'd 
like to see an example.
Thanks a lot
Saverio Romeo 

Romeo Saverio 
Area Network System
Cefriel 
Milan- Italy

Re: Last Call: Date and Time on the Internet: Timestamps to Proposed Standard

[John Stracke]

Doug Royer wrote:

>Why not just specify that dates/times are RFC2445 compliant?
[...]
>We decided on ONE format for date time based on ISO-8601
>
>MMDDTHHMMSS [+/- ...]

Not quite; RFC-2445 doesn't have the UTC offset.  (See section 4.3.5 of 
RFC-2445; at the bottom of page 35, it says, "The form of date and time with UTC 
offset MUST NOT be used".)  This was 
debated in the IMPP group; some suggested forgetting about timezones and 
just specifying that all timestamps had to be in UTC.  The counterargument 
was that knowing somebody's timezone offset helps you guess whether he's 
likely to be in the office, etc.

I did argue for using the pure-numeral form from RFC2445, until it was 
pointed out that we had to add the offset, which meant breaking 
compatibility with 2445 anyway.

/=\
|John Stracke|Principal Engineer  |
|[EMAIL PROTECTED]   |Incentive Systems, Inc. |
|http://www.incentivesystems.com |My opinions are my own. |
|=|
|I used to belong to a solipsism club, but I got bored & voted|
|everybody else out.  |
\=/

Re: Why is IPv6 a must?

[J. Noel Chiappa]

> From: "Perry E. Metzger" <[EMAIL PROTECTED]>

> People frequently propose "endpoint identifiers" and "routing
> identifiers" be separated but no one has ever come up with a worked
> proposal that was less flawed than the current mechanism.

I always find it incredibly funny when IPv6 proponents roll out this tired,
worthless canard - because the IPv6 protocol suite contains a very nicely
worked out mechanism which does *exactly* this!

It's called Mobile IPv6, and the "care-of address" in the basic IPv6 header
is exactly the "routing identifier", whilst the home address in the IPv6
routing header is the "endpoint identifier". (Don't be confused by the fact
that the two identifiers are from the same namespace - the functionality is
exactly that proposed in other schemes, although they vary the two namspaces
to better suit each to their particular function.)


Needless to say, the sight of IPv6 proponents ranting about how nobody has
ever come up with a fully specified way to do this, while the protocol they
are defending contains, apparently unbeknown to them, the perfect
counter-evidence to this sterile claim, is extremely educational as to the
general clue level.

What's especially amusing is that although I keep pointing this wonderfully
ironic and devastating counter-argument out, some IPv6 proponents keep
trotting out this same old lame, bogus point. Oh well, perhaps eventually
these simple points will sink in. In the meantime, perhaps the crack IPv6
"spin team" needs to update the "talking points" that people are working
from, and make sure that such obvious howlers don't continue to embarass them.

Noel


PS: Additional irony can be obtained from the intense assertion that since a
perfectly finished worked mechanism is (supposedly) not in evidence, that the
idea is therefore a bad one which should be ignored. Too bad this standard
wasn't applied when IPv6 was picked, back in 1994 (or whenever it was - it's
been a long time) - we wouldn't be inflicted with it now.

Re: Why is IPv6 a must?

[J. Noel Chiappa]

> From: "Perry E. Metzger" <[EMAIL PROTECTED]>

> There is a school of thought that seems to believe that IPv6 is a
> failure because it only solves a quite narrow although extremely
> important problem -- specifically address space exhaustion.

> The fact that it does not solve the global routing table meltdown is,
> according to such people, an obvious failure of v6 -- never mind that
> they are unrelated issues.

How does the fact that they are somewhat unrelated issues in any way refute
the criticism of IPv6 regarding its lack of a solution to routing issues?

> As you note, there is no distinction between solving the global routing
> problem in a v4 or v6 context. The same algorithms can be used for
> either. If new algorithms are developed, they can be deployed for
> either.

The reasoning here is faulty. The fault lies in the assumption that whatever
fix is found can be deployed in IPv4 (and thus, since the two are so similar,
in IPv6). In fact, many people see IPv4 as fundamentally flawed in its basic
structure, when it comes to supporting a true "next generation" routing
architecture - and so, by extension, IPv6 is equally fundamentally flawed
(since it's just IPv4 with a large address).

Noel

Re: Why is IPv6 a must?

[Keith Moore]

> Quite simply, a bunch of us *are* searching for a paradigm shift.  

Indeed.  But a satisfactory one hasn't been found yet.  

Keith

Information

[Salvatore Spadaro]

Hello everybody,

I am studying the Optical Channel demands statistics according to the
traffic generated by the users in an IP over ASON environment.

Could someone help me with information about the triggering mechanism of
the Optical Channels? For example, in a MPLS router, which is the
triggering mechanism of the establishment for a new LSP?

Thank you very much in advanced.

Salvatore

Re: Why IPv6 is a must?

[Brian E Carpenter]

Keith Moore wrote:
> 
> somebody needs to define an alternative to midcom that uses IPv6
> prefixes to name the addressing realms, and an algorithm  to map
> (prefix name + NATted IPv4 address) into an IPv6 address.
> 
> nobody says you have to actually be willing to route traffic to
> those IPv6 addresses, but you could use them in midcom as
> unambiguous host names for pinhole specification, and you could
> use them in network management.  and if/when you did decide to
> actually route IPv6 traffic, management would be considerably
> simplified by being able to use the same addresses.

And of course, the 6to4 prefix can be used exactly this way, with
no need to go to a registry for an IPv6 prefix. 

  Brian


> 
> Keith
> 
> > From: "Perry E. Metzger" <[EMAIL PROTECTED]>
> > To: Keith Moore <[EMAIL PROTECTED]>
> > Cc: "Tony Hain" <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
> > "Hans Kruse" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> > Subject: Re: Why IPv6 is a must?
> >
> > Keith Moore <[EMAIL PROTECTED]> writes:
> > > I don't see a "killer IPv6-based business app" as likely,
> >
> > I think I know one. Network management and administration. There is no
> > way in some of today's deeply NATed v4 networks to do adequate network
> > management -- monitoring is especially hard. Overlaying a v6 network
> > with a real address space over the NAT mess is easy, and results in
> > being able to actually get to all the nodes being managed.