- ipv6-wg - mailman.ripe.net

RE: Interim Policy proposal for IPv6 Address Assignment Policy fo rInternet Exchange Points
by paul.mylotte＠bt.com 07 Sep '01

07 Sep '01

All, YES - and I am hoping that the WGs will reach consensus at the Prague meeting that the interim policy-based allocations will permit extension to a /48 allocation. Paul P. S. Mylotte IP Addressing & Naming BTexact Technologies Adastral Park 01473 606333 / + 44 1473 606333 paul.mylotte(a)bt.com 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: David R Huberman [SMTP:huberman@gblx.net] > Sent: 04 September 2001 17:57 > To: lir-wg(a)ripe.net; eix-wg(a)ripe.net; ipv6-wg(a)ripe.net > Subject: Re: Interim Policy proposal for IPv6 Address Assignment > Policy forInternet Exchange Points > > > So I ask: > > > > In lieu of any other policy changes, are you, as a RIPE member and > > participant in the LIR, EIX, and IPv6 WGs, in favor of the interim > policy > > proposal for IPv6 address assignment policy for internet exchange > points? > > To answer my own question, I support the interim policy proposal and hope > it is ratified by the WGs as soon as possible. > > /david

1 0

Re: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points
by Wilfried Woeber, UniVie/ACOnet 06 Sep '01

06 Sep '01

=>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? = =I agree with you Mike, I think this is the only way an IXP can show its =independence from any one of its members (connected ISPs, carriers or =whatever) = = - Henk This "independence" argument is completly off-topic for this discussion. "Independence" can mean too many different things to too many different people. Usually you deal with that by making contingency plans or by building redundancy (or by defining procedures for the management plane ;-). Wilfried.

1 0

Re: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points
by Wilfried Woeber, UniVie/ACOnet 06 Sep '01

06 Sep '01

>The chairs put forth this interim policy proposal to these lists hoping to >garner consensus or judge that consensus does not exist. > >The ensuing discussion, while not unuseful, does not appear (to me) to be >helping the chairs and the wg membership from gauging the extent to which >there is consensus for this interim policy proposal. > >So I ask: I think it was your intent to separate discussion/improvement from "tallying" pro.s and com.s - so I4ll summarize my comments in a separate message... >In lieu of any other policy changes, are you, as a RIPE member and >participant in the LIR, EIX, and IPv6 WGs, in favor of the interim policy >proposal for IPv6 address assignment policy for internet exchange points? YES. >/david Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points
by Henk Steenman 06 Sep '01

06 Sep '01

At 07:19 PM 9/3/2001, Randy Bush wrote: > >> 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. > > I agree with you Mike, I think this is the only way an IXP can show its > > independence from any one of its members (connected ISPs, carriers or > > whatever) > >s/ixp/small isp/ > >i.e. the small isps want to appear independed from their upstream(s). >the discussion over this has been going on nigh a decade. so what makes >an ixp's business so special they warrant special treatment? I believe there is a difference, An IXP is a facilitating infrastructure delivering services to all ISPs connected or to be connected. Linkage in any way to one or more of its members might harm the neutrality of the exchange towards its other members. For AMS-IX: > AMS-IX is a non-profit, neutral and independent association, meaning > that it has no bias as to who connects For LINX > A neutral, not-for-profit partnership between Internet Service Providers > globally, LINX provides a physical interconnection for its members to > exchange Internet traffic through co-operative peering agreements I believe that in both cases "neutral" and "no bias to.." will be harmed if IXP address space (in any way, for the exchange infrastructure as well as for the services infrastructure like web server, e-mail etc) is related to a limited set of its customers. - Henk

3 2

WG: I-D ACTION:draft-ramki-multi6-nlmp-00.txt
by Thomas Trede 05 Sep '01

05 Sep '01

