Re: IP addresses for the RIPE NCC
On Wed, 8 May 2002, Hans Petter Holen wrote:
Dear working Group, Now that we have a new interim policy in place, an important policy question comes up: How can the RIPE NCC get IP addresses for their services ?
Either they qualify trough the Interim policy
or they need to go to their upstream.
what does it matter? Either way the RIPE NCC is going to be the ones making the final decision, be it a hostmaster or one of their tech staff.... -p
Hi, On Wed, May 08, 2002 at 12:59:14PM -0700, auto347221@hushmail.com wrote:
Dear working Group, Now that we have a new interim policy in place, an important policy question comes up: How can the RIPE NCC get IP addresses for their services ?
Either they qualify trough the Interim policy
or they need to go to their upstream.
what does it matter? Either way the RIPE NCC is going to be the ones making the final decision, be it a hostmaster or one of their tech staff....
Actually, they are NOT. *We*, as the community, have made the current IPv6 allocation policy. The NCC people have been helpful in organizing and documenting, but have refrained from pushing in any specific direction concerning the policy. As for the original question: I have discussed various options with Joao on the last RIPE meeting, and the outcome of this (which was also an opinion-forming process for myself) was that "take one /48 and announce that all over the place" is among current options the best one. The advantage of this approach is that: - we need no special policy for the NCC "and everybody else who is special" - we do not need to create PI legacy objects, or any other kind of "I get an allocation even if I do not assign to end users" networks - the effect on the routing table is the same for whatever kind of thing they are going to announce, but with this approach, if the /48 is filtered somewhere, the aggregate will provide "fallback", and thus better resilience. As for "which upstream to go to" - I think that with some careful planning in advance (insert proper macros in all configuration files that contain explicit IPv6 addresses, etc.) renumbering of a fairly flat IPv6 network *is* much easier than for IPv4, due to the fact that one can seamlessly add a second prefix and take away the first one some time later - with v4, this usually requires lots of rebooting and thus downtime. So based on this, I'd say "pick an upstream that isn't likely to go bankrupt any time soon, and seems to provide a reliable network, and if it turns out that they are not good enough, change to a different /48" (and be prepared to do so - by good documentation and pre-planning). [Yes, Randy, Nigel, and others - we all seem to agree, which is really unusual. Must be something wrong with this idea.] Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45077 (47584) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi, On Thu, May 09, 2002 at 12:51:27AM +0200, Gert Doering wrote:
I have discussed various options with Joao on the last RIPE meeting, and the outcome of this (which was also an opinion-forming process for myself) was that "take one /48 and announce that all over the place" is among current options the best one.
That should have read "take one /48 from one of the upstream's /32", of course. I think it was pretty clear in the argumentative text, but want to clarify it nonetheless. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45077 (47584) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
as my earlier recommendation attests, i agree with you. grab a /48 and do as in v4. except ... rfc 2772 - 6Bone Backbone Routing Guidelines 4. Routing Policies for the 6bone Leaf sites or pNLAs MUST only advertise to an upstream provider the prefixes assigned by that provider. Advertising a prefix assigned by another provider to a provider is not acceptable, and breaks the aggregation model. A site MUST NOT advertise a prefix from another provider to a provider as a way around the multi-homing problem. However, in the interest of testing new solutions, one may break this policy, so long as ALL affected parties are aware of this test, and all agree to support this testing. These policy breaks MUST NOT affect the 6bone routing table globally. ... All 6bone pTLAs MUST NOT advertise prefixes longer than a given pTLA delegation (currently /24 or /28) to other 6bone pTLAs unless special peering arrangements are implemented. When such special peering aggreements are in place between any two or more 6bone pTLAs, care MUST be taken not to leak the more specifics to other 6bone pTLAs not participating in the peering aggreement. 6bone pTLAs which have such agreements in place MUST NOT advertise other 6bone pTLA more specifics to downstream 6bone pNLAs or leaf sites, as this will break the best-path routing decision. cute, eh? will work well in scalable reality, eh? randy, struggling along in 2001:418:1::/48
Hi, On Wed, May 08, 2002 at 04:21:55PM -0700, Randy Bush wrote:
as my earlier recommendation attests, i agree with you. grab a /48 and do as in v4. except ...
rfc 2772 - 6Bone Backbone Routing Guidelines
4. Routing Policies for the 6bone
Does that one apply for people using 2001:: space? What is "the 6bone" anyway? Just being curious... :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45077 (47584) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Thu, 9 May 2002, Gert Doering wrote:
On Wed, May 08, 2002 at 04:21:55PM -0700, Randy Bush wrote:
as my earlier recommendation attests, i agree with you. grab a /48 and do as in v4. except ...
rfc 2772 - 6Bone Backbone Routing Guidelines
4. Routing Policies for the 6bone
Does that one apply for people using 2001:: space?
As a recommendation (like Best Current Practises) at most. I feel these rules should be adhered to the best we can. I see nothing seriously conflicting here and w/ RIPE NCC getting a /48 from upstream(s). Just live with the reality it cannot be announced any further than the operators you have direct connectivity with, with private agreement, which is ~ok by the guideline: However, in the interest of testing new solutions, one may break this policy, so long as ALL affected parties are aware of this test, and all agree to support this testing. These policy breaks MUST NOT affect the 6bone routing table globally. "global routing table" is the key here. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
| > 4. Routing Policies for the 6bone This document describes the use of 3ffe::/16 space: The 6BONE. | Does that one apply for people using 2001:: space? No. | What is "the 6bone" anyway? I find it strange that somebody who is at ripe meetings presenting routing table information (and brokenness) never took the time to actually find out what 'these weird 3ffe' addresses are! The 6bone is a layered network on top of the current public IPv4 networks, where people in the early 90s started testing their protocol implementation mainly using 5f and 3f (top 8 bits) prefixes. It grew, policy was made, people joined the 6bone to test on ISP rollout and such things. Due to the costs involved with LIR allocation (either pay ARIN, or pay an engineer to fight with RIPE for 4 months), lots of people stuck to 6bone space. It is sequentially allocated by Bob Fink (fink@es.net) and the DNS is maintained by Bill Manning (bmanning@isi.edu) who also maintains a global '6bone mailinglist' which discusses lots of technical issues from time to time. It's a majordomo@isi.edu list called '6bone'. The problem is: people on the 6bone are not always operators. Some are kids with cablemodems announcing to their (tunneled) peers origins as 64001 or networks that have never been allocated in the first place. Another strange situation is that because nobody had a decent shared medium to create native IPv6 peerings in the old days, people would erect tunnels to just about everywhere. For example, an Amsterdam based company would peer over a tunnel to someone in California and in New York. Because the AS path lengths are almost always NOT an indication on how the traffic flows, traffic simply bounces around everywhere and not taking the optimal routes. This should be avoided of course in the production network (which still tunnels quite a bit, of course). | Just being curious... :-) I sometimes envie you for not knowing what the 6bone is. And to come back to RFC2772, I was always a strict filter person and kick and stomp any of my peers that feed me crap, but after recent events (ripe42 is one of them) I am strongly thinking on easing my filters up a little to allow for /48 to make it into my route tables. groet, Pim -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________
Pim van Pelt <pim@bit.nl> writes:
| What is "the 6bone" anyway? I find it strange that somebody who is at ripe meetings presenting routing table information (and brokenness) never took the time to actually find out what 'these weird 3ffe' addresses are!
You completely missed Gert's question. Of course he knows what 3ffe is, but that was not the question. The question was how to precisely define it, in nowadays reality,
| Just being curious... :-) I sometimes envie you for not knowing what the 6bone is.
You still didn't define what the 6bone comprises. Any site which received an allocation? Wait, that's not sufficient since you can have a pNLA/pSLA without allocation. Any site which announces 3FFE prefixes? Well, then not all of them are bound by the agreement. Any site with a entry in the 6bone whois? Can I sign the agreement and not announce /48 to other 6bone sites, but announce to non-6bone sites? Back to the original question: I'd rather take Pekka's more practical approach and say that even the 6bone rules make allowances for e.g. a /48 announcement from RIPE as long as it's scope is limited. Allow it to be announced by RIPE to direct peers, and from them to their customers, but don't give any guarantee that it is globally visible. For true global multihoming of important services like whois, techniques can be used that work in IPv4 already: get two assignments, two AAAA records for the services, and possible some DNS magic with short TTLs and an "intelligent" DNS server to turn off AAAA answers if that uplink is seriously broken. Robert
Hi, On Thu, May 09, 2002 at 11:38:52AM +0200, Pim van Pelt wrote:
| What is "the 6bone" anyway? I find it strange that somebody who is at ripe meetings presenting routing table information (and brokenness) never took the time to actually find out what 'these weird 3ffe' addresses are!
That was ironic - I know what "6bone space" is (look it up in my slides ;-), and we started out with 5f* and later 3ffe space (from UUnet)) - but as a matter of fact, everybody means different things when speaking about "6bone". So the term is not *that* clear. When talking about "routing policies in the 6bone", one could argue that the RFC was written with the 3FFE test addresses in mind, but one could argue as well that "it logically extends to production IPv6 networks". Which it might or might not, depending on consensus among those that do try to run production IPv6... [..]
It grew, policy was made, people joined the 6bone to test on ISP rollout and such things. Due to the costs involved with LIR allocation (either pay ARIN, or pay an engineer to fight with RIPE for 4 months), lots of people stuck to 6bone space.
Hmmm. My application to RIPE took me about 2-3 hours of work (and two weeks of waiting), and half of the work was due to the fact that the form still had some rough edges. So "4 months" is definitely not fair to the RIPE people. [..]
Another strange situation is that because nobody had a decent shared medium to create native IPv6 peerings in the old days, people would erect tunnels to just about everywhere. For example, an Amsterdam based company would peer over a tunnel to someone in California and in New York. Because the AS path lengths are almost always NOT an indication on how the traffic flows, traffic simply bounces around everywhere and not taking the optimal routes. This should be avoided of course in the production network (which still tunnels quite a bit, of course).
Which is why I'm currently working (with some others) on a BCP proposal for "how to do BGP in the face of many tunnels so that other peers can see that this prefix with the nice-and-short path isn't as good as it looks like". Will be presented "soon". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45077 (47584) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert Doering wrote:
[Yes, Randy, Nigel, and others - we all seem to agree, which is really unusual. Must be something wrong with this idea.]
I think I shall go and lie down for a little. All this consensus is making me feel faint
Hi, to wrap up the discussion. We should get addresses from upstream provider(s). Next question: how many? I guess the RIPE NCC offices are "a site" and thus the need is for a /48 which we subnet internally. Probably another one for the RIPE Meeting, which is another site (a mobile one), with its own subnets. So far so good. Doubts come when I think about the tunnels we want to provide to our staff, as we do with IPv4. If I read the policy and the IETF statements, each of these sites, which normally have a Linux box acting as end point and subnets internally (even if each subnet usually has no more than one other box), would need a /48, as that is the minimum for a site. Or should we assign, say /56's? We estimate about 50 of these cases in a reasonable period of time. What makes a site? The length of the cable? The technology used to get the packets inside those cables? The desire to subnet? Something else? I have never been able to get a definition that suits more than a small portion of the people I talk to. I am very interested in your opinion both because we would like to roll out IPv6 services in the near future and to see what is the community's interpretation of the policy as a benchmark for our hostmasters. So consider yourselves the hostmasters for our request as I would like to avoid our own departments calling a judgement on our own address resources. Jooa
participants (8)
-
auto347221ï¼ hushmail.com -
Gert Doering -
Joao Luis Silva Damas -
Nigel Titley -
Pekka Savola -
Pim van Pelt -
Randy Bush -
Robert Kiessling