- ipv6-wg - mailman.ripe.net

New Document available: RIPE-233
by RIPE NCC Document Announcement Service 30 May '02

30 May '02

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-233 Title: IPv6 Addresses for Internet Root Servers in the RIPE Region Author: Joao Luis Silva Damas Date: 24 May 2002 Format: PS=9362 TXT=2362 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- The "IPv6 Addresses for Internet Root Servers in the RIPE Region" document describes the special case assignment policy for Internet DNS root servers in the RIPE region. Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The document will be available shortly on the FTP-server at: ftp://ftp.ripe.net/ripe/docs/ripe-233.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-233.txt plain text version You can already access the RIPE document in HTML format via WWW at: http://www.ripe.net/docs/ipv6-rootservers.html Kind Regards, Jeroen Bet RIPE NCC Webmaster

10 14

RE: Draft Minutes (v1) IPv6 wg RIPE42
by Jean-Marc Uze 29 May '02

29 May '02

Hi David, > ======================== > B. IPv6 roadmaps of network equipment vendors > a. Juniper > ======================== > Jean Marc Uze (JMU) presented Junipers Roadmap for IPv6. > The slides are available at > > Pim van Pelt (PVP): What about Filtering and OSPF6 ? > JMU: OSPF6 for Junos will come in the second half of 2002 > Filtering will come soon. I think you mean OSPFv3. Regarding IPv6 filtering, I said that it will be available in a couple of weeks. Which is true ;-), as it is now available in last release: JUNOS 5.3 http://www.juniper.net/techpubs/software/junos53/swconfig53-ipv6/download/f… > ?: Are you working on 6-to-4 transition? > JMU: Are there already applications that need it? > ?: 6-to-4 relays will need it, these will be important for the users > ?: What about 6PE? (MPLS over IPv6) > JMU: Should be avoided on core routers, since it degrades performance. I think what I said is that 6PE will be attractive for SP that want to deploy native IPv6 service with an existing core backbone that can't implement IPv6. With 6PE, the core is not involved in IPv6 forwarding, just MPLS forwarding. So 6PE is a good solution to integrate native IPv6 service in existing backbone, as it required IPv6 routers only in the edges. This is in our plan for second half 2002. > ?: Will you implement NAT/PAT for v6? > JMU: Not on the short term. > Regarding the transition mechanisms, the message I wanted to give is that the mechanisms are numerous. 6to4 had gained a lot of traction last year but in recent times IETF has come up with even newer transition mechanisms. The priority was dual stack, IPv6 in v4 tunnels, as well as Circuit Cross Connect support for IPv6 (layer 2 VPN over MPLS). This phase is achieved. 6to4 as well as other mechanisms like NAT-PT are under investigation but we didn't get a strong push from our customers so far. Inviting the vendor to the RIPE IPv6 WG is a good way to discuss this topic. After the first feedback received at the conference we would be more than happy to get more feedback from you. David, I'm going to send you my presentation separately (big file) so you can put it on your web server. Thank you for your invitation. Regards, Jean-Marc Jean-Marc Uzï¿½ Liaison R&E Networks and Institutions, EMEA Juniper Networks 70 Boulevard de Courcelles - Paris 75017 - France Tel: +33 (0)1 44 01 60 24 Fax: +33 (0)1 44 01 60 90 Mobile: +33 (0)6 15 43 25 12

1 0

RE: New Document available: RIPE-233
by matthew.ford＠bt.com 24 May '02

24 May '02

" It is not associated with the organisation(s) that operate the root server at a particular point in time and these organisations should not use the address space to provide any services not related to the root server." s/should/must/ Mat. > -----Original Message----- > From: RIPE NCC Document Announcement Service [mailto:ncc@ripe.net] > Sent: 24 May 2002 16:01 > To: ipv6-wg(a)ripe.net > Cc: lir-wg(a)ripe.net > Subject: New Document available: RIPE-233 >

1 0

Implementation of Global IPv6 Policy
by Mirjam Kuehne 24 May '02

24 May '02

