Subject: Update to Provider Independent addressing format drafts

From: "Tony Hain" <[email-masked]>
Date: Sun, 21 Oct 2001 23:04:00 -0700

The updates to the provider independent address format & usage drafts
are available at:
http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-fmt-01.txt
http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-use-01.txt

The usage document has been significantly reworked to address both
direct comments, as well as distillation of key issues from various mail
threads on nanog & multi6 lists. At this point comments should be
directed to the multi6 list.

Tony

---

From: [email-masked]
Date: Mon, 22 Oct 2001 16:25:06 +0900

>http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-use-01.txt

	I still don't understand how PI address format can be routed in
	currently-practiced routing infrastructure.  PI address, based on
	physical location can behave very poorly against aggregation.
	example:
	    I'm using 1fff:ffff:ffff::/48 and connected to ISP A, while
	    my neighbor is using 1fff:ffff:fffe::/48 and connected to ISP B.
	    ISP A and B needs to exchange /48 routes to route between us.
	I believe we end up having 2^44 routes in the routing system with
	the PI address allocation.  are there any magic I'm missing?
	examples given in the drafts did not convince me at all.

	another comment - in the document, it is mentioned that the allocation
	of a single /48 must be solved by "local jurisdiction".
	I don't think it workable for highly populated area (think of NY, tokyo,
	whatever), where skyscrapers make hundreds of companies to share the
	same geographical location.  it may work for less populated area
	(imagine any farms in middle-of-nowhere).

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Oct 2001 18:22:45 +0200

I agree. I think this is *very bad* for aggregation, since it won't just
be the IBM's of this world who go for it. If every small company goes
for a PI /48, the BGP table is a lost cause. I don't believe this
is a good idea.

I think the correct solution is PA, with PA /35 (or thereabouts) prefixes 
being used by local neutral exchange points - and policy mechanisms
beyond the scope of the IETF to create those exchange points. I don't believe
there is anything more we can do in this area by writing standards.

   Brian

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 22 Oct 2001 11:46:26 -0700

> for a PI /48, the BGP table is a lost cause. I don't believe this

Please read the current text. The recommendation specifically addresses
the small business / telecommuter case.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 22 Oct 2001 11:46:17 -0700

> 	examples given in the drafts did not convince me at all.

Yes you are missing the point. The magic is that you only have the /48
over a given region, so you are really talking about O 2^20 or so. If
that is too big the region needs to be split up with additional
exchanges.

> 	same geographical location.

Please provide a specific example rather than spread FUD. If you read
through the doc high rise buildings are specifically addressed in the
text.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Oct 2001 21:39:58 +0200

> the small business / telecommuter case.

Yes, and I don't believe it will work as you expect. Small companies will
use PI /48s and ISPs will announce them in exchange for money. Tragedy of
the commons all over again.

   Brian

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 22 Oct 2001 13:01:52 -0700

> the commons all over again.

Yes the direct connected ISP has to announce the /48 for any redundancy
to work, and that will happen no matter what format we choose. What this
version of the document is suggesting is that those small business /48's
be restricted to a region by virtue of a well defined policy which says
only 4 /48's per origin AS. Unless the small business can justify that
it has a distinct policy from its providers it will not have an AS, so
its /48 will appear with origins from each of the connected providers.
Since those AS's will be origin for well over 4, they will be filtered
and restricted to a region.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Oct 2001 23:21:59 +0200

Yes, Tony, but that is a policy decision - not something the
IETF can dictate by a standard, and one that personally I don't
think the ISP community would respect.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
Board Chairman, Internet Society http://www.isoc.org

---

From: [email-masked]
Date: Tue, 23 Oct 2001 08:34:45 +0900

>through the doc high rise buildings are specifically addressed in the

	I saw draft-hain-ipv6-PI-addr-use-01.txt, page 8 (extend grid to 150m
	square).  i don't believe it works, as I don't believe local
	jurisdiction functions.  and don't call my comment a FUD.

itojun

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 22 Oct 2001 23:25:03 -0700

itojun wrote:
> i don't believe it works, as I don't believe local
  ^^^^^^^^^^^^^^^^             ^^^^^^^^^^^^^^^
> 	jurisdiction functions.  and don't call my comment a FUD.

I only called it FUD because you are stating your belief rather than
specific detail of an instance where it doesn't work. Lots of people
hold the belief it won't work, but how many of those are based on a
simple resistance to think differently about the possible solution
space?

