Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting

From: [email-masked] (Noel Chiappa)
Date: Tue, 7 Nov 2006 08:52:03 -0500 (EST)

> From: "Fergie" <[email-masked]>

    > perhaps the most controversial (?) issue(s) that came up was w.r.t. how
    > v6 actually complicates operational aspects of the global routing
    > system ... it actually contributes to the existing problem.

Just briefly, since this is the point that's relevant here (not the rest of
the v6Ops stuff), what are the things about v6 that make the routing problem
worse? The nitwitted Provider-Independent addresses, of course, but that's
obvious. Other than that, I thought v6 was pretty similar to v4 (from the
point of view of the routing), so I'm curious as to what else makes it
worse.

	Noel

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 7 Nov 2006 08:07:32 -0800

On Nov 7, 2006, at 5:52 AM, Noel Chiappa wrote:
> Just briefly, since this is the point that's relevant here (not the  
> rest of the v6Ops stuff), what are the things about v6 that make  
> the routing problem worse?

the PI address is just as PI as the IPv4 PI address. No change. There  
is a ringer in PA space - there are some issues that can arise if one  
gets a PA prefix from one provider and advertises it to another. That  
provider or its upstream may not accept the prefix in routing, and  
the original ISP is forced to advertise it into the backbone in order  
to not have a working alternate path get all the traffic. PA in that  
sense becomes PI.

The big thing that makes routing screwey is ingress filtering - BCP  
38. If the prefix in use is supposed to be the one delegated by the  
ISP, then the enterprise is nominally on the hook to ensure that the  
source address that crosses its DMZ is for the right ISP. But the  
host has no idea which DMZ the routing system will use or what  
prefixes are sited there. So it essentially selects a source address  
at random and the routing system is nominally on the hook to tunnel  
the packet to the right DMZ. The other side of that is the fact that  
a multihomed destination also has multiple addresses and there isn't  
necessarily real good guidance on which to use. The cross product of  
the two sets of addresses is essentially a random selector among M*N  
routes (which DMZ will it go out of my network, through which pair-or- 
more of ISPs, and which DMZ will provide the ingress to the peer  
network?), which may have very different characteristics.

There is a mechanism to configure policy of this kind, in RFC 3484.  
The discussion in v6ops yesterday was to the effect that we wanted to  
look at this, though, as it may not be a adequate solution. SCTP and  
shim6 also have ways to mitigate the M*N routes, through some  
combination of cached history and probing during the session.

There is renewed discussion of GSE and an ID/Locator split. GSE  
solves the above issue, at least for the source address, by allowing  
the egress DMZ to write its prefix into the IPv6 header, eliminating  
the question of tunneling to a randomly selected DMZ. There is some  
possibility that a bad choice of destination address on the SYN-or- 
equivalent can be fixed by GSE on the SYN-ACK path - if the routing  
in the remote system picks a different DMZ, it will pick a different  
prefix according to it. So GSE actively helps, although it doesn't  
fully optimize the solution and Mike's initial ID is best described  
as an initial ID.

The discussion of GSE is couched in language related to the ID/ 
Locator split. As you discussed in 1993 and earlier, this would be a  
good thing for various architectural reasons. I can't say that it  
automatically improves routing, or the scaling of addressing though.  
To my small mind, it enables the address overwrite done in GSE to be  
done safely, and it is the address overwrite that actually helps.

There is a wrinkle with the address overwrite, but it is solvable. It  
makes AH not work as specified - one has to restrict the "immutable  
or predictable" fields to the locator as opposed to the address. It  
also has some issues with IKEv2 in setting up ESP sessions (although  
ESP is not itself affected). Steve Bellovin tells me that both are  
fixable and has offered to help.

I will have the presentations that were given posted in the v6ops  
IETF67 proceedings site later today. I'll post the URL at the time.

---

From: Fred Baker <[email-masked]>
Date: Tue, 7 Nov 2006 09:39:47 -0800

On Nov 7, 2006, at 8:07 AM, Fred Baker wrote:

