May 2002 - ipv6-wg - mailman.ripe.net

Re: Getting addresses
by Wilfried Woeber, UniVie/ACOnet 24 Oct '02

24 Oct '02

Hi Rudolf! >I am new to these discussions on the list, so if I am saying something >stupid, please tell me so. Not at all! The worst thing that is happening here is that we re-iterate things. So what.... >>I don't have a point of view. A lot of people are telling me they will >>choose the /48 road. Without a detailed definition of site, almost >>everyone's view will have to be accepted. That's what I am seeing in all >>these discussions. > >That is what has been bothering me the most in the whole discussion about >who gets a /32 assignment and who doesn't. This is one thing that is so surprising for me in these discussions: There seems to be an implicit assumption that we SHOULD come up with all sorts of criteria to BLOCK distributing IPv6 addresses, rather than getting the technology rolled out :-(). As an aside, I still see IPv6 address space as a *global resource*, not something which a (roughly) self-defined group of entities partitions amongst them (tier-X ISPs). Becoming an LIR is possible for (almost) every type and shape and size of organisations (at least in the RIPE region) - but it is not for free. There are quite some good reasons for distributing globally unique IPv6 addresses to entities which would not fit the "classical" ISP (or even tier-X ISP) definition. And those amongst us who worry about end-to-restoration, making things simple(r), looking into the future, should recognize that there is no "rfc1918" space in v6-land. (Yes, I know about the site-local address concept. But why should we plant time-bombs ticking when there are plenty of those magic bit combinations around?). >Both the number of /48 >assignments as well as the determination of what an end-site is, are >completely arbitrary I agree. It's the same level of "arbitray-ness" that is wired into "200 sites", trying to define an ISP, and the like. It's better than nothing at all (i.e. no consensus) - at least for now. >and therefore in the long run unworkable. We'll see. We havent tried yet. And by the way, we have tried to define "ISP" in v4-land for years, and we failed. > Almost >everyone that is an LIR now, is able through one trick or another to >justify an allocation of a /32 Actually, this was the point of view that had emerged in the RIPE region during the Jan'02 meeting. "Every LIR should get an allocation" if they can document the need for 1 address. The "tricking" started to come into the game when we again tried to impose (artificial) criteria/ limits/ restrictions/... Btw, I still do remember the days (around '93) when a LIR was allowed to give away a /23 to every "site", no questions asked. And it didn't *break* the Internet, it made it *succeed*! In the end every policy is a compromise. Some of us don't like the version we do have on the table right now because we think it is too restrictive. Some of us dislike the thing because we perceive it as too liberal. Such is life. > and as Joao points out, the RIR's won't be >able to do anything against it. The RIRs should not act *against* "something"! They are supposed to execute a consensus, written down in a document and agreed by the community! It took a loong time, and many discussions, to arrive at the doc we do have on the table right now. And there are things in it which are "fuzzy". That was done deliberately, after trying (and failing) to come to more precise (and sometimes restrictive) definitions that would still be acceptable to all the 3(4) regions. On the other hand quite a few things were straightend out (like the exclusive reference to a /48 holder), and I'd really urge all of you to *completely read* the final doc. > And then I wonder if in the long run we >won't see a global routing mess, because many more organisations will be >able to register as LIR and justify a /32 in the same way. This is exactly >what the requirement for 200 potential sites tries to achieve, but fails to >do. Well, again one of those "assumptions" that this is bad :-) I still think that we can accommodate a *lot* of IPv6 routing with the slack from the (predicted) growth in v4 that did NOT happen in v4-land.... >The community should be able to come up with a better definition of who >should be allowed to get a /32 and who is condemned to go to an upstream >provider. This should be more objective than the current rule and not >result in the problems that we see now for RIR's and IXP's and smaller >NREN's and ISP's, . Welcome to the show. I hope you would be around to help when we have to re-work the thing to adapt it to the evolving Internet :-) Just one comment on the use of "smaller" here: we couldn't come up with a good set of criteria to define a "smaller" "whatever". What are the criteria? Real estate? Gigabit/sec? Terabit storage? number of contracts? number of web pages? annual turnover? annual profit (or loss :-)? The tier-1 ISP of yesterday is the chapter 11 case of today and a department of another ISP tomorrow. As I said during the discussion, (given the IETF recommendation) a SOHO customer of a "commercial" ISP s/would qualify for a site .eq. a /48. Probably a handful of physical subnets would be used. And it is easy to have a few hundred of those, eventually (probably). A university, or a regional edu-network could be structured alongside a single /48 as well. Such a "site" could happen to serve some 5000..10000 ..50000 users in quite some hundred physical subnets (LAN, ISDN, ADSL, wire-less). Which of those network would be the "smaller" one?? Is it really "cheating" if we start to treat a primary and secondary school as a site with their own /48? Or the other way 'round, why is the "commercial ISP" not treated as a site with *1* /48? I am stretching things here just a little bit, on purpose... >I think we can evade a global routing slump if we allow the RIR's to >continue the excellent work they have done in the last couple of years. >They have conserved adresses well. In one of the doc.s there is that famous statement that conservation and routing aggregation can, or tend to, be conflicting goals. >But we should provide them with adequate >rules to work with, so that they can aggregate well in the IPv6 future too. > >>The problem is the lack of arguments for an RIR on what is the right thing >>to do. >> >>Joao > >Let us provide them with the right arguments to do the right thing. Fair enough, but - >Maybe we should take that discussion back to the global v6 list. wouldn't it be prudent to try to *implement* the new policy, learn by doing so, and *then* go back to the drafting table?! I do not believe anybody claiming that we/he/she can find out *now* what the best solution is in a few year's time. The 'net is constantly evolving.... >Greetings, > >Rudolf van der Berg >Dutch German Internet Exchange >http://www.ndix.net OK, I think I'll leave it at that for this discussion :-) Thanks for your good questions and observations! Cheers, 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

