[ppml] Address Space versus Routing Slots
Jeroen Massar
jeroen at unfix.org
Tue May 2 04:43:24 EDT 2006
Hi,
As it seems there is quite some controversy about the term "PI".
For many people "PI" seems to imply "DFZ Routing Slot entry", this is
not the case of course.
ARIN, RIPE, APNIC, AFRINIC & LACNIC hand out, based on demand,
requirements, fulfilment and other factors _Address Space_.
They *DON'T* guarantee any routing though. Just like it is not able to
currently (easily ;) announce a IPv4 >/24 usefully, if a lot of ISP's
filter larger blocks, or only the few interresting ones, eg if Google
would filter on IPv4 /16's or so, a lot of sites would become quite sad,
or at least their users. That is economics. If one doesn't want to
accept a route, don't accept it. Thus for the folks hating the idea of
"IPv6 PI", when the time comes you have the option of not accepting the
route, or to make it economically nice for you: let them pay for it ;)
Anyhow, back to the guts... Currently the RIR's pass out IPv6 PA address
space, which means that the ISP breaks up this address space and
provides chunks of it to it's end-users. There is some fierce discussion
(actually more corner closet to other corner closet talk) going on about
"PI address space". PI is provider independent, which means the
end-sites can keep on using this address space wherever they are, even
disconnected from the internet. PI only provides end-sites globally
unique address space, that is independent of any provider.
PI thus doesn't *NOT* say that it will have any entry at all in the DFZ
routing tables. For that matter PA doesn't even mean this. Taking a nice
look at the IPv6 PA allocation to the Holy See (just a random nice
example ;), they could use it internally as a globally unique addressing
space addressing all their churches, monestaries and I know what. It
does not even mean that this address space would have to be announced in
the DFZ as it is only for their own use. (It is being announced already
btw and it works)
Normally of course people will, more sooner than later want to
communicate to networks on the global internet.
For the time being, say the upcoming ten or so years, this will mean
that these routes are taking a slot in the routing tables. Now some idea
I would see happening in the future.... lets see what you folks think of
it ;)
At a certain point, some bright person somewhere on this planet will
come up with an ideal solution of not having a global DFZ any more.
One of these solutions could be some form of shim6 or HIP. These
protocols could use the Address Space the site has as an identification
mechanism. The actuall routing though, using a locator, might very well
happen using a completely different address space, of which only
relatively a few ISP's will be announcing those routes into the DFZ.
Yes this will require some mind set changes, but not for the coming
couple of years at least so one can get used to it ;)
Now some drawings as examples, a current "IPv4 PI Multihomed Site", thus
2 different access mediums, and own IPv4 PI address space and some
upstreams.
+-----------+
|Remote Host|
+-----------+
|
+--+
|RR|
+--+
|
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
{ World Wide Internet(tm)(z) }
`````````````````````````````
| |
+------------+ +------------+
| Upstream 1 | | Upstream 2 |
+------------+ +------------+
| |
BGP BGP
| |
+--+ +--+
+----|R1|---------------|R2|----+
| +--+ Site +--+ |
| (ASN) |
| +------+ |
| | Host | |
| +------+ a:b:c::/48 |
+-------------------------------+
The site thus has 1 globally unique address space, they announce this to
their two upstreams and they receive 'full' tables from both of them. If
they want U1 to deliver most packets they drop the announement to U2,
prepend a lot of their own ASN or do some other tricks. When they want
to use U2 for outgoing packets they use U2 to send them out over. Very
basic traffic engineering. The Remote Host doesn't know a thing of these
tricks that are getting played as the routing system takes care of it.
Now compare the above with:
+-----------+
|Remote Host|
+-----------+
: | :
: +--+ :
: |SR| :
.....+--+...:
|
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
{ World Wide Internet(tm)(z) }
`````````````````````````````
| |
+------------+ +------------+
| Upstream 1 | | Upstream 2 |
+------------+ +------------+
| |
BGP BGP
| 1:2:3::/48 | 4:5:6::/48
+--+ +--+
+----|S1|---------------|S2|----+
| +--+ Site +--+ |
| (ASN) |
| +------+ |
| | Host | |
| +------+ a:b:c::/48 |
+-------------------------------+
The site still have their own globally unique address space (the IPv6 PI
they most likely can soon get from ARIN). Their upstreams are providing
them with each a chunk out of their PA space. The upstreams still
provide BGP tables (they are small as they only contain PA) to the
ensite. The endsite thus can traffic engineer outbound using BGP just
like in the previous scenario. The site does NOT though announce it's
own address space into BGP. When a packet hits one of the two exit
routers (S1/S2) the exit picks it's upstream of choice, based on BGP and
possibly other metrics, translates the packet to source address of the
packet to the address space of that upstream and kicks it up the chain.
When the remote host now wants to send a packet back, it's SR sees what
possiblities it has to send the packet back, translating the destination
to the PA prefix of it's choice, which might be influenced by the
sending side. On the wire thus the PA space is used, while when the
packet crosses the S1/2/R they will be the same as the original.
There is one missing magic component here of course, how do S1/2 and SR
communicate to tell that S1/2 are authoritive that when a packets coming
from 1:2:3::/48 and 4:5:6::/48 are actually a:b:c::/48. And how do they
communicate their current policy to the remote router. A sort of
mini-bgp where S1/2 talks to SR could solve this. But that is the work
for the bright folks ;) (Who are working on this in context of shim6).
Note that in the above I depict SR as being able to be integrated on the
remote host, for large scalability reasons, but it could also be
somewhere in front of it, eg at the site's exits, or exist as a service
somewhere else all depending on the wishes of the site.
Greets,
Jeroen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 313 bytes
Desc: This is a digitally signed message part
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060502/6f60aa39/attachment.sig>
More information about the ARIN-PPML
mailing list