Tony

---

From: [email-masked]
Date: Tue, 23 Oct 2001 15:56:36 +0900

>> i don't believe it works, as I don't believe local

	sorry for poor choice of word.  s/believe/think/

itojun

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 23 Oct 2001 12:07:07 +0200 (CEST)

On Mon, 22 Oct 2001, Tony Hain wrote:

> Lots of people

Ok, so it can work. But does it have any real advantages? I don't see
them. If we want geo addressing, why not apply some brain power and come
up with something that works better. The problem with a direct translation
between location and address is that there are locations that need very
few addresses and there are locations that need very many. Also, the
boundaries will be in impractical places. For instance, half of London is
in the western hemisphere, the other half in the eastern hemisphere. So
should there be a LINX East and a LINX West then?

Doing the translation by hand means you can give areas the number of
addresses they need and you can have the boundaries where they should be:
where the interconnection is sparse (ie North Sea and not one of the
busiest cities of Europe).

On the other hand: direct mapping between addresses and locations could be
_very_ interesting if we had geo routing. For instance, a satellite or
UMTS base station could decide which antenna to use to transmit a packet
based on the address. But this doesn't seem to be happening.

I still believe is some form of geo addressing, but it has one huge
disadvantage: you need to be fully interconnected within the region. With
current multihoming, two networks could lose all their interconnects in
(for instance) the US and there would still be some level of reachability
through interconnects in other parts of the world. With geo addressing,
this isn't possible.

I'm starting to think we should give large address blocks to commercial
organizations who will then negotiate what kind of announcements will be
accepted within that block. This way, someone who wants their /24 (v4) or
/48 (v6) in the DMZ can do this by paying a large sum of money to one of
these address brokers, who will make sure it happens by paying the
networks to accept them. Obviously, this will not stop the routing table
growth but at least it will introduce the laws of supply and demand so
those who supply can buy bigger routers with the money from those who
demand.

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 23 Oct 2001 14:01:14 -0700

Iljitsch van Beijnum wrote:

> up with something that works better.

I have no problem with yielding to a better approach, but so far I
haven't seen one that addresses anything more than the service provider
technical perspective. This is a multi-facetted problem space, and we
need a broad perspective approach.

> The problem with a
> direct translation
> few addresses and there are locations that need very many.

This is only a problem if one tries to absolutely optimize the
allocation to the need. As long as those with a large requirement can
get what they need, there is no problem. One of the things that keeps
coming up when I talk to site network managers is the fact that a single
/48 is functionally equivalent to a /8 in IPv4. There are very few
organizations that need more than a single /8 today, so one could
extrapolate that very few organizations will need multiple /48's anytime
soon.

> Also, the

If one chose to implement it that way, yes that might happen. The point
is both prefixes would be exchanged at the current LINX until growth
caused that to be inadaquate. There is no reason to make this harder
than it needs to be.

> based on the address. But this doesn't seem to be happening.

Is this a chicken and egg problem? We don't currently have a decent
mapping that would allow a satellite operator to build a service like
this, so is lack of service simply a function of lack of an address
model?

> disadvantage: you need to be fully interconnected within the
> region.

Only for those who are not expressing an explicit policy to the DFZ (ie:
the ones who really don't need to be known outside the region anyway).
The sites that are looking for explicit policy will show up in the DFZ
no matter what we do.

> With

Why? You appear to be assuming that there is magic around one of these
prefixes which would prevent it from being announced via an alternate
path. I would argue that these prefixes would recover automatically
where the alternate announcements for PA space would require manual
intervention.

> those who supply can buy bigger routers with the money from those who

To a large degree allocating large blocks is what this proposal is
about. The current rules for PA space need to persist intact if there is
to be any structure. If we don't hold the line on the current rules, we
are simply recreating the IPv4 mess (which people are comfortable with
so they seem to like that level of pain). So this means we need an
alternate space which is provider independent to work with, and it needs
some level of structure to scale globally.

One way to implement your suggestion would be to have the registries act
as the brokers, and have the explicit value item be the AS number rather
than any specific prefix. If any organization wants to have an
independent origin AS in the DFZ money would flow. The number of
prefixes a single AS could be origin for could be self regulated through
financial feedback, or I was suggesting we set a hard limit which would
cap table growth at a small multiple of AS growth. I really don't care,
and maybe it gets implemented as one price for up to N prefixes, then a
significantly higher rate for each one over N.

Tony