5 4

Status field for inet6num objects
by Joao Luis Silva Damas 08 Jul '02

08 Jul '02

[** Mail posted to both APNIC and RIPE lists in the hopes of trying to find a solution suitable for all users of RIPE or RIPE-derived software **] Dear all, the inet6num, like the inetnum object, has a field named "status" which stores some information about the nature or position of a block of addresses in the delegation chain, from the RIR through to the end user. Currently, the status field for inet6num object is generated by the Database software based on the size of the address block and its possible values are: o TLA o SubTLA o NLA o SLA This notation has been deprecated and it is time to adapt the database. Discussions on this matter have identified the usefulness of having the capability to distinguish between allocations made by the RIR, allocations made by an LIR or their customers and assignments to end users. As such, we propose to modify the "status" attribute of the inet6num object to be: a) not-generated. This means users must assign a value to the status attribute when creating the object, just as in the inetnum object b) have the following possible values: RIR-allocated LIR-allocated Assigned to be used according to the following set of rules: The RIR-allocated status can only be used in objects representing allocations created directly by the RIR. The LIR-allocated status can be used by LIRs and their customers to represent blocks of addresses that are not assigned to specific end users. There can be several levels of objects with this status. The Assigned status must be used in objects representing assignments to end users (households, companies, enterprises, etc) We hope that with this modification the information in the Database will more accurately describe the registration of IPv6 address space. A possible transition to the new values could be: 1) RIRs modify status fields for allocations 2) Any new objects and modifications to existing ones must have a value for the status field corresponding to the ones described above. Otherwise the update will fail. 3) RIRs contact LIRs to have the status of assignments and sub-allocations updated. Best regards, Joao Damas RIPE NCC

6 8

Draft Minutes (v1) IPv6 wg RIPE42
by David Kessens 04 Jun '02

04 Jun '02

