Subject: Re: [GLOBAL-V6] Problem statement for transit/exchange only IPv6 address space

From: "Jim Fleming" <[email-masked]>
Date: Fri, 9 Nov 2001 14:04:24 -0600

----- Original Message ----- 
From: "Janos Mohacsi" <[email-masked]>

Problem statement for transit/exchange only IPv6 address space:

The current Proposed TLA and NLA Assignment Rules (RFC 2450) and IPv6 
Aggregatable Global Unicast Address Format (RFC 2374) is not particularly 
supporting addressing long haul transit providers or exchange providers.
...
This solution is not really acceptable. Or you have some other idea?

The "toy" IPv4 Internet is a sewer.
IPv8 is designed to be a swamp to cover the sewer.
IPv16 is the "high-ground"....

...here are some links...

Jim Fleming
http://www.unir.com
Mars 128n 128e
http://www.unir.com/images/architech.gif
http://www.unir.com/images/address.gif
http://www.unir.com/images/headers.gif
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp
http://www.ietf.org/mail-archive/ietf/Current/msg12213.html
http://www.ietf.org/mail-archive/ietf/Current/msg12223.html

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Janos Mohacsi <[email-masked]>
Date: Fri, 09 Nov 2001 10:09:35 +0000

Dear All,
	Sorry for cross posting this message to more than one IPv6 related mailing 
list, but I think IPv6 community should prepare with some position to the 
transit/exchange only providers. I have seen the excellent presentation 
from Mirjam K|hne from RIPE-39 about IPv6 exchange proviers, but then I 
have not seen any discussion. My goal with this problem statement to 
increase the debate and hopefully reach some consensus about the problem. 
The problem statement is rather long.... Sorry about that.
Kind Regards,
		Janos Mohacsi 	

As RFC2374 states:
"While this address format is designed to support exchange-based 
aggregation (in addition to current provider-based aggregation) it is not 
dependent on exchanges for it's overall route aggregation properties.  It 
will provide efficient route aggregation with only provider-based aggregation."

What is the current proposed solution to obtain IPv6 addresses for 
long-haul IPv6 transit providers or IPv6 exchange providers?

To better understand the case I try to explain the problem more thoroughly.

Let suppose the following situation:
There is a long-haul ipv6 transit provider call it X. X is providing IPv6 
transit or exchange service for ISPs Y1, Y2,....Yn. But X provide only IPv6 
address assignment service for few  customers of Yi, let say only for 4-5 
customers, for one of the following reasons:
	1. Most Y1,Y2, ... Yn has already production IPv6 subTLA
	2. X company profile does not contain running local IP registry.
	3. other reason

X operates its offices in the area of Yi. For office purpose X can obtain 
IPv6 address from Yi.

For IPv6 transit provision X needs an IPv6 address, but probably not /35 
addresses, but /44 is enough, even if the transit network is quite 
extensive and geographically large.

Scenario 1:

X request address for its transit network from Yi, since his office is in 
the area of Yi. They get /44 from Yi (it must be difficult according to the 
current NLA allocation rules).
X is implementing transit service and establishes private or public peering 
with ISP Z1, Z2, ... Zn and of course ISP Y1, Y2, ... Yn.
To help the network management X implement and run some monitoring tools on 
the network near to monitored equipment. X can access its network, the 
involved network was network Yi. They are happy with the monitoring tools 
and X wants to share some results with Zk and Yj.

Since the strict aggregation network addresses: of X-transit_network will 
be reacheable via Yi peering of Zk and Yj, not via peering of X-Zk and X-Yj 
that would be preferred. X can advertise more specific routes Zk and Yj, 
but this way X pollutes with non really aggregated entries the routing 
table of Zk and Yj. If they implement a really strict aggregation scheme 
then these more specific routes are discarded. How can X solve the problem?

What happens if X wants to change provider from Yi to Yj? What happens if X 
has more than office one near to Yi and the other Yj? Which one should be 
used? Or some kind of multihoming should be used?

Scenario 2:

X request address (a subTLA) for its transit network from Regional IP 
Registry. X implementing IPv6 transit service and also network monitoring 
as before, but he does not allocate addresses just for few ISP Y. This 
somehow violates the current registration policy, since X does not fulfill 
all the 5.1 requirements of RFC 2450 and the corresponding RIR IPv6 
allocation policy documents.

There is no problem with accessing the services via the preferred peering 
since aggregation is done in X based on subTLA.

Is this the current recommended solution?

Scenario 3:

X request address for office purpose only from Yi, and for the network they 
use site local address. The public and private BGP peering is quite 
problematical in this case, since some routers does not allow using local 
type IPv6 addresses in BGP peering.
Providing the monitoring services can be also difficult, since monitoring 
tools cannot be reached outside of X transit network.

---

From: Gert Doering <[email-masked]>
Date: Wed, 14 Nov 2001 17:38:10 +0100

Hi,

I haven't seen any responses to this, so let me comment...

On Fri, Nov 09, 2001 at 10:09:35AM +0000, Janos Mohacsi wrote:
[..]
> supporting addressing long haul transit providers or exchange providers.

I don't think there is any issue that needs to be addressed.

There are three different cases:

 - the ISP in question is offering IPv6 address space to its customers,
   that is, will do LIR services.  In this case he can get address space
   from the RIRs, no problem.

 - the ISP in question is not offering LIR services, but has an upstream
   provider who *is* offering LIR services.  So he can get an /48 from
   them with no problem.  A /48 means "a full /64 for 65000 networks",
   which is quite some.  If /127s are used on point-to-point links
   (which is legal) it's definitely "enough for ever".  If /64s are
   used, it may be necessary to come back to his upstream provider
   and get a second /48 - which is possible.

   No problem here either.

 - the ISP in question is a Tier-1 provider, has no upstream provider
   that can provide IPv6 addresses to him, and does not offer LIR 
   services to his customers.  (Out of curiosity: does such an ISP
   exist?  I haven't found one.)

   If such ISPs exist in reality, they could get an /48 from the "Yi"
   customer that you mentioned - or they could just become a LIR and
   get address space for their own, which is not impossible, and the
   costs for becoming a LIR should be neglectible for a Tier-1 provider.

   No big problem.

Conclusion: I do not see the need for a special-case provider who needs
IPv6 addresses, has no upstream provider to get a /48 and does not want
to become a LIR.
   
Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:   72980 (73128)

SpaceNet AG                 Mail: [email-masked]
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299