Dear Colleagues, We are pleased to announce that the RIPE NCC will implement the new Global IPv6 Policy on 1 July 2002. This policy has been agreed by the communities of all the Regional Internet Registries (RIRs). Before 1 July 2002 we will publish and announce the following as RIPE Documents: - Global IPv6 Policy Document - Initial IPv6 Allocation Request Form in the RIPE NCC Service Region - IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region (for prefixes shorter than a /48) Regards, -- Mirjam Kuehne RIPE NCC

7 6

Re: Getting addresses
by João Carlos Neves Cabral 21 May '02

21 May '02

Hi everyone, Perhaps this has been mentioned on the thread before, if so I must have missed it with so many messages, sorry :( Could someone point me out to the RIPE allocation policy? Which of the two below applies now ? I was under the impression that: IPv6 Address Allocation and Assignment Global Policy applied now, but I can't find a form @ RIPE for requesting IPv6 addresses with this policy. Is the old policy still in place ? Sorry if it is a dummy question, Thanks for any information, Best Regards, Joao Cabral. JC310-RIPE ---------------------------------------------------------------------------- ------------- in ripe-196: http://www.ripe.net/ripe/docs/ripe-196.html Subject to sections 4.2.2, and 4.2.3, Regional IRs will only make an initial allocation of sub-TLA address space to organisations that meet criterion (a) AND at least one part of criterion (b), as follows: a. The requesting organisation's IPv6 network must have exterior routing protocol peering relationships with the IPv6 networks of at least three other organisations that have a sub-TLA allocated to them. AND either b(i). The requesting organisation must have reassigned IPv6 addresses received from its upstream provider or providers to 40 SLA customer sites with routed networks connected by permanent or semi-permanent links. OR b(ii). The requesting organisation must demonstrate a clear intent to provide IPv6 service within 12 months after receiving allocated address space. This must be substantiated by such documents as an engineering plan or deployment plan. ---------------------------------------------------------------------------- -------------- in IPv6 Address Allocation and Assignment Global Policy: ftp://ftp.cs.duke.edu/pub/narten/ietf/global-ipv6-assign-2002-04-25.txt quote: To qualify for an initial allocation of IPv6 address space, an organizaion must: a) be an LIR; b) not be an end site; c) plan to provide IPv6 connectivity to organizations to which it will assign /48s, by advertising that connectivity through its single aggregated address allocation; and d) have a plan for making at least 200 /48 assignments to other organizations within two years. ---------------------------------------------------------------------------- -------------- --- Joao Cabral Vodafone - Portugal Engineering - Network Planning and Design Tel: +351 - 23 - 0915818 Mobile: +351 91 8736538 ---------- This message may contain confidential information or privileged material, and is intended only for the individual(s) named. If you are not in the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.

1 0

RE: Getting addresses
by Michel Py 20 May '02

20 May '02

Gert, > Gert Doering wrote: > I'm strictly against IPv6 PI. The problem in saying this is that you do not have a replacement solution. The reason we never got rid of the v4 swamp crap is because we do not have to offer people that have a prefix in the swamp any alternative that makes business sense. I hear a swamp /24 sells for $10,000. When IPv6 becomes a real business, becoming a LIR will just be "cost of doing business". > IPv4 PI nowadays is far too cheap, at least in RIPE land I know lots of people in RIPE land that says it's far too pricey. > I do not say that there won't be anyone doing this - but I am fairly > sure it *will* reduce the number of "pseudo-PI-for-multihoming" > prefixes we'll see. I do not agree. I have been known to get stuff from RIRs that I am not supposed to have, and becoming a LIR is no different. You just have to fill the paperwork the way it is supposed to. I am not saying that cheating (to become a LIR when all you need is to be multihomed) is good, but thinking that RIRs can enforce a no-cheat policy is worse. > /48s from LIR-/32s being visible in "the table". At least > "regionally", like "two AS hops away from the originating AS", or > something like this. This is not enough for most multihomers. Actually, it might be considered worse than being singlehomed: It gives the primary LIR even more leverage. It seems to me that you might not have realized something fundamental about IPv6: it is never going to fly if it does not offer _better_ than IPv4 does; just being even would be having some form of address independent from the provider, and you still have to come up with a good reason to go through the migration headache. Michel.

1 0

RE: Getting addresses
by Michel Py 16 May '02

16 May '02

Pekka and Gert, > Pekka Savola wrote: > I don't think university-like organizations ever need more than > a /48. One and the only really problematic thing is if they > provide access to students/staff/etc., e.g. via DSL, dial-up, > dorms or what. /64 would usually be ok (except very large > universities and the like), /48 would not. Universities are ISPs, and it is perfectly legitimate to assign /48s to students. Invariably, each class I teach IPv6 subnetting, students ask me "ok, now what if want to try this?" and my answer is "go to freenet6 and get a /48". Yes, they're going to use only two or three subnets possibly with only with one host each but they do need more than a /64 and I do not think that allocating anything between a /48 and a /64 is debatable at this point. > How do you think that e.g. Nokia, Cisco or Microsoft will do this? > I think everyone agrees that /48 should be very well enough, Pekka, I am sorry but this is wrong. One of the valuable participants we have in ipv6mh is Craig Huegen, the lead network architect for Cisco, and the _first_ question he asked about the protocols we are developing is how they would work for people that need more than a /48. With an HD of 0.8 Cisco needs between a /46 and a /45. > Gert Doering: > So with some reason instead of a "this can't work!" attitude, I think > this can work well - if one insists on doing non-useful things, it will > break (but yes, this is a problem with the "one site" = /48 rule, because > it's too vague to work unless people are reasonable). Yes, the "one site" = /48 rule leads to terrible HD, but a university with 50K students would indeed fit within a /32. The question is: will people be reasonable. Michel.

12 28

RE: (ipv6-wg) Roadmap to IPv6 multihoming: no PI addresses
by Michel Py 16 May '02

16 May '02

> Francis Dupont wrote: > => MHAP is a two space solution (PAs are locators, PIs are > identities) These locators are provider-independent, but should really _not_ be called PI for two reasons: 1. They do _not_ appear in the global routing table. 2. Most of them are geographically aggregated. > and draft-ietf-ipngwg-esd-analysis-05.txt should be read in order to > understand pros & cons (note: this draft is expired and can be hard > to find). http://arneill-py.sacramento.ca.us/ipv6mh/draft-ietf-ipngwg-esd-analysis -05.txt Note that this draft is not completely relevant to MHAP. MHAP does have strong similarities with GSE, but is a different protocol as well. Michel.

1 0

(ipv6-wg) Roadmap to IPv6 multihoming: no PI addresses
by Michel Py 16 May '02

16 May '02

Ipv6-wg folk, This is my candid view on IPv6 multihoming, comments welcomed. Enjoy, Michel. +-----------------------------------------------+ | Roadmap to IPv6 multihoming: no PI addresses. | +-----------------------------------------------+ Assessment of the current IPv6 multihoming situation: ----------------------------------------------------- - Regardless of the availability of multihoming protocols, independence from the service provider is highly desired by multihomers. - The pressure is increasing on RIRs to allocate PI blocks. - RIRs have delayed PI allocation as it creates long-term known problems. - The current policies effectively prohibit multihoming for everyone but ISPs (even RIRs themselves can not use PI addresses). - It is clear at this time that PA addresses alone do not address today's needs. The current roadmap to IPv6 multihoming is: - Offer a short-term alternative that would prevent the deployment of PI addresses: "geo for now". - Finish developing a long-term, scalable solution: MHAP. - ISP multihoming remains unchanged. "geo for now" ------------- The idea is to create a low-ambition geographic aggregation model that can be adopted using today's technology, requires no changes to physical infrastructure and few changes to current operational practices. Current work includes making geo for now and MHAP compatible to the migration from the shorter-term geo for now to the longer-term MHAP smooth. Geo addresses are: - Allocated depending on the location of the site. - Allocated by RIRs or NIRs - Locally portable. - Globally unique. - Aggregatable. Regardless of the actual aggregation ratio achieved, geo addresses are always preferable to PI; PI addresses will never be aggregated, geo will some day. Therefore, no IPv6 PI addresses must be ever used in any situation and geo addresses must be used instead. In other words, PI addresses offers no hope of aggregation, geo addresses do. The choice between PI and geo is a no-brainer: geo. MHAP ---- This is currently a working document of the ipv6mh mailing list. The draft is relatively mature and an earlier form was submitted to the IETF a year ago (it has evolved since then). MHAP is a full-blown mid to long-term solution. MHAP Features: - Zero impact on the DFZ's routing table. The DFZ's routing table stays strongly aggregated. - Provides multihomed, provider-independent, /48 address space for any site. - Very large organizations that require more can get a /47 or bigger. - Scalable (4 billion multihomed sites, initial allocation). - Addresses are aggregated at geographic areas boundaries. - There is no need for Internet eXchanges at aggregation boundaries. - MHAP is transparent to hosts. No modification of existing stacks is required and end-to-end traffic is unchanged. - More than 90% of routers would not require modification. - Provides global load balancing. - Provides survivability of open sessions. - There is no MTU reduction. - Can be run on hardware available today. - Gradual migration, no "flag day". - IPv6 only protocol. - MHAP provides site multihoming. ISP multihoming is unchanged. MHAP Concepts: - Multihomed address space exists only at the edge. The end-to-end multihomed traffic is carried over aggregated PA address space in the core. - A site gets PA addresses from ISPs and multihomed provider-independent space from a registry. - The process of transforming multihomed traffic to PA and back is called aliasing and relies on the presence of rendezvous points and aggregators. - Rendezvous points and aggregators answer topology requests. They do not carry traffic. - There is a separation between the DFZ's routing table and the multihomed space routing tables. The entire multihomed space is represented by two aggregates in the DFZ's routing table. - The only multihomed traffic on backbones is topology requests and routing updates. - There are two types of multihomed addresses: o Centralized, portable, for large multinational organizations. o Geographical, portable only within a geographic area. - There is no centralized table for geographic addresses. - The routing table for centralized prefixes remains contained to rendezvous points. - No multihomed site receives full multihomed tables. All a multihomed site needs is the small DFZ's routing table.

2 1

RE: Getting addresses
by Michel Py 14 May '02

14 May '02

Joao, > Joao Luis Silva Damas wrote: > My questions so far have not been trying to find a way of giving > any RIR arguments to fight against the deployment of IPv6 or > anything else in the Internet. If the RIRs ever become a stumbling > block for the development of the Internet you might just as well > get rid of them (us). On the other hand, RIRs have a role to play in controlling practices that lead to problems in the long run, such as the v4 swamp. > Currently, the policy refers to the concept of "site" which has > been left intentionally "fuzzy". That is OK as a starting point, > to be refined later, as we (all) gain experience. In practice, > this fuzziness will be translated into acceptance of any definition > of "site" that a requester puts forward. And each site is entitled > to a /48 as per the IAB's recommendation, which seems to be widely > accepted. I think there is a de-facto definition of site, though. - No subnetting = /64 - Some subnetting = using what was used to be called the SLA bits = site = /48. > And we get to the magical word: multihoming. > Organisations which fear not having their addresses routed when > they multihome might generate requests that ensure they get a /32. > If conservation is not a problem, this should also not be a problem. It actually is in the long run, and there is a balance to find here: Even if saving IPv6 addresses is not the goal, one must be careful in not creating monstruosities. A /48 is overkill already for most multihomers. Making it a /32 is a monstruosity. In order to eliminate the fuzziness you mentioned above, the policy needs to either: a) Allocate a /32 to everyone. b) Have clear rules if multihomers get a different size (which I do not recommend at this point in time). > In practice the current policy is equivalent to the one suggested > in January: When you have plans to use IPv6, become an LIR if you > aren't one already. The RIR will register the numbers. Again, this is not a rant about the new policy, I actually support it in the lack of a better one. Nevertheless, in practice the new policy is equivalent to giving a /32 PI to multihomers, as cheating to fulfill a legitimate business need is done. We have seen increases in 6bone pTLA requests, and we will see requests for LIR allocations for the same reason: Get a global prefix that will be seen in the global routing table. We have done that in the past already: it's called the pre-CIDR swamp. Having everyone become a LIR can _NOT_ continue forever. There is a limited time we collectively have before we have to define a new policy. > If the RIRs ever become a stumbling block for the development of > the Internet > And we get to the magical word: multihoming. If a multihoming solution is not deployed during this limited time I just mentioned, I hope that everyone understands what will be the next RIR policy in order not to become a stumbling block for the development of the Internet: "Give a /48 PI to anyone that wants one" The writing is on the wall. I renew my call to people with a brain in working order to join the effort in developing a v6 multihoming solution before it is too late. Michel.

1 0