Please see below for the first version of the draft minutes of the IPv6 wg at the last RIPE meeting. I would like to thank the scribe for writing down the minutes. The minutes will be declared final by June 7th if there are no objections raised and/or major changes required. Thanks, David K. --- Draft Minutes of the IPv6 Working Group session of the RIPE 42 Meeting, 29 April - 3 May 2002 at the Krasnapolsky Hotel, Amsterdam, Netherlands. The session was held on May 2, 14:00 - 17:30 ----------------------------------- Chair: David Kessens Scribe: Rainer R|cker Attendees: 113 ----------------------------------- Agenda: 1st slot A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. IPv6 roadmaps of network equipment vendors a. Juniper (Jean-Marc Uze, Elise Gerich) b. Cisco (Simon Pollard) C. Global IPv6 routing table status (Gert Dvring) D. Tunnelbrokers & ipv6 in practice (Pim van Pelt) related discussion topic: do we prefer to use 6to4 instead of tunnelbrokers ?!? 2nd slot E. IPv6 Promotion Council Activities Overview (Kosuke Ito) F. IPv6 capable RR DNS servers - what is needed, what are the issues ?!? (Joao Luis Silva Damas, RIPE NCC) G. IPv6 RR DNS - is it ip6.int or ip6.arpa? Why? Documented where? (Joao Luis Silva Damas, RIPE NCC) related topic: 6to4 reverse delegations H. lbnamed Bug Discussion I. IPv6 allocation survey (Mirjam K|hne, RIPE NCC) J. Euro6IX and layer 3 IX addressing (Raffaele D'Albenzio) K. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) - French NIC initiative regarding DNSv6 deployment (Mohsen Souissi) L. LIR-WG session on IPv6 policy Z. AOB ======================== A: Scribe, Agenda bashing ======================== Two scribes from the RIPE NCC. One additional presentation from the tipster project was accepted for point K on the agenda. The Agenda was accepted. ======================== 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. ?: 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. ?: Will you implement NAT/PAT for v6? JMU: Not on the short term. ======================== B. IPv6 roadmaps of network equipment vendors b. Cisco ======================== Simon Pollard (SP) presented Ciscos Roadmap for IPv6. The slides are available at Gert Dvring (GD): The IOS upgrade is not really free available - you need to buy the IP+ option package before you can make the upgrade. SP: This is true for the low-end platforms - but most people have IP+ anyway PVP: What about filtering and OSPF6. SP: Available - a beta of OSPFv3 will be out in October 2002. ?: What about Layer3 Switches? SP: They will come in Q3/2002 ?: Will there be a Ciso-PIX for IPv6? SP: This is planned for Q1/2003 ?: Is there 6PE and NAT/PAT for v6? SP: Yes, we have this for the PE-routers GD: IOS has become very large - you can't fit it into the small routers without upgrading Flash and Memory. Customers are not willing to spend money in order to upgrade. Make IOS smaller. An Image-size of 4MB would be good. SP: Customers will pay for the router-upgrade if they see the business drive of IPv6. However, Cisco is working on re-packaged IOS for the lower platforms. The memory-footprint will probably be 8 MB. GD: 4MB should be the target. ======================== C. Global IPv6 routing table status ======================== Gert Dvrings presentation is available at http://www.space.net/~gert/RIPE/R42-v6-table/ Conclusions: - Downstream filtering recommended - You should watch the announcements of your peers. PVP: 6bone has changed it's policy to give out /32 now, four of these prefixes should be visible. 15 are in the table. ?: Is there a canonical filter-list for IPv6 ? GD: Not yet. ?: Would you be up to maintain such a list? GD: I will discuss this with David Kessens and we should move the discussion on this topic to the mailing-list. === ;7777777;7777777;7777777 COFFEE BREAK ;7777777;7777777;7777777 10:35 - 10:50 ;7777777;7777777;7777777 === ?: Is it easy to filter unassigned ASNs ? GD: Technically this is possible but it's preferable to talk to the people that are making the mistakes. ======================== D. Tunnelbrokers & ipv6 in practice ======================== Pim van Pelts presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6… PVP: Sixxs, a IPv6 tunnel-broker for LIRs in the RIPE-region is looking for participants that are willing to be a POP for this service. ?: What about the 6-to-4 tunnels? PVP: At the time we started, static tunneling was the only thing available. Today, if you run a 6-to-4 relay, it's easy for everyone to join, so it's also easy for everyone to abuse the service. If you host the relay, you also have to filter the incoming IPv4 traffic which is not easy. Attacks by script-kiddies on the next-hop of the relay (which is IPv4) are common today. DK: There have also been native V6-DoS-attacks, it's really scary. ======================== E. IPv6 Promotion Council Activities Overview ======================== Kosuke Ito's presentation can be found at ??? See also http://www.v6pc.jp/index_e.html - The audience had no questions or comments. ======================== F. IPv6 capable RR DNS servers - what is needed, what are the issues ?!? ======================== DK: IPv6 capable RR DNS Servers should be discussed in the LIR-WG. - the audience agreed ======================== G. IPv6 RR DNS - is it ip6.int or ip6.arpa? Why? Documented where? ======================== Joao Luis Silva Damas presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6… The recommendation is to populate ip6.arpa and phase out ip6.int - but what is wanted and how shall we proceed? ?: Software currently relies on ip6.int - you can't just switch it off. ?: Can't we just duplicate the delegation-records? GD: A good solution would be a CNAME very high in the hierarchy DK: Can't we just do automatic delegation in both domains? Joao: ip6.int should be abandoned soon - if we duplicate it will not go away. GD: But older machines all use ip6.int. Joao: OK, for the time being both delegations are possible. But should it be done automatically or do we only delegate in ip6.int if someone really wants it? GD: RIPE NCC should investigate if it's possible to do away with ip6.int and make a solution with CNAMEs. Make some experiments and report at RIPE 43 ACTION on RIPE NCC: Investigate the CNAME solution for v6-reverse delegation. Wilfried Woeber: Automatic delegation for ip6.int and ip6.arpa appears the best solution, but if someone requests different delegations in ip6.arpa and ip6.int, RIPE NCC should not prevent this. Mohsen Suissis: RIPE NCC did this in the past, at least for 2002:0660::/35 both delegations were made. DK: RIPE NCC, could you investigate the possibilities? Joao: OK, we will do the automatic delegation in both trees by default and we will allow different configuration if the user wants it. ?: But would this approach not lead to inconsistent data in the two domains? DK: It's only reverse delegation, that should have no big impact. DK: OK, 6-to-4 reverse delegation will also happen in ip6.arpa. What about this? Joao: The draft on 6 to 4 DNS (draft-ietf-ngtrans-6to4-dns-00.txt) is not very specific. RIRs will do the delegation based on the IPv4 /8s that they are authoritative for, but anything else is not clear yet. DK: What about the 6bone addresses and ip6.arpa Joao: I am not familiar with that. DK: Could you investigate this and give a more specific presentation at RIPE 43? Joao: Sure. ACTION on RIPE NCC: Give an overview of 6-to-4 reverse delegation issues at RIPE 43 ======================== H. lbnamed Bug Discussion ======================== Francis Dupont explained that an updated version of lbnamed is available and urged everyone using lbnamed to update to the latest version. ======================== I. IPv6 allocation survey ======================== Mirjam K|hne announced that the survey will be published on the web. The presentation was not given in this session due to shortage of time. The survey is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6… ======================== J. Euro6IX and layer 3 IX addressing ======================== Raffaele D'Albenzio's presentation is available at http://www.euro6ix.net/mantenimientos/e-doc_subidos/D1.1_Project_Presentati… (needs to be verified!) - The audience had no questions or comments. == DK reminded that there is not much time left. The time for each of the following presentations was restricted to less than 5 minutes. == ======================== K. Developments/initiatives regarding IPv6 in the RIPE region and beyond The Hungarian Tipster6 project ======================== Geza Turchanyi gave a short overview on the tipster6-project and provided some statistics on the v6-capability of several unix-distributions. (Sun, BSD, Linux) ======================== K. Developments/initiatives regarding IPv6 in the RIPE region and beyond French NIC initiative regarding DNSv6 deployment ======================== Mohsen Suissis presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6… Mohsen Suissis pointed out that currently not many TLD-Nameservers are native v6-speakers. AFNIC is willing to help other NICs to roll out v6 DNS. AFNIC also applied to become secondary for ip6.arpa. The request was submitted to IANA but nothing happened so far. ======================== L. LIR-WG session on IPv6 policy ======================== The iproposal for a global interim IPv6 Allocation Policy was accepted by the LIR-WG. ======================== Z. AOB ======================== Nothing reported ======================== Summary of actions arising from this meeting ======================== 42.1 ACTION on RIPE NCC: Investigate the CNAME solution for v6-reverse delegation in the ip6.int tree. 42.2 ACTION on RIPE NCC: Give an overview of 6-to-4 reverse delegation issues at RIPE 43

7 11

RE: New Document available: RIPE-233
by Michel Py 30 May '02

30 May '02

Havard, > Havard Eidnes wrote: > I have to ask a rhetorical question here, what is a "block" in > this context? > Is it a single routing announcement? Surely, it cannot be, > because the different root name servers are placed at different > points in the topology. The very purpose of placing them at different points is to have redundancy; so yes, for the same reason they must have different blocks. > I'll claim that the actual numeric sequence (or non-sequence) of > the IPv6 address blocks allocated to the root name servers do not > matter; the identity of the blocks will be well-known anyway, so > there is no robustness gain to be had from picking "obscure" or > "scattered" numbers. There is an advantage to scattered numbers, IMHO. Since they are scattered, nobody will try to aggregate them and suppress the specific announcements. Martian configs do happen; not often but they do. > I do however agree with those which have said that a root name server > should not have its address changed when it moves between RIR regions; > the whole point of this "special" assignment to the root name servers > is to avoid *any* renumbering because the DNS bootstrap data is > (currently) distributed in a static configuration file. There are (at least) two ways to achieve this: 1. Two-space systems (the servers would have a unique identifier and multiple changeable locators). 2. "special assignement" otherwise called PI. I think the RIRs have acted responsibly so far in not showing the bad example of allocating themselves a PI block. A short-term fix to this would be a two-space system where the locator initially assigned could be transformed into the identifier later. Michel.

1 0

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

Re: Getting addresses
by Joao Luis Silva Damas 14 May '02

14 May '02

I agree with Wilfried about the re-iteration, but it is probably just a reflection of the fact that the devil is in the details and you encounter details when you try to actually translate paper into action. 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). One thing the RIRs need, though, is a set of guidelines (policy) that is as clear as possible. Fuzziness leads to interpretations that might lead to a perception of unfairness. 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. Different ISPs will have different perceptions of what services they roll out to customers and how they position themselves in the market. That has always been the case, with ISPs or any other company, and an "IP allocation policy" should not attempt to dictate a business model. The only other criteria that is clearly set down in the current instance of the allocation policy is the number of sites the LIR expects to provide services to. Currently a minimum of 200 "planned" in a couple of years is the threshold. Fine. I understand this is a very flexible way of going about things, and probably a good one until there is a certain critical mass of IPv6 service providers. It also circumvents the need to discuss a "PI" policy now. Since the barrier is so low and refers to medium term plans, in practice almost any organization will be able to get an allocation. This last part, the "almost", is where I see people finding most of the problems. The difference between getting the allocation or not is not whether the organisation gets enough addresses, it is more likely related to the uncertainty of whether those addresses will be useful. In other words, if the routing announcements will make it throughout the whole IPv6 Internet without the need to do anything special. 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. 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. Cheers, Joao

