RE: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points

I totally agree with Mike in his comments below, and those from Dave Pratt
in a previous email.

Some time ago I sent the following proposal to the list, and I would like to
point out, again, that address space is already allocated for this and is
clearly specified in RFCs. 

The proposal was:

At the RIPE 39 joint meeting it was clarified that we should cater for the 
support of both types of IPv6 exchanges, viz:

(i)	allocate addresses for IPv6 exchange infrastructure only (no onwards
allocation in the manner of a backbone ISP). 

(ii)	allocate a sub TLA to the IPv6 exchange which will then act in the 
manner of an ISP and allocate downstream.

In order to progress this, I would like to propose: 

1	 IPv6 exchanges that need addresses for the purpose of internal
addressing can apply for the addresses already set aside for this purpose 
and held by IANA, as per RFC2928 (Initial IPv6 Sub-TLA ID Assignments)
and RFC2450 (Proposed TLA and NLA Assignment Rules). In this case a /48 
allocation will be sufficient. (How IPv6 exchanges should apply for these 
addresses is out of scope - either direct to IANA, or IANA allocates down 
to RIRs first).

extract from RFC2928
Section3	Initial IPv6 Sub-TLA ID Assignments
...  ..The block of Sub-TLA IDs assigned to the IANA (i.e., 2001:0000::/29 -
2001:01F8::/29) is for assignment for testing and experimental usage
to support activities such as the 6bone, and for new approaches like
exchanges.

2	IPv6 exchanges that plan to onward allocate addresses in the manner
of an ISP should apply via the existing mechanism. The existing mechanism 
is currently being reviewed and this review should take account of any
changes 
necessary to include IPv6 exchanges explicitly desiring addresses for onward

allocation as being acceptable candidates for address space.



Could we please add this proposal to what is already on the table.

Regards,



Paul

 P. S. Mylotte
 IP Addressing & Naming 
 BTexact Technologies
 Adastral Park
 01473 606333 / + 44 1473 606333
 paul.mylotte@localhost

BTexact Technologies is a trademark of British Telecommunications plc
Registered office 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000

This electronic message contains information from British Telecommunications
plc which may be privileged or confidential. The information is intended to
be for the use of the individual(s) or entity named above. If you are not
the intended recipient be aware that any disclosure, copying, distribution
or use of the contents of this information is prohibited. If you have
received this electronic message in error, please notify us by telephone or
email (to the number or address above) immediately.

> -----Original Message-----
> From:	Mike Hughes [SMTP:mike@localhost]
> Sent:	03 September 2001 11:19
> To:	lir-wg@localhost
>; ipv6-wg@localhost
> Subject:	Re: Interim Policy proposal for IPv6 Address Assignment
> Policy for Internet Exchange Points
> 
> On Fri, 31 Aug 2001, Dave Pratt wrote:
> 
> > Unfortunately, I must respond against the proposal as it stands with use
> of a
> > /64 allocation.
> 
> If the proposal for the /64 allocation for the IXP mesh is "it" - i.e.
> this will be the only address space allocated to an IX, period - then I
> find it hard to be in full agreement with this proposal.
> 
> The LINX is currently an RIR in it's own right, with a /19 of PA space
> delegated to it. This is diced up to provide addresses for the IXP meshes
> at LINX (both Unicast and Multicast), for LINX's own public-facing and
> member services, and some space is delegated for essential services LINX
> hosts (such as nic.uk).
> 
> LINX peers with all it's members, and announces this /19 to them - this
> means that members have direct, independant connectivity to the LINX
> services. We also have a handful of transit ISPs (a small subset of
> members, but over independant media) to fill in the gaps, and make sure
> we're still online if there is an exchange problem.
> 
> If v6 addresses for an IXP's member services have to be delegated from an
> upstream provider, this makes the exchange dependant on that provider. If
> that provider has problems, or ceases trading, that could have serious
> impacts on the business continuity of the exchange, for it's
> member/participant community, and possibly other members of the RIPE
> community.
> 
> Please don't say IPv6 address-based multihoming to me. It's not ready
> for primetime IMHO.
> 
> What I believe is needed is an allocation for IXP service networks as well
> as for the IX mesh, which is globally routable. I'd like to propose this
> alongside the existing proposal we have on the table.
> 
> Comments?
> 
> Mike
> -- 
> Mike Hughes	Network Architect	London Internet Exchange
> mike@localhost	http://www.linx.net/	
>      "Only one thing in life is certain: init is Process #1"
>