FYI. Regards, Thomas Trede -----Ursprï¿½ngliche Nachricht----- Von: owner-ipng(a)sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von Internet-Drafts(a)ietf.org Gesendet: Mittwoch, 5. September 2001 12:45 An: IETF-Announce: Cc: ipng(a)sunroof.eng.sun.com; multi6(a)ops.ietf.org Betreff: I-D ACTION:draft-ramki-multi6-nlmp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A proposal for scalable network-level multihoming Author(s) : R. Gummadi Filename : draft-ramki-multi6-nlmp-00.txt Pages : Date : 04-Sep-01 This document proposes two extensions to BGP4+ to provide scalable multihoming in IPv6. The first is a new well-known and mandatory 'TunneL (TL)' BGP path attribute that allows a multihomed enterprise to maintain global connectivity in the presence of network outages within a direct provider Autonomous System (AS) without adding any global forwarding overhead. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ramki-multi6-nlmp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ramki-multi6-nlmp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-ramki-multi6-nlmp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ENCODING mime FILE /internet-drafts/draft-ramki-multi6-nlmp-00.txt

1 0

Re: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points
by Chris Fletcher 05 Sep '01

05 Sep '01

One of the points that has been raised a couple of times is... There is a lot of IPv6 address space - why not just give IXP's a sub TLA. The argument against this seems to be - if IXP's are treated as a special case then there is a precedent for every other 'special case' to justify their case. ... but there is still *lots* [1] of address space so why not give everyone who wants one a sub TLA? AIUI the reason for restricting who gets sub TLAs is... In the current IPv4 world (multiprovider) multihomed customers have their own address space and AS number this fills the default-free routing table and won't scale. In IPv6, addressing is hierarchical and multihomed customers have multiple addresses, this keeps the default-free routing table small and scalable. If everyone (multihomed customers) gets a sub TLA then the default-free routing table fills up with multihomed customer sub TLAs and IPv6 routing tables are as cluttered and unscalable as IPv4. Is this the issue? If not, why not give out sub TLAs to all who want them? Chris - LINX [1] There are 2^32 (~ 4,000,000,000) /35s available... +--+-----+-----+---+-----+------+------------------+ |-3|--13-|--13-|-6-|--13-|--16--|------64 bits-----| +--+-----+-----+---+-----+------+------------------+ |FP|-TLA-|-sub-|Res|-NLA-|--SLA-|---Interface ID---| |--|-ID--|-TLA-|---|--ID-|--ID--|------------------| +--+-----+-----+---+-----+------+------------------+

5 5

RE: Interim Policy proposal for IPv6 Address Assignment Policy fo r Internet Exchange Points
by paul.mylotte＠bt.com 03 Sep '01

03 Sep '01

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(a)bt.com 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@linx.net] > Sent: 03 September 2001 11:19 > To: lir-wg(a)ripe.net > Cc: eix-wg(a)ripe.net; ipv6-wg(a)ripe.net > 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(a)linx.net http://www.linx.net/ > "Only one thing in life is certain: init is Process #1" >

2 1

Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points
by Fearghas McKay 03 Sep '01

03 Sep '01