1 0

Off-topic university networks. WAS Re:Getting addresses
by Rudolf van der Berg 14 May '02

14 May '02

At 17:09 13-5-2002, Michel Py wrote: >This is a grey area for sure. I don't think that providing access to >currently enrolled students can reasonably be considered bad use of >public money, for the good reason that a simple accounting trick will >assign that to tuition fees students do pay. Besides, access to the >university's computer resources is mandatory for studying, and a >university provided dial pool does have some operational advantages in >terms of security. Oh well, I'll pitch in on the discussion what universities do with their networks, having been the vice-chairman of Twente University's campus network (which included dial-in, ADSL and cable). Twente University saw it as a strategic decision for getting new students, changing the way people study and to support new (business) initiatives of students, to provide all on campus rooms in '94 with 10mbit connections (now 100mbit switched). Later they have extended these connections to every student and employee, so that they can now get a 130.89.x.x connection over cable, adsl, or POTS in the region of the university. For everything off-campus they made use of businesses, who were happy enough to have such a big customer. The university used its power to buy wholesale to get cheaper and better connections for all and realize the strategic objective that employees could work from anywhere. These are legitimate reasons and every business could/can offer to provide these services, so no anti-competitive behavior there. But yes, buying wholesale means that the profit per user is less for the provider, if anyone (Francis?) finds this anti-competitive... go ahead, challenge modern economics. :-) In the Netherlands Surfnet, the NREN, has been very active in hooking up student accommodations with fiber under the Gigaport FttD-project (Fiber to the Dormitory). The motivation for this was, that there would be no commercial provider willing to do this and offer gigabit connections to the dorms. Furthermore these projects are very helpful as pilots for fiber to the home projects. It has always been the goal of academic networks to support new developments. So I don't see a problem there either. A nice added bonus for providers is, that students that have tasted the sweetness of 100mbit links to the internet will generally opt for ADSL of cable services when they leave university. > > In terms of the get-outs, I expect that commercial spin-offs or > > products from the universities (e.g. a university selling > > intelligent widgets) may be hosted from a university with such a > > spin-off. > >Most of these will get grants that include cash from the university, >there is nothing fundamentally wrong in making connectivity part of the >grant. Agree, another way of solving it is what Twente University recently did.. They allowed separate VLAN's over their campus infrastructure, so that commercial parties on campus could hook up to commercial providers connected to the nearby internet exchange. Before this, commercial use was explicitly forbidden, because it violated the rules for use of the NREN. Now the commercial traffic is nicely routed of campus to a commercial party that can charge it. So no anti-competitive behavior there either. Even better... new business opportunities have emerged for some ISP's. Rudolf van der Berg Dutch German Internet Exchange (NDIX) http://www.ndix.net