> There is a wrinkle with the address overwrite, but it is solvable.  
> It makes AH not work as specified - one has to restrict the  
> "immutable or predictable" fields to the locator as opposed to the  
> address. It also has some issues with IKEv2 in setting up ESP  
> sessions (although ESP is not itself affected). Steve Bellovin  
> tells me that both are fixable and has offered to help.

for completeness, I should note that there is another ringer in the  
address overwrite. SCTP has the ability for one end to announce  
alternative addresses to its peer, and in shim6 a similar capability  
is added to TCP and UDP. The mutability of addresses makes  
recognizing packets in the session depend on this. GSE, in proposing  
a locator, allows the endpoint transport to look only at the locator.  
That means, however, changing every transport implementation running  
atop IPv6.

---

From: "Schliesser, Benson" <[email-masked]>
Date: Tue, 7 Nov 2006 11:57:38 -0600

> Just briefly, since this is the point that's relevant here (not the
rest
> of the v6Ops stuff), what are the things about v6 that make the
routing
> problem worse? The nitwitted Provider-Independent addresses, of
course,
> but that's obvious. Other than that, I thought v6 was pretty similar
to v4
> (from the point of view of the routing), so I'm curious as to what
else
> makes it worse.

I'm also curious about what makes it worse. I wasn't able to attend
v6ops yesterday, but from past discussions I've gathered that the
scaling complaints against v6 can be summarized as "it scales like v4,
but with a higher limit on table size". Would somebody making this
argument view v4 address-exhaustion as a feature?

It seems to me that, leaving traffic-engineering aside, v6 can scale
better than v4 with proper allocation rules. That is, if each AS gets a
single prefix large enough to satisfy all of their current and future
needs (pretend that we can perfectly predict future needs for a moment)
then table size should be much smaller than today.

What am I missing?

Cheers,
-Benson

---

From: Chris Morrow <[email-masked]>
Date: Tue, 7 Nov 2006 18:20:25 +0000 (GMT)

On Tue, 7 Nov 2006, Fred Baker wrote:
> this. GSE, in proposing a locator, allows the endpoint transport to look only 
> at the locator. That means, however, changing every transport implementation 
> running atop IPv6.

which, with ipv6 'infancy' might still be a decent idea... doing it 
'right' this time could lead to a better long term solution?

---

From: Chris Morrow <[email-masked]>
Date: Tue, 7 Nov 2006 18:27:03 +0000 (GMT)

> better than v4 with proper allocation rules. That is, if each AS gets a

I can't really scale 'better' if you want multihoming... If you think of 
multihoming as you would today in the current v4 world. It scales about 
the same in that case, which with a higher top end means more trouble :(

> then table size should be much smaller than today.

table size will grow... I'm not sure you can say it'll be smaller than 
today, since tomorrow there are likely many, many more things being 
connected to the Internet.

Also, keep in mind that the 'global table' isn't all that is the problem 
here, there are internal routes for ISP/NSP folks to carry, and overlay 
routes for 'services'...

---

From: John Day <[email-masked]>
Date: Tue, 7 Nov 2006 13:35:51 -0500

At 18:27 +0000 2006/11/07, Chris Morrow wrote:
>I can't really scale 'better' if you want multihoming... If you 
>think of multihoming as you would today in the current v4 world. It 
>scales about the same in that case, which with a higher top end 
>means more trouble :(
>
>table size will grow... I'm not sure you can say it'll be smaller 
>than today, since tomorrow there are likely many, many more things 
>being connected to the Internet.
>
>Also, keep in mind that the 'global table' isn't all that is the 
>problem here, there are internal routes for ISP/NSP folks to carry, 
>and overlay routes for 'services'...
>
>>What am I missing?
>
>

A complete architecture.  ;-)  Sorry I couldn't resist.

---

From: Fred Baker <[email-masked]>
Date: Tue, 7 Nov 2006 11:01:34 -0800

I would agree, and agreed ten years ago. But if we're going to do it  
now, there is no time to waste.

On Nov 7, 2006, at 10:20 AM, Chris Morrow wrote:

>> this. GSE, in proposing a locator, allows the endpoint transport  
>> to look only at the locator. That means, however, changing every  
>> transport implementation running atop IPv6.
>

---

From: David Meyer <[email-masked]>
Date: Tue, 7 Nov 2006 11:27:17 -0800

> point of view of the routing), so I'm curious as to what else makes it

	More rope (address space).

	--dmm