Following discussion between the WG-Chairs and the NCC we have the following proposed draft. To enable allocations to be made as soon as possible we are soliciting comments over the next few days but unless there are any issues we would like to start making allocations by the end of next week, ie 7th September 2001. Please send any comments to the LIR-WG list <lir-wg(a)ripe.net> We propose a joint session to be held at RIPE40 where we can discuss the initial size allocations, information required in the forms and other issues raised by the community after which we will formalise the proposal. Thanks Fearghas EIX-WG Chair -- IPv6 Address Assignment Policy for Internet Exchange Points =========================================================== 1. Abstract ----------- This document describes a policy for Internet Exchange Points (IXPs) under which unique IPv6 address space to be used for the infrastructure of the Internet Exchange Point can be obtained from a Regional Internet Registry (RIR). 2. Background ------------- It has been recognised that there are scenarios in which it is not desirable for IXPs to obtain address space from one of the Internet Service Providers (ISPs) connecting at the IXP. In these cases it is viable to have unique IPv6 address space assigned directly from an RIR. This address space is needed to adress the Exchange fabric. This issue has been brought forward to the RIPE community in May 2000 and has subsequently been discussed at RIPE Meetings and on public RIPE mailing lists. The conclusions of these discussions are described in this document. It is expected that the same policy will be accepted in the ARIN and the APNIC region at which point it will be incorporated in the Global IPv6 Policy document. 3. Definition ------------- An Internet Exchange Point is defined as a physical network infrastructure (layer 2) operated by a single entity with the purpose to facilitate the exchange of Internet traffic between Internet service providers. The number of Internet Service providers connected should at least be three and there must be a clear and open policy for others to join. Addresses needed for other purposes (e.g. additional services provided to the members) should be aquired through other appropriate means ( e.g. an upstream ISP). 4. Policy --------- An IXP that seeks to obtain an IPv6 address assignment by the RIR in its region, needs to submit a request to that RIR. IXPs operating in the RIPE NCC service region should use the 'IPv6 Request Form for Internet Exchange Points' (http://www.ripe.net/ripe/docs/ipv6request-exchangepoint.html) After approval of the request, the RIR will make the assignment. Since the address space does not need to be routable globally and an IXP is expected to only have one subnet, a /64 (64 bits of address space) will be assigned in most cases. In the case the IXP is using multiple fabrics (e.g. unicast separated for multicast), multiple /64s can be assigned to the IXP. IP Address requests can only be handled if the requestor is a Local Internet Registry (LIR) or if the request made through an existing LIR. 5. Other Considerations ----------------------- It should be noted that ISPs usually do not announce address space used on the IXP mesh itself to their peers. That means the address space assigned under this policy is likely not to be routable globally.

6 8

Interim Policy discussion
by David Kessens 31 Aug '01

31 Aug '01

This is a request to keep our discussion focused: - let's try to keep the discussion on lir-wg. - the proposed policy is an interim policy, that means further changes can be and will made to the policy after it has been approved. we don't have to discuss all those changes right now, *unless* you cannot live with the interim policy at all without such changes. - the policy is not intended to solve all problems to everybody. I hope this helps, David K. ---

1 0

WG: I-D ACTION:draft-gopinath-host-name-resolution-protocol-ipv6-00.txt
by Thomas Trede 31 Aug '01

31 Aug '01

FYI. Regards, Thomas Trede -----Ursprï¿½ngliche Nachricht----- Von: owner-ipng(a)sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von Internet-Drafts(a)ietf.org Gesendet: Donnerstag, 30. August 2001 13:14 An: IETF-Announce: Cc: ipng(a)sunroof.eng.sun.com Betreff: I-D ACTION:draft-gopinath-host-name-resolution-protocol-ipv6-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Host Name Resolution Protocol (HNRP) for IPv6 nodes Author(s) : G. Sinniah et al. Filename : draft-gopinath-host-name-resolution- protocol-ipv6-00.txt Pages : 13 Date : 29-Aug-01 This document describes a new method, which will automatically acquire the host name of active IPv6 nodes and register it to the local Domain Name System (DNS) server. Active IPv6 nodes are nodes that are connected to a network. Our proposed new protocol, which is called Host Name Resolution Protocol (HNRP) [6], will automatically learn some useful information from all the IPv6 nodes, such as the host name and the IP address. All the information will be kept by HRRP and the host name together with the IPv6 address will be added to the DNS. This will be implemented without the need for any changes at the clients' site. The objective of this document is to specify the new Host Name Resolution Protocol and also the algorithm used in the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gopinath-host-name-resolution-prot ocol-ipv6-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-gopinath-host-name-resolution-protocol-ipv6-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-gopinath-host-name-resolution-protocol-ipv6-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ENCODING mime FILE /internet-drafts/draft-gopinath-host-name-resolution-protocol-ipv6-00.txt

1 0