2 1

Re: Getting addresses
by James Aldridge 13 May '02

13 May '02

Pekka Savola wrote: > On Mon, 13 May 2002, Xavier Henner wrote: > > > If you *do* have 200 IPv6 customers *today* (those that pay for the > > > service, not necessarily IPv6 service, but something), I'd surely conside r > > > one a real player here. > > > > > > But an issue is about DSL operators with 1,000,000 IPv4 customers > > > beginning to introduce IPv6 services.. > > > > I don't see any issue with DSL operators. > > Can you explain it ? > > With HD ratio of 80%, the operator would require a /23. Just because a HD ration of 80% is the minimum utilisation required to get a subsequent allocation, this doesn't mean that higher utilisation can't be achieved in some (and shouldn't be an aim in all) cases. I can imagine DSL operators offering /64 (single subnet) and /128 (single host) assignments to some customers (in the same way that single IPv4 addresses are often assigned now), in which case these 1,000,000 customers could be handled with an allocation of between a /39 and a /103 while maintaining an HD ration of 0.8 within that allocation - i.e. one /32 would be more than enough! James

4 5

RE: Getting addresses
by Michel Py 13 May '02

13 May '02

Tim, > Tim Chown wrote: > but yes a university may feel it wants to offer connectivity to > past students This is a grey area for sure. I don't think that providing access to currently enrolled students can reasonably be considered bad use of public money, for the good reason that a simple accounting trick will assign that to tuition fees students do pay. Besides, access to the university's computer resources is mandatory for studying, and a university provided dial pool does have some operational advantages in terms of security. However, providing access to past students could definitely be seen as using public money to compete with businesses. > staff. I do not think staff is a problem. They get a paycheck that contains public money, why can't they use a dial-up that is paid by public money? > In terms of the get-outs, I expect that commercial spin-offs or > products from the universities (e.g. a university selling > intelligent widgets) may be hosted from a university with such a > spin-off. Most of these will get grants that include cash from the university, there is nothing fundamentally wrong in making connectivity part of the grant. > the really fuzzy area is universities who use their academic > connectivity to give students access from halls of residence, which > if done with open ADSL-like rules may well let students run > commercial services. This is not that bad. Students have 10 meg connectivity in dorms. And yes, we know they'll use it not only for studying but also to surf porn and download pirated .mp3s. From time to time, an idiot will run a warez ftp server and will get busted. Frankly, I'd look the other way if I see a student that runs a website for his on-campus pizza delivery service that helps pay his/her tuition. I think it all comes down to this: fast and reliable Internet access is something that students need. Money and side jobs are also something lotsof them need. They are students for 4 years, after that they get a real job and pay for their own. Michel.

1 0

Re: Getting addresses
by James Aldridge 13 May '02

13 May '02

Pekka Savola wrote: > > I can imagine DSL operators offering /64 (single subnet) and /128 (single > > host) assignments to some customers (in the same way that single IPv4 > > addresses are often assigned now), in which case these 1,000,000 customers > > could be handled with an allocation of between a /39 and a /103 while > > maintaining an HD ration of 0.8 within that allocation - i.e. one /32 would be > > more than enough! > > IAB/IESG recommendation state /48 should be used in scenarios like this. Personally, I don't agree with the "/48 for all" policy but it's there so I suppose we have to live with it... Note, however, that rfc3177 is just the IAB/IESG *recommendations* in the form of a "best current practices" RFC. James

1 0

Re: Getting addresses
by Wilfried Woeber, UniVie/ACOnet 13 May '02

13 May '02

Sorry, Francis, >=> one detail which is never called to mind here is an university which >gives internet access to its students *outside* the university (i.e. >in a context where students can need a /48) should be sued by all >commercial ISPs for illegal competition using public money... but this statement is simply ridiculous.... and completely off-topic as well. 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

RE: Getting addresses
by Michel Py 13 May '02

13 May '02

David, > David Kessens wrote > You can present whatever you want, but I don't have a 'default > route' that points to any of my ipv6 peers. This is by choice and not by necessity, because you could have one if you wanted to. Here are a few definitions I glanced in what we are currently working on: 1. At the top level, the `default-free zone', it's not possible to define a default route. BGP speakers in the default-free zone really do need to have a route for every possible Internet destination. 2. The core of the Internet is also called the default-free zone (DFZ) because backbone service providers must maintain a complete map of all globally visible network prefixes reachable throughout the Internet: no default routes are allowed. 3. The Default-Free Zone (DFZ) of the Public Internet is where routers MUST maintain routing entries for all reachable destinations. In short: A router in the DFZ can NOT have a default route. These are tier-1 transit providers. Opposed to tier-2, where you CAN configure a default route to one or more of your transit providers; it actually is common practice for tier-2 to have a floating static default route as backup in case of BGP snafus. As of today, I have not seen a single IPv6 router where you could not configure a default route, as filtering (or the lack thereof) makes almost every peer a transit provider. The ipv6mh mailing list had this discussion a while ago and here is the definition we currently use: DFZ: the subset of routers that do not have a default route and do not receive a full routing table from a single peer. Michel.

1 0

RE: Getting addresses
by Michel Py 12 May '02

12 May '02

> This is very I advocate separate, "earmarked" blocks for > dialup/DSL/whatever, if it is done in such a big scale that /48 > for organization or /32 for an ISP would not be enough. > If you just give out an /32 which should be used for everything, > I think the problem is more serious. One can not know beforehand > how big a block of that /32 must be reserved to dialup/DSL/whatever. > And after it is reserved, what if there is a need to expand? These > things do happen within a time span of 2-3 years. This is where HD > ratio is useful. I have not seen many universities growing their number of students that fast, but any there is a word to address this: PLANNING. If one evaluates that they would need more than a /32 in three years and don't have the 7,100 sites now, there is legitimate reason to ask why they think they need more a /32. I don't have a problem with that figure of 7,100 except that I would have placed the bar a little higher. As far as having multiple blocks, I personally prefer having only one. Michel.

1 0

RE: Getting addresses
by Michel Py 12 May '02

12 May '02

> Gert Doering wrote: As a side note: nothing prevents you from > making better usage of a /32 - 7100 users is the minimum value > you have to document to get a bigger block. > Depending on the way the internal network hierarchy works (if > it has few levels, and all entities at one level are similarily > sized) it is perfectly allowed to utilize 20.000 /48s or more :-) > - it all depends on your network structure. Pekka, I don't know how you came with these figures but Gert is absolutely right. The HD of a dial pool or tunnel pool depends on two things: 1. The HD of the hardware itself, as there are some strong operational incentives to allocate a block per device, such as allocating a block of 256 sites to an access server that has only 192 modems. 2. The network structure. For a dial pool that size, there is absolutely no need for more than one level of aggregation (that would be the pop level). The device with the worst HD I have used is Cisco AS5400, it has 648 modems and it is temping to allocate a block of 1,024 sites to it. That device itself has a HD of 0.934. Then you have the pop aggregate. In a single pop, the worst you can have is 33 of these boxes. This is 21384 sites on a /32, which is a HD of 0.899. On a 3-pop setup, the worst you would have 9 boxes per pop, which still is 17,496 sites and a HD of 0.881. This is the absolute worst case scenario. The bottom line is that a typically organized /32 dial pool has up to 40k sites. Michel.