---

From: <[email-masked]>
Date: Wed, 8 Nov 2006 10:24:01 +0200

David Meyer [mailto:[email-masked]] wrote:
>Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting
>
>> rest of the v6Ops stuff), what are the things about v6 that make the 
>> routing problem worse? The nitwitted Provider-Independent addresses, 
>> of course, but that's obvious. Other than that, I thought v6 was 
>> pretty similar to v4 (from the point of view of the routing), so I'm 
>> curious as to what else makes it worse.
>

Or "more tunnel" :-?

	Jarno Rajahalme

---

From: <[email-masked]>
Date: Wed, 8 Nov 2006 10:48:49 +0200

Fred Baker [mailto:[email-masked]] wrote:
>"immutable 
>for completeness, I should note that there is another ringer 
>in the address overwrite. SCTP has the ability for one end to 
>announce alternative addresses to its peer, and in shim6 a 
>similar capability is added to TCP and UDP. The mutability of 
>addresses makes recognizing packets in the session depend on 
>this. GSE, in proposing a locator, allows the endpoint 
>transport to look only at the locator.  
>That means, however, changing every transport implementation 
>running atop IPv6.
>

Existing transport stacks could be fooled by masking the LOC part to
some fixed value, so that they would effectively only see the ID? Also,
the Locators could be assigned from a different address block than the
currently standardized unicast addresses so that routers would know
which are which? Then some encouraging policy to make networks that want
to multihome to migrate to LOC/ID split?

IMO the ID part should be allowed to be cryptographically generated.

Then about the perceived layer violation: Optimally the RG/LOC stuff
should live in it's own header (internetworking header), while the ID
should be in its own header, effectively taking the pseudo-header used
by transports away from the internetworking header. Something like this
could be possible with the existing IPv6 header structure with option
headers. Separating the headers would also allow for different sizes
than 64 bits for both LOC and ID. Maybe something like this should be
specified. But I would not mind also settling a mapping to the current
IPv6 header with 64-bit ID & LOC for the benefit of current and
in-development forwarding HW being able to effectively operate on these.

Also strongly agree that there is no time to waste on doing this right,
now. 

Regs,

	Jarno Rajahalme

---

From: David Barak <[email-masked]>
Date: Wed, 8 Nov 2006 11:48:03 -0800 (PST)

> the same in that case, which with a higher top end

Valid point, but if our allocation rules are sensible,
then the vast majority of non-transit providers should
be fine with a single block.  Even at maximum CIDR
aggregation nowadays, we'd have multiple times the
number of routes as ASNs.  If we can keep the number
of routes < 2x number of ASNs, that'd still be better.

> connected to the Internet.

It's not the things connected to the Internet which
necessarily causes table growth: it's the things which
are connected to multiple Internet providers. 
Singly-homed devices should be aggregatible inside the
provider's block.  As long as the allocation process
does not permit singly-homed sites to obtain PI space,
there shouldn't be an additional scale effect.

> here, there are internal routes for ISP/NSP folks to

But at the very least, those internal routes need not
be known by anyone else, and each route should
represent some process or service for which the ISP is
being paid...

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

____________________________________________________________________________________
Sponsored Link

Try Netflix today! With plans starting at only $5.99 a month what are you waiting for?
http://www.netflix.com/Signup?mqso=80010030

---

From: Chris Morrow <[email-masked]>
Date: Wed, 8 Nov 2006 19:12:35 -0500

> of routes < 2x number of ASNs, that'd still be better.

sure... there are cases where more than 2x might happen, but an  
average ov 2x, perhaps that's doable.

> there shouldn't be an additional scale effect.

part of this problems/solution might be a dissolution of 'pi'... If I  
understand the ID/Loc split concept I can have a single 'ip address'  
forever on a single device, indepenedent of the attachment to the  
network(s).

> represent some process or service for which the ISP is

Internal table growth to support services is impacting today's  
networks. It's one of the major contributing factor to pain in route- 
scaling today. It is likely that tomorrow that problem will continue,  
at the very least it won't disappear.

---

From: Dorian Kim <[email-masked]>
Date: Wed, 8 Nov 2006 19:54:47 -0500

> average ov 2x, perhaps that's doable.

As it was observed by Vince earlier in the thread, we are going
to most likely have to deal with coexistance of IPv4 and IPv6,
for some reasonable period of time regardless of things play out,
so IPv6 having a bit better RIB growth characteristics is likely
insufficient to address the problem we are facing.

Furthmore, given the market demand for multihoming and traffic 
engineering we don't know how many prefixes an ASN will announce 
even when we can assuming something close to 1 allocation per ASN.

I also think that allocation policy is not sufficient a check on 
future table growth if there are financial incentives that are
pitted against any type of allocation policy.

-dorian

---

From: "Schliesser, Benson" <[email-masked]>
Date: Wed, 8 Nov 2006 19:01:53 -0600

I just read through Vince's slides at http://www.vaf.net/~vaf/iepg.pdf
and some of his references. If I may summarize (oversimplify?) the
primary objections, they come down to 1) adding more address space might
lead to routing table growth beyond what humanity are capable of
handling, and 2) if we lock ourselves into IPv6 right now then we might
have difficulty implementing a locator/id split later.

Both of these are legitimate considerations of course, and I'd like to
address them in a moment. But first I want to ask, do we think it's
possible, even with the weight of these concerns, to change the course
of IPv6 at this point and still alleviate address exhaustion in time? As
Vince points out, these concerns have been a topic of discussion for the
past 20 years. Can we introduce a new architecture that addresses them
and get it implemented to the same degree (coverage and maturity) as
IPv6 today, quickly? I'm doubtful, and I'd rather have an imperfect
routing system than face disruption from critical resource exhaustion.

That said, I still want to comment on the concerns mentioned above.

The first concern, that routing tables will grow beyond what we can
handle, is of course a possibility. I'm not particularly swayed by the
argument that we have to protect the world from the need to
upgrade--this is a natural part of technology growth, and will often be
a requirement to support new protocols in any case. On the other hand
the argument that the routing system might grow beyond what technology
can keep up with is a scary thought. But is it realistic?

I understand the potential for 6M businesses to multihome (and use PI or
deaggregated space), but as of yet we haven't seen even a fraction of
that number. Looking at a recent Routing Report
(http://thyme.apnic.net/oix-data/2006/11/08/mail-global) it appears that
there are around 20k origin-only ASs. It would take an incredible change
in the economics of network connectivity for this number to jump by
several orders of magnitude, so I see this worst-case as unlikely.

A more realistic case might be Jason Schiller's example of global IPv6
deployment in today's environment, where a Tier 1 service provider could
have >500k routes and a "normal" full table (i.e. not including provider
internal routes) is around 300k. This shouldn't be an issue for todays
core routers. But subsequent growth from that point should be better
than the projections based on the current rate. Clearly better
multihoming methods, locator/id split, etc, will play an important part
of this. (i.e. removing 20k origin-only ASs from the routing system
would be a boon--then I'd only have to maintain routes for my competitor
service providers...) But additionally we will benefit from allocation
policy such as limiting v4 availability once v6 is predominantly
available, giving out adequate v6 space to limit (eliminate?) the need
for multiple networks per AS, etc. This alone may be enough to reduce
growth rates to a supportable target.

The second concern, about difficulty in implementing a locator/id split,
is not an area I can claim expertise. Is there any reason why IPv6 would
make a poor locator? (It seems to do that job today...) Is there a
reason why it would make an ID split more difficult? If not then we
should continue to encourage IPv6 deployment and plan to use it as a
locator when we settle on the ID protocol some day. After all, it does
solve some large and relatively short-term problems.

Cheers,
-Benson

---

From: David Conrad <[email-masked]>
Date: Thu, 9 Nov 2006 06:20:43 -0800

Jarno,

On Nov 8, 2006, at 12:48 AM, <[email-masked]> wrote:
> some fixed value, so that they would effectively only see the ID?

Doesn't solve the problem of higher layer protocols encoding the  
address they are using into their protocol stream.

> Also,
> which are which?

Yep.

> Then some encouraging policy to make networks that want

I suspect market forces will be sufficient to encourage the  
movement.  After all, if you are an enterprise customer, wouldn't you  
want the ability to change ISPs without renumbering?

> IMO the ID part should be allowed to be cryptographically generated.

 From the perspective of the routing system, the ID is opaque so it  
shouldn't matter how it is generated/assigned.

> Something like this
> specified.

One question that needs to be answered is "how much do we want to  
change?"  There are several options:

a) Change both the end points and the infrastructure (I call this the  
IPv7 approach)
b) Change only the end points (every host IPv6 stack deployed to date)
c) Change only the infrastructure (all routers deployed for IPv6  
service)
d) Change the junction between the hosts and the infrastructure  
(e.g., the point between the "core" and the "edge").