2 1

Getting addresses
by Peter B . Juul 11 May '02

11 May '02

Hi! The danish research network is part of the native IPv6 project 6net. We've tried for some months to get some IPv6 addresses assigned for this, but the active guidelines - specifically the demand for three peers in the default-free zone, a demand that can't be met for political and economical reasons - made this impossible. I gathered that changes were a-coming and RIPE-42 might be a turning point in this. However, I was unable to attend, so I'd like to hear if any consensus was achieved in this? Peter B. Juul, Uniï¿½C (PBJ255-RIPE)

10 28

RE: Multi homed IPv6 (was: Re: Regarding IPv6 prefix filtering)
by Michel Py 11 May '02

11 May '02

> Arien Vijn wrote: > Sorry for the late reply. No need to apologize. > Layer 2/switch software issues kept my attention all week. You mean you had to _work_ ? That's terrible. > All right. But what about these VLANs then? Do you mean that VLANs have > to be defined on both sites of this router/firewall? That's the way I would do it. > Why do you think we need VLANs anyway? Why not just configure n > addresses in the same VLAN? For security issues. Having 90 different prefixes on the same VLAN does not sound good to me anyway. > - VLANs must be defined an must not conflict with those of other > members. Many members do have switches them selves in-between the > IX infrastructure and their border routers. This is not mandatory. In the study case, RIPE-NCC needs to connect to each AMS-IX participant. Let's say that RIPE-NCC has a router in front of the DNS server, that router connects to AMS-IX fabric via a trunk (Cisco's term would be routing on a stick). That router, on the RIPE side, connects to RIPE's switch fabric. - Vlan 277 on one side of the RIPE router can be vlan 377 on the other side. In that kind of setup, you have strict policy routing between the router subinterfaces anyway, so there can be a conversion matrix. - The connection between AMS-IX' fabric and a participant does not need to be a trunk. If the port is an ordinary one that belongs to only one vlan, there is nothing wrong in having two different VLAN numbers. > - VLANs must be configured correctly in multiple places by > multiple parties. You do use something like VTP domains, don't you? > - Administer all these subnets and then hoping peers will route > it correctly. The peers' issue, not AMS-IX. > Suppose we can deal with this. Then it *might* work for UDP but what > about TCP sessions? Failover is a MH requirement too. Failover is a requirement of _real_ multihoming, which is available next year not today. > Is this worth the manpower? > In other words it is too much of a hassle for a solution which, might > be working (but not all the time). Your decision, not mine. > Advertising /48 is unsatisfactory from an aggregation point of view. > But it is the only working MH "solution" at the moment. I actually have less of a problem with the new policy that basically gives an allocation to anyone that wants one. It is a collective hypocrisy that is nothing less than recreating the pre-CIDR swamp. Nevertheless from a design standpoint it is preferable than punching holes in PA. > Our neutrality at least makes us reluctant to use provider space anyway. Find a reason to allocate 200x /48s to foreign entities and get a /32 by the new policy. The only problem with that is that you would appear as the fireman that puts gas on the fire. > I would very much like to see a working and scalable solution. It > would solve one of the main IPv6 issues for neutral, in-depended > entities, which just do not fit the customer-ISP-upstream model. You are encouraged to comment on what we have in the pipe. Michel.

1 0