My personal feeling is that in terms of feasibility (that is, getting  
people to actually change), you'll want to minimize cost (both in  
financial terms as well as in deploying new technology).  I'd argue  
option (d) is likely to be the least expensive and thus, the most  
likely to be deployable.

Rgds,
-drc

---

From: Jefsey_Morfin <[email-masked]>
Date: Thu, 09 Nov 2006 17:24:14 +0100

At 15:20 09/11/2006, David Conrad wrote:
One question that needs to be answered is "how much do we want to
>option (d) is likely to be the least expensive and thus, the most

I am sorry, this is a "mono-Internet" rough consensus oriented 
comment! The response is not to get a rough consensus between IETF 
co-users for the academic 1983 Internet to roughly perform, but to 
document the a, b, c, d, etc. diversity and the way they are to 
interoperate to permit everyone to survive from the multiple messes 
of the mono-internet and get to the unique top quality of the Multi-Internet.

The problem discussed here about IPv6 is equivalent in nature, 
origin, and result to the IDN in the DNS area. IPv4/DN, IPv6/IDN are 
equivalent problems where one hopes that details will solve universal 
issue. Please remember the reality is always more complex than 
models, and that frozen models do not escalate. All the more if they 
do not exist!

The IETF is built on the rough consensus culture. It permitted to 
deploy a supernetwork over the telecom infrastructure. Great. The 
Catenet network of the networks. We need now a concerted consensus 
culture where each proposition is consensually documented by its 
supporters and their interoperability is rough consensually 
discussed. To obtain a networks of the network of networks 
architecture. To  support brain2brain metacoms, over the end2end 
datacoms, over the plug2plug telecoms. Interconnectibility supporting 
interoperability supporting interintelligibility. Plugs are usually 
fixed. Ends are more and more moving. Brains are ubiquitous.

Multilingualisation, multihoming, multimodes, multilateral relations 
are requiring solutions that the lingualised IPv4 can only support as 
internationalised and IPv6 options. They need more. Much more. 
Multi-homed, -lingual, -modal, -technology, -lateral, etc. Internet.

Is this to stay an unique protocol pile, or can it benefit from 
uncoupling? The Internet technology managed end to end links over 
plug to plug lines. IMHO this is to be cleaned; and the metacom layer 
to be identified and developed, as such. With a different cultural 
approach: hardware, software, brainware. The need is building a smart 
IP addressing plan over a dumb stupid network numbering scheme, in 
devising an intelligent language management over a dumb stupid 
internationalisation (Unicode). Also, let stop thinking 
network/applications and let think continuity/services/organisation. 
Let stop thinking centralisation (IANA) and let start thinking 
distributed architecture (ex. let suppress the DNS root server 
system, the decentralisation of a centralised file to serve a 
distributed network - a pile of layer violations).

This is what I understand John Day calls an operating system. 
Something diversified which delivers commonly accepted intelligent 
usages of relational services over the Internet, NGN, GENI, etc.: all 
these software technologies being used on the hardware of the world's 
digital ecosystem.

The time when you said "you do what you want with the Internet, as 
long as it is the unique way I wrote in an RFC" is over for a long 
time. The problem is that the IETF did not know it, and has now to 
adapt before we crash.

IMHO the addressing plan core is: there are 16 possible upstream and 
16 downstream addresses in a switcher using an hexadecimal numbering 
plan. How do we best organise that routing atom/lego to best support 
IPv4, IPv6, IPv7, IPv8, IPv10, etc?

jfc