IXP networks routing
Hi, as an IXP-Operator I would like to comment this in three ways: 1. Requesting an Address-space be it v4 or v6 for an IXP-Infrastructure and not making it globally reachable somehow misses the point. It should be clearly reachable - ideally through *all* connected peers of the infrastructure. (they certainly can decide on the security for these destinations) 2. Address-space differs from IXP to ISP substiantially. ISPs hand out IP-addresses to customers and IXPs assign single (or *very* few) addresses to ISPs. That means that address consumption and renewals are very rare. Even the default allocations from the IRRs for IXPs is - to my opinion - far too large. 3. Same with the members fee. Ok, I am speaking for a small IXP, but a RIPE membership cannot be afforded right now. There is in contradiction the need for 1 single AS-number and one small prefix the cost which is normally calculated for the untrained new LIR ISP, who needs training, hostmaster-help, etc. Why not add a special categoy for IXP demands. There is a small number of them (50 in Europe?) and basicall NO effort after giving them their numbers for work. Best regards, Kurt Kayser Lars Erik Gullerud wrote:
On Tue, 2003-02-25 at 16:20, Stephane Bortzmeyer wrote:
On Tue, Feb 25, 2003 at 04:11:57PM +0100, Petr Baudis <pasky@pasky.ji.cz> wrote a message of 29 lines which said:
AFAIK they should not be globally routable and they are only for internal usage of the exchange points.
Very bad idea.
1) When you traceroute through an exchange point, the IP addresses you get should be routable, for easier debugging.
2) Path MTU discovery may depend on it.
Having IXP addresses not globally routable is as wrong as having RFC 1918 (or FECO::) addresses at an IXP.
No, very GOOD idea.
We block all inbound route announcements of IXP prefixes we are connected to on IPv4 for a very good reason, and I don't see what has changed from IPv4 to IPv6 that should make our routing policy any different for IPv6 IXP-space.
Hint - a lot of networks don't use "next-hop-self" on their border routers toward iBGP peers and instead carry a route for the IXP block in their IGP so other BGP speakers have next-hop reachability. Some networks, unfortunately, also do NOT make sure to filter said IXP blocks properly. What do you think happens when suddenly a route for that IXP block leaks in on some peering session (on a different router than the one actually connected to the IXP of course), and eBGP has a lower administrative distance (preference) than the IGP - which is usually the default? Can you guess what happens to the traffic that should be going to a next-hop from that IXP-block? Yes, I've seen this very effect on several networks I've had the joy of troubleshooting, and could share some interesting stories on that topic.
As for your specific objections:
1) Why does this make for easier debugging? You get a perfectly valid ICMP reply from a valid IP address that you should be able to resolve in DNS without any problems as it is unique (global unicast). If you mean you would like to use the actual IXP IP-address as a destination for a traceroute, well - don't. You shouldn't need to anyway. And unless you are one of the peers I am speaking to over said IXP, you have no valid reason in my book to send any traffic to my border-router on that IP-address, and I don't see why I should let you. Hey, services like echo and chargen were once considered very useful debugging tools too - that doesn't mean anyone would recommend having said services open to the world nowadays.
2) How would lack of routability of this space break path MTU discovery? Please show me where in RFC1191 or RFC1981 it says that you would need to send any packets addressed directly to the IP who sent you a "Datagram Too Big/Packet Too Big" ICMP message in either IPv4 or IPv6, respectively, for pMTUd to work.
/leg
-- +++ Kurt Kayser Consulting - ISP & Carrier Netzwerkdesign, Planung, Schulungen *** Heinrich-Müller-Str. 1c, 90530 Röthenbach b.St. Wolfgang, Germany *** Tel: +49 (0) 9129 289315, Fax: +49 (0) 9129 289316, Mobil: +49 (0) 160 5810284
On Wed, Feb 26, 2003 at 02:10:41PM +0100, Kurt Kayser wrote: | Hi, | | as an IXP-Operator I would like to comment this in three ways: Hoi Kurt, | 1. Requesting an Address-space be it v4 or v6 for an IXP-Infrastructure | and not making it globally reachable somehow misses the point. It should | be clearly reachable - ideally through *all* connected peers of the | infrastructure. | (they certainly can decide on the security for these destinations) You probably are using this /48 out of 2001:7f8::/32 with the wrong reasons. It should be used for peering meshes and not for services at your IXP, and therefor it should not have to be routable or globally visible. If you want PI space for your IXP to run services in, you can join the long list of people that would like to have PI space in IPv6, which is simply not possible at this point in time. | 2. Address-space differs from IXP to ISP substiantially. ISPs hand out | IP-addresses | to customers and IXPs assign single (or *very* few) addresses to ISPs. That | means | that address consumption and renewals are very rare. Even the default | allocations | from the IRRs for IXPs is - to my opinion - far too large. The standard allocation size as per common practice at this point is either /64 or /48. More types of sizes are being debated all the time, but to this day, no other sizes have been established. A /64 might be too small for IXPs with more than one peering mesh, so the next step up is /48. | 3. Same with the members fee. Ok, I am speaking for a small IXP, but a RIPE | membership | cannot be afforded right now. There is in contradiction the need for 1 | single AS-number | and one small prefix the cost which is normally calculated for the | untrained new LIR | ISP, who needs training, hostmaster-help, etc. Why not add a special | categoy for IXP | demands. There is a small number of them (50 in Europe?) and basicall NO | effort after | giving them their numbers for work. You cannot identify your IXP as a special pig in the race of pigs. Therefor, no exception should be made for you, or RIRs, or any other enterprise. What would happen if every enterprise started an IXP and claimed a right to their own PI space ? It would become a mess! To put it frank: go to an upstream and request a block of 'PA' from their space to run your services in, and let them aggregate your traffic. If you want independability, go to multiple upstreams. groet, Pim -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________
Hi Pim (and mailing-list observers, of course :), please see my inline comments. Pim van Pelt wrote:
On Wed, Feb 26, 2003 at 02:10:41PM +0100, Kurt Kayser wrote: | 1. Requesting an Address-space be it v4 or v6 for an IXP-Infrastructure | and not making it globally reachable somehow misses the point. It should | be clearly reachable - ideally through *all* connected peers of the | infrastructure. | (they certainly can decide on the security for these destinations) You probably are using this /48 out of 2001:7f8::/32 with the wrong reasons. It should be used for peering meshes and not for services at your IXP, and therefor it should not have to be routable or globally visible.
We're currently only running v4 with PA-space, which is blocked by the LIR from whom we borrowed it. So w.r.t. v6, there are just link-local tests ongoing.
If you want PI space for your IXP to run services in, you can join the long list of people that would like to have PI space in IPv6, which is simply not possible at this point in time.
Agreed, that would be the way to go for me as well.
| 2. Address-space differs from IXP to ISP substiantially. ISPs hand out | IP-addresses | to customers and IXPs assign single (or *very* few) addresses to ISPs. That | means | that address consumption and renewals are very rare. Even the default | allocations | from the IRRs for IXPs is - to my opinion - far too large. The standard allocation size as per common practice at this point is either /64 or /48. More types of sizes are being debated all the time, but to this day, no other sizes have been established. A /64 might be too small for IXPs with more than one peering mesh, so the next step up is /48.
I'm again referring currently more to v4, since there are /19s or /20s default for new LIRs.
| 3. Same with the members fee. Ok, I am speaking for a small IXP, but a RIPE | membership | cannot be afforded right now. There is in contradiction the need for 1 | single AS-number | and one small prefix the cost which is normally calculated for the | untrained new LIR | ISP, who needs training, hostmaster-help, etc. Why not add a special | categoy for IXP | demands. There is a small number of them (50 in Europe?) and basicall NO | effort after | giving them their numbers for work. You cannot identify your IXP as a special pig in the race of pigs. Therefor, no exception should be made for you, or RIRs, or any other enterprise. What would happen if every enterprise started an IXP and claimed a right to their own PI space ? It would become a mess!
I do not consider myself a pig, so please let's keep this discussion on a serious level, ok? I sincerely believe in NEW IXP-members (not for free of course!), but with special conditions (no support, just one AS and one prefix) for the IXP-setup. I also believe in the RIPE-NCC to be able to distinguish between enterprises that might request a status of an IXP. It all depends of the policy and conditions.
To put it frank: go to an upstream and request a block of 'PA' from their space to run your services in, and let them aggregate your traffic. If you want independability, go to multiple upstreams.
First part has happened so far, but traffic for the network is a problem (basically who pays the upstream-ISP for the traffic) and connectivity is just not there. So it's a very bad hack for local connectivity, which could be greatly improved, if there are mechanisms in place that would allow this. .kurt -- +++ Kurt Kayser Consulting - ISP & Carrier Netzwerkdesign, Planung, Schulungen *** Heinrich-Müller-Str. 1c, 90530 Röthenbach b.St. Wolfgang, Germany *** Tel: +49 (0) 9129 289315, Fax: +49 (0) 9129 289316, Mobil: +49 (0) 160 5810284
Hi Kurt, Hi Pim, and everybody who listens, I would like to support Kurt´s request for inventing an IXP membership. Today the ixp´s are a vital part of the global infrastructure, but they are not represented as a legal member of ripe. Sure we can come to every meeting and can do nearly all the things the LIR´s are doing, but it is always some kind of guest status.
I also believe in the RIPE-NCC to be able to distinguish between enterprises that might request a status of an IXP. It all depends of the policy and conditions. This is very simple. Have a lock at the peering matrix and you can distinguish between a enterprise and an IXP (or am i wrong here?).
greetings - Stefan Wahl
On 02-03-2003 16:12PM, "Stefan Wahl" <swahl@netsign.de> wrote:
I also believe in the RIPE-NCC to be able to distinguish between enterprises that might request a status of an IXP. It all depends of the policy and conditions. This is very simple. Have a lock at the peering matrix and you can distinguish between a enterprise and an IXP (or am i wrong here?).
Well the fears are probably not concerning existing IXPs. The fear is that setting up an (fake) IXP becomes a way to get independent address space. Naturally, we do not want to create a chicken and egg situation when you limit "IXP-space" to well established IXPs only. Arien
Hi, On Tue, Mar 04, 2003 at 10:37:27AM +0100, Arien Vijn wrote:
Well the fears are probably not concerning existing IXPs. The fear is that setting up an (fake) IXP becomes a way to get independent address space.
Yep. This is what I tried to point out. I'm not fundamentally opposing anything here, I just point out "difficult issues". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
I would like to support Kurt´s request for inventing an IXP membership. Today the ixp´s are a vital part of the global infrastructure, but they are not represented as a legal member of ripe. Sure we can come to every meeting and can do nearly all the things the LIR´s are doing, but it is always some kind of guest status.
Uhm, we are a IX and we are a member? All you need to do is pay the membership fee. - kurtis -
Hi, On Sun, Mar 02, 2003 at 04:12:58PM +0100, Stefan Wahl wrote:
I would like to support Kurt´s request for inventing an IXP membership. Today the ixp´s are a vital part of the global infrastructure, but they are not represented as a legal member of ripe. Sure we can come to every meeting and can do nearly all the things the LIR´s are doing, but it is always some kind of guest status.
I don't understand this. The RIPE meetings, and the policy making working group (lir-wg) are open to everybody. This is not tied to being a LIR. What kind of disadvantage to you see for the IXPs here? [..]
I also believe in the RIPE-NCC to be able to distinguish between enterprises that might request a status of an IXP. It all depends of the policy and conditions. This is very simple. Have a lock at the peering matrix and you can distinguish between a enterprise and an IXP (or am i wrong here?).
So is C&W (just to pick one example) an enterprise or an IXP? Yes, I am nitpicking, but if you want to introduce special categories, you should be able to specify the criteria pretty well. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
[...]
[..]
I also believe in the RIPE-NCC to be able to distinguish between enterprises that might request a status of an IXP. It all depends of the policy and conditions. This is very simple. Have a lock at the peering matrix and you can distinguish between a enterprise and an IXP (or am i wrong here?).
So is C&W (just to pick one example) an enterprise or an IXP?
C&W is a enterprise. Period. They operate at least 2 IXP's, but if Enterprises operate a IXP or anyone who operates / will operate an IXP should taken care of. We should work on policies for the IXP-IPV6-SPACE ... (anyhow, gert, isn't SPACE in SpaceNet *SCNR*)
Yes, I am nitpicking, but if you want to introduce special categories, you should be able to specify the criteria pretty well.
But it's better that we do currently nitpicking than filling holes later on :-) --jan -- Jan Ahrent Czmok - Senior Network Engineer - Access Networks Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok@gatel.de
Kurt Kayser (kurt_kayser@gmx.de) wrote:
Hi Pim (and mailing-list observers, of course :),
please see my inline comments.
Pim van Pelt wrote:
On Wed, Feb 26, 2003 at 02:10:41PM +0100, Kurt Kayser wrote: | 1. Requesting an Address-space be it v4 or v6 for an IXP-Infrastructure | and not making it globally reachable somehow misses the point. It should | be clearly reachable - ideally through *all* connected peers of the | infrastructure. | (they certainly can decide on the security for these destinations) You probably are using this /48 out of 2001:7f8::/32 with the wrong reasons. It should be used for peering meshes and not for services at your IXP, and therefor it should not have to be routable or globally visible.
We're currently only running v4 with PA-space, which is blocked by the LIR from whom we borrowed it. So w.r.t. v6, there are just link-local tests ongoing.
Hi Kurt, Hi Pim, Isn't it always these PA / PI Discussion about the same issues ? In regards to the IPv6, what is a IXP offering ? (in technical sense): - Classic Services (e.g. providing Interconnect possibilities) - (sometimes) colocation space - New Services: (e.g. Tunnel Broker (?), Gateway (v4/v6) Multicast/Anycast ?, DiffServ, Billing(?) ... Therefore i would like to see that we are really doing back to a technical level to discuss possibilities and further development in the EIX stuff, not just bashing around with pigs and irons and politics. Many people tend to do this times, but we all should stick our head together and create services / ideas for the future.
If you want PI space for your IXP to run services in, you can join the long list of people that would like to have PI space in IPv6, which is simply not possible at this point in time.
I would not rather call it PI space.. why not defining and using IXP-space (with cooperation from the RIR (like RIPE/APNIC/ARIN etc.)
| 2. Address-space differs from IXP to ISP substiantially. ISPs hand out | IP-addresses | to customers and IXPs assign single (or *very* few) addresses to ISPs. That | means | that address consumption and renewals are very rare. Even the default | allocations | from the IRRs for IXPs is - to my opinion - far too large. The standard allocation size as per common practice at this point is either /64 or /48. More types of sizes are being debated all the time, but to this day, no other sizes have been established. A /64 might be too small for IXPs with more than one peering mesh, so the next step up is /48.
I'm again referring currently more to v4, since there are /19s or /20s default for new LIRs.
LIR != ISP != IXP !!!
| 3. Same with the members fee. Ok, I am speaking for a small IXP, but a RIPE | membership | cannot be afforded right now. There is in contradiction the need for 1 | single AS-number | and one small prefix the cost which is normally calculated for the | untrained new LIR | ISP, who needs training, hostmaster-help, etc. Why not add a special | categoy for IXP | demands. There is a small number of them (50 in Europe?) and basicall NO | effort after | giving them their numbers for work. You cannot identify your IXP as a special pig in the race of pigs. Therefor, no exception should be made for you, or RIRs, or any other enterprise. What would happen if every enterprise started an IXP and claimed a right to their own PI space ? It would become a mess!
Come on. Calm down. Think! Ripe is surely educated enough to differentiate between a Enterprise, ISP or IXP. To see real _further_ development, we should really propose to RIPE to offer a "IXP Membership" - these would help small IXPs to grow and to attract. And they are independant of ANY ISP or CARRIER, which is not good IMHO... Also we should see that we come to a more technical level on the RIPE Meetings. If compared to the NANOG Meetings (which are AFAIK different) i see more output and help from the talks at NANOG than at RIPE. At RIPE it has come to a tooo political level, which is really stopping things at the moment. But it's just my 0.2 EuroCent... --jan -- Jan Ahrent Czmok - Senior Network Engineer - Access Networks Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok@gatel.de
Hi, On Mon, Mar 03, 2003 at 10:08:11AM +0100, Jan Czmok wrote:
If you want PI space for your IXP to run services in, you can join the long list of people that would like to have PI space in IPv6, which is simply not possible at this point in time.
I would not rather call it PI space.. why not defining and using IXP-space (with cooperation from the RIR (like RIPE/APNIC/ARIN etc.)
We *have* IXP-space. There are special rules to get it, and it's not guaranteed to be routeable, which is clearly written into the policy. What people are asking for is *PI* - "get me space that is not tied to any specific ISP but that nevertheless can be routed over any of them". Currently there is no PI in IPv6, and many think that this is a good thing. [..]
Come on. Calm down. Think! Ripe is surely educated enough to differentiate between a Enterprise, ISP or IXP.
Can you *define* what is an IXP? In a way that an enterprise aiming for PI space can't cheat and match that definition? I cannot. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert At 22:20 +0100 3/3/03, Gert Doering wrote:
Can you *define* what is an IXP? In a way that an enterprise aiming for PI space can't cheat and match that definition?
what is the problem with the current definition that we have agreed on? f
Hi, On Mon, Mar 03, 2003 at 10:08:03PM +0000, Fearghas McKay wrote:
At 22:20 +0100 3/3/03, Gert Doering wrote:
Can you *define* what is an IXP? In a way that an enterprise aiming for PI space can't cheat and match that definition?
what is the problem with the current definition that we have agreed on?
The current definition is fine for the purpose we have: special-case, non-routeable (at least not guaranteed to) IXP address space. There's no big gain for an enterprise trying to cheat to get such a prefix For the proposed purpose - to get IXPs some sort of PI space - it's different - enterprises want PI, and if the only way they can get it is to claim to have setup an IXP, chances are that some will do. This is why we have to be careful here. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) 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:
For the proposed purpose - to get IXPs some sort of PI space - it's different - enterprises want PI, and if the only way they can get it is to claim to have setup an IXP, chances are that some will do. This is why we have to be careful here.
But there are many genuine reasons for getting PI - let us not forget. If someone thinks their PI assignment will be world routeable, good luck to them. Peter
Hi, On Tue, Mar 04, 2003 at 08:17:11AM -0000, Peter Galbavy wrote:
But there are many genuine reasons for getting PI - let us not forget. If someone thinks their PI assignment will be world routeable, good luck to them.
Right now, the global IPv6 policy has no provisions at all for PI assignments. This could be changed, of course, if we ("the RIPE policy making community") agree that this is a desireable goal. Let me ask you a question, though. What good is non-routeable PI (except for the IXP peering mesh)? So what good is it to have a policy that hands out PI without caring for routing? (In the IPv4 world, as you might know, there has a task force been formed to work on the PI policy - this conflict being one of the reasons behind) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) 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:
Right now, the global IPv6 policy has no provisions at all for PI assignments. This could be changed, of course, if we ("the RIPE policy making community") agree that this is a desireable goal.
As I *personally* see IPv6 as a dead duck (sorry all those who put work into it, but opinions are opinions) - so this matters little to me.
Let me ask you a question, though. What good is non-routeable PI (except for the IXP peering mesh)? So what good is it to have a policy that hands out PI without caring for routing?
Cough. Lucky I finished my coffee, else it might be mesy here. PRIVATE INTERCONNECTS. Real world example follows, which is why my primary employer has a PI assignment; we interconnect using IPsec VPNs and some leased lines with a number of other enterprises. We use RFC1918 *internally* and so do many others. What addressing scheme would you suggest we use to talk, especially as we DO NOT want this traffic to accidentally leak onto the public internet ? While I do not believe IPv6 will ever happen, *my* opinion I don't want to discuss it, if I get it wrong and it does, how will you achieve that same thing ? Peter
On 03-03-2003 22:20PM, "Gert Doering" <gert@space.net> wrote:
Come on. Calm down. Think! Ripe is surely educated enough to differentiate between a Enterprise, ISP or IXP.
Can you *define* what is an IXP? In a way that an enterprise aiming for PI space can't cheat and match that definition?
I cannot.
Pretty common definition (also in RIPE-256): "An Internet Exchange Point is defined as a physical network infrastructure (layer 2) operated by a single entity whose purpose is to facilitate the exchange of Internet traffic between ISPs. There must be a minimum of three ISPs connected and there must be a clear and open policy for others to join" Cheating seems quite a burden too me... Anyway RIPE-256 just works well. Every IXP in the RIPE region can easily get a /48 for the peering mesh. In fact it seems easier than requesting IPv4 PI space (which is good :) ) The issues remains the IPv6 space for services. Yes, I know that this has been "discussed" before. However it seems that the discussion has not ended. Arien
On Mon, 2003-03-03 at 23:28, Arien Vijn wrote:
On 03-03-2003 22:20PM, "Gert Doering" <gert@space.net> wrote:
Come on. Calm down. Think! Ripe is surely educated enough to differentiate between a Enterprise, ISP or IXP.
Can you *define* what is an IXP? In a way that an enterprise aiming for PI space can't cheat and match that definition? [snip] Anyway RIPE-256 just works well. Every IXP in the RIPE region can easily get a /48 for the peering mesh. In fact it seems easier than requesting IPv4 PI space (which is good :) )
The very fact that they do only get up to a /48 makes it pretty worthless for anyone to try to "cheat", since a /48 will most likely be blocked by the filters of most networks, being a too long mask - those who DO proper filtering, at least. I know I won't be punching holes in any filters to allow IXP /48's through... And that is not a problem, as long as those networks are only used for their intended purpose, namely the peering meshes.
The issues remains the IPv6 space for services. Yes, I know that this has been "discussed" before. However it seems that the discussion has not ended.
I would imagine an IXP should have plenty of operators close at hand to choose from when it comes to buying upstream connectivity and getting PA space to run said services in... :) The issues of how they allocate whatever membership fees they charge their members to pay for said upstream are between the IXP and it's members, they are a commercial entity after all (well, mostly). I'm sure quite a few of them will be able to make suitable arrangments with their connected members too. If they want multihoming - well, then they are in the same boat as a lot of other enterprises out there, that problem as we all know hasn't been solved yet. But I don't see what makes an IXP any different from any other commercial operation seeking to get multihomed, that gives them any right to "special treatment" in that regard. /leg
On 04-03-2003 0:00AM, "Lars Erik Gullerud" <lerik@nolink.net> wrote: [...]
The issues remains the IPv6 space for services. Yes, I know that this has been "discussed" before. However it seems that the discussion has not ended.
I would imagine an IXP should have plenty of operators close at hand to choose from when it comes to buying upstream connectivity and getting PA space to run said services in... :)
Depends very much. The larger exchanges might have plenty of choice. Smaller ones do not have any choice at all. When there is is choice. An IXP will faces a difficult dilemma. Which member will get the contract? Here is where the much misunderstood neutrality comes in place. This demanded neutrally differs IXPs from normal enterprises. Neutrally for an enterprise means that it can make it's decisions based on its *own* interests (within certain limits). An neutral IXP is typically owned by it's members. On top of the the normal criteria an IXP has to keep the interest of *all* its members in mind. Since most members are also each others competitors this is not always a simple thing to do. Especially when it comes to purchasing services offered by the very same competing members.
The issues of how they allocate whatever membership fees they charge their members to pay for said upstream are between the IXP and it's members, they are a commercial entity after all (well, mostly). I'm sure quite a few of them will be able to make suitable arrangments with their connected members too.
On the contrary. The most successful ISPs are not for profit. To be successful as IXP, one needs to keep a certain distance from all members and treat them all equally. By buying upstream from one member the interest of other, competing members might be harmed implicitly. Do not underestimate the impact that might have.
If they want multihoming - well, then they are in the same boat as a lot of other enterprises out there, that problem as we all know hasn't been solved yet. But I don't see what makes an IXP any different from any other commercial operation seeking to get multihomed, that gives them any right to "special treatment" in that regard.
With multihoming the IXP could get upstream from a number members and keep its neutrality that way. IMHO that is the way to go. Easy renumbering might help a bit too. However both multihoming and easy renumbering are still far away. Therefore I do understand those who do not want to wait for that and prefer an exception for critical infrastructure. Arien
On Tue, 2003-03-04 at 14:34, Arien Vijn wrote:
With multihoming the IXP could get upstream from a number members and keep its neutrality that way. IMHO that is the way to go. Easy renumbering might help a bit too.
However both multihoming and easy renumbering are still far away. Therefore I do understand those who do not want to wait for that and prefer an exception for critical infrastructure.
Keep in mind we are talking about services here, not the peering mesh - address space for the peering mesh is already available. And the question then becomes, what services do the IXP operators need to run that would qualify as "critical infrastructure", and therefore qualify for any exception to current policies? Let me put it this way, what services do the IXP operators run outside the mesh that absolutely requires IPv6 space and is considered "critical", from the perspective of requiring globally routable space? I would imagine that by the time the needs can no longer be solved through IPv4, a solution to the whole multihoming/PI problem has already been solved, otherwise I don't think that time WILL come. /leg
Hi, On Tue, Mar 04, 2003 at 03:11:38PM +0100, Lars Erik Gullerud wrote:
Let me put it this way, what services do the IXP operators run outside the mesh that absolutely requires IPv6 space and is considered "critical", from the perspective of requiring globally routable space? I would imagine that by the time the needs can no longer be solved through IPv4, a solution to the whole multihoming/PI problem has already been solved, otherwise I don't think that time WILL come.
I consider this approach ("the IPv6 rules have a problem here, so let's do this with IPv4") flawed. The issue is twofold: - address space for the peering mesh, which is unique, not tied to any of the members, and easy to get: available & solved. - address space for additional services (secondary name servers, web servers for members / global information, mail servers, etc.) - all things that obviously *need* global connectivity. As a solution for the second problem, I think that "using upstream space" *is* a workable solution, at least to start with. Right now I consider it more important to actually get IPv6 services up and running than to endlessly discuss why it's not possible to do IPv6. When doing this, one needs to be prepared to renumber - which is pretty easy, when done right (generate DNS zones, firewall rules, and whatever you need from templates that contain $CURRENTPREFIX, possibly multiple of them). In the long run, one of the multihoming solutions might "really" solve the problem, or we might end up needing "real IPv6 PI space" for the exchange points. (And big enterprises. And universities. And so on.) But this "future plans" shouldn't stop people from deploying IPv6 for infrastructure things *today*. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
In message <20030304152015.B15927@Space.Net>, Gert Doering writes:
In the long run, one of the multihoming solutions might "really" solve the problem, or we might end up needing "real IPv6 PI space" for the exchange points. (And big enterprises. And universities. And so on.)
But this "future plans" shouldn't stop people from deploying IPv6 for infrastructure things *today*.
These two sentences remind me of a sketch I saw many years ago on british television: The inventor for the rocket-car was interviewed. He argued fewerishly that all cars should be exchanged for rocket-cars right now because it was much faster, cheaper, safer etc etc. Only when questioned directly did he reluctantly admit that some minor issues were not entirely solved yet, but it would of course only be a matter of a short time and a little emperical data before that would be sorted out. Further questioning reveals that the "minor issues" are "how to avoid collisions in intersections", "how to follow curves in the road" and "how to stop if there is no brick wall". It wasn't the pythons, but the style was similar. IPv6 needs to fix the protocol errors in the political layer, soon. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Hi, On Tue, Mar 04, 2003 at 03:35:56PM +0100, Poul-Henning Kamp wrote:
IPv6 needs to fix the protocol errors in the political layer, soon.
While I understand your argument, I do not consider the non-availability of IPv6 PI space an *error*. (Speaking for myself). It means re-thinking some established ways to do things - things that have caused large problems in the past, and might not have been an overly good idea to start with. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
In message <20030304160219.E15927@Space.Net>, Gert Doering writes:
Hi,
On Tue, Mar 04, 2003 at 03:35:56PM +0100, Poul-Henning Kamp wrote:
IPv6 needs to fix the protocol errors in the political layer, soon.
While I understand your argument, I do not consider the non-availability of IPv6 PI space an *error*. (Speaking for myself).
It means re-thinking some established ways to do things - things that have caused large problems in the past, and might not have been an overly good idea to start with.
Well, but those "established ways of doing things" may also happen to be exactly why we could deploy IPv4 in the first place, and their absense have provably hampered IPv6 deployment. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Hi, On Tue, Mar 04, 2003 at 04:07:58PM +0100, Poul-Henning Kamp wrote:
It means re-thinking some established ways to do things - things that have caused large problems in the past, and might not have been an overly good idea to start with.
Well, but those "established ways of doing things" may also happen to be exactly why we could deploy IPv4 in the first place, and their absense have provably hampered IPv6 deployment.
Yes, of course we can stay on IPv4 with NAT and double-NAT and dynamic IPs for customers and whatever kludges are necessary... Changing over to IPv6 *is* painful. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
In message <20030304161229.G15927@Space.Net>, Gert Doering writes:
Hi,
On Tue, Mar 04, 2003 at 04:07:58PM +0100, Poul-Henning Kamp wrote:
It means re-thinking some established ways to do things - things that have caused large problems in the past, and might not have been an overly good idea to start with.
Well, but those "established ways of doing things" may also happen to be exactly why we could deploy IPv4 in the first place, and their absense have provably hampered IPv6 deployment.
Yes, of course we can stay on IPv4 with NAT and double-NAT and dynamic IPs for customers and whatever kludges are necessary...
Changing over to IPv6 *is* painful.
I'm mainly talking about the lack of a feasible way for end-customers to get working multi-homing. This ties directly into the "PI" space question. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
I'm mainly talking about the lack of a feasible way for end-customers to get working multi-homing. This ties directly into the "PI" space question.
it ties directly to a fantasy that addressing and routing are not intimately and inextricably intertwined, and changing one requires serious thought about the other. randy
--On Tuesday, March 04, 2003 16:14:57 +0100 Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
I'm mainly talking about the lack of a feasible way for end-customers to get working multi-homing. This ties directly into the "PI" space question.
Multihoming today depends on the possession of an AS number. I see no alternative to that prerequisite. Size of current v4 routing table: roughly 120000 entries Number of ASen visible : roughly 15000 So, if we simply give every AS number holder currently present in the v4 table a /32 or so, with STRICT instructions to forget getting another prefix until half that prefix is pingable, we attain several things: * This makes the PI/PA distinction moot, or rather, we have PI only. Perhaps the mootness is temporary, but I hope not. It might be replaced with AA -- AS Allocated, ie "these addresses belong to AS1653, and cannot be placed under any other AS". * The "v6 for services" problem will disappear. End of this discussion. * The routing table will shrink to 12.5% of its present size. * We will have a minor chunk of v6 space used, and all present users of v4 will be able to migrate without lack of address space. * If the number of ASen (with one /32 per AS) visible in the v6 table increase 100% compared to todays v4 figures, the table will still be only 25% of today. * Everybody will hunt me with both sharp and blunt objects for being a filthy pragmatic person with blasphemous opinions. Now, please tell me why this does not work. Purity reasons will have no effect, for I am too shortsighted. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead.
Hi, On Wed, Mar 05, 2003 at 01:29:22PM +0100, Måns Nilsson wrote:
So, if we simply give every AS number holder currently present in the v4 table a /32 or so, with STRICT instructions to forget getting another prefix until half that prefix is pingable, we attain several things:
* This makes the PI/PA distinction moot, or rather, we have PI only. Perhaps the mootness is temporary, but I hope not. It might be replaced with AA -- AS Allocated, ie "these addresses belong to AS1653, and cannot be placed under any other AS".
Unfortunately it's not that easy. It will just change the discussion from "I need IPv6 PI address space for my enterprise XYZ" to "I need an AS number for my enterprise!". I agree that "give every existing AS holder a /32" seems like a very elegant solution - but what about *new* ASes? I think it might create a "land rush" situation in the AS area ("get one while they are still easy to get"), which would be very bad. 32 bit AS numbers are possible, yes, but will not solve the core problem. [..]
* Everybody will hunt me with both sharp and blunt objects for being a filthy pragmatic person with blasphemous opinions.
It's not that this solution hasn't been proposed before. I'm just convinced that it won't work as a reliable way to scale into the future. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
--On Wednesday, March 05, 2003 14:16:09 +0100 Gert Doering <gert@Space.Net> wrote:
Unfortunately it's not that easy. It will just change the discussion from "I need IPv6 PI address space for my enterprise XYZ" to "I need an AS number for my enterprise!".
But don't they already have that? My proposal is exactly the same as the current need wrt multihoming in v4; you must have an AS number to multihome to several upstreams -- multihoming inside one provider still can be done over OSPF or similar; no need to get a separate allocation for that.
I agree that "give every existing AS holder a /32" seems like a very elegant solution - but what about *new* ASes? I think it might create a "land rush" situation in the AS area ("get one while they are still easy to get"), which would be very bad.
Yes, this is a calculated risk. But, the LIRen should of course keep their strict policies for ASN allocation -- must be visible over several paths within three months or so, and should stay so, with reevaluation applied. The cost and cumbersomeness associated with keeping an AS present in several paths, combined with a strictly enforced revocation process, should keep that landslide to thaw levels instead of avalanching.
32 bit AS numbers are possible, yes, but will not solve the core problem.
Not until Moore makes a 2^32 entries large routing table usable. My guess is that these issues are interdependent -- We will get routers that can handle these entries when there is an imminent risk that they will be necessary.
It's not that this solution hasn't been proposed before. I'm just convinced that it won't work as a reliable way to scale into the future.
I realise this. It is a calculated risk, based on studies of usage patterns during the last 10 years of v4 routing. I think that will sort itself out, if people are exposed to problems as opposed to just discussing horror scenarios. My point is, simply put, that: * Unless we get some blowtorch applied to the collective Internet posterior wrt v6, the people who state that v6 won't work will be right. I would hate that. * The hierarchical routing model used and promoted for v6 so far, seems, from the view of this naive bystander, to be designed by someone seriously opposed to practical v6 deployment, much as the Bundeswehr uniform is claimed to be designed by a pacifist, with the intent of making war unfeasible... * If it due to aggressive optimisation design choices is hard or impossible to get v6 working in an informal but live manner, nobody but a select few at the big operators will be able to play with it outside the tunnel playpen. * Thus, there is some value in sacrificing parts of the purity in the interest of gaining momentum and users, meaning more effort will be put into solving the problem. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead.
Måns Nilsson wrote:
* If it due to aggressive optimisation design choices is hard or impossible to get v6 working in an informal but live manner, nobody but a select few at the big operators will be able to play with it outside the tunnel playpen.
Tunnels are just one of the _transitions methods_ for the endusers, that they where also used to bind together the 6bone is something else. The bigger and IPv6 aware ISP's are quickly moving out of that, read: http://ip6.de.easynet.net/ipv6-minimum-peering.txt I also am wondering how people define "multihoming". Do they define it as: - Multiple prefixes over multiple cables from multiple upstreams. - One prefix over multiple cables from multiple upstreams. - One prefix over one cable from multiple upstreams. If you are talking about the last case, where one only has one physical upstream... one shouldn't call that multihoming. I guess the second one is where people are talking about. And the first one is what I would call real multihoming, though one needs SCTP to make that work. Greets, Jeroen
--On Wednesday, March 05, 2003 17:53:00 +0100 Jeroen Massar <jeroen@unfix.org> wrote:
Tunnels are just one of the _transitions methods_ for the endusers, that they where also used to bind together the 6bone is something else. The bigger and IPv6 aware ISP's are quickly moving out of that, read: http://ip6.de.easynet.net/ipv6-minimum-peering.txt
Of course. This is a discussion "post-tunnel". My comment was in the spirit of "going forth from the lab activity under 3FFE". Today 6bone is legacy.
I also am wondering how people define "multihoming". Do they define it as: - Multiple prefixes over multiple cables from multiple upstreams. - One prefix over multiple cables from multiple upstreams. - One prefix over one cable from multiple upstreams.
If you are talking about the last case, where one only has one physical upstream... one shouldn't call that multihoming. I guess the second one is where people are talking about. And the first one is what I would call real multihoming, though one needs SCTP to make that work.
Cases one and two. One or more prefixes advertised over multiple upstreams. Although my idea is to give people so much space in their initial allocation that only the biggest networks will need more than one prefix, thus keeping the routing table as close to "nPrefixes == nAS-numbers" as possible. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead.
Måns Nilsson wrote:
--On Wednesday, March 05, 2003 17:53:00 +0100 Jeroen Massar <jeroen@unfix.org> wrote:
<SNIP>
I also am wondering how people define "multihoming". Do they define it as: - Multiple prefixes over multiple cables from multiple upstreams. - One prefix over multiple cables from multiple upstreams. - One prefix over one cable from multiple upstreams.
If you are talking about the last case, where one only has one physical upstream... one shouldn't call that multihoming. I guess the second one is where people are talking about. And the first one is what I would call real multihoming, though one needs SCTP to make that work.
Cases one and two. One or more prefixes advertised over multiple upstreams.
Case one means having more than one prefixes on the cable, or in diagram style: +-----+ +-----------+ 2001:db8:11:22::/64 +------+ | the +---+ Cable ISP +------------------------+ eth0 | | N | +-----------+ | | | E | | YOU | | T | +-----------+ 3ffe:ffff:33:42::/64 | | | +---+ ADSL ISP +------------------------+ eth1 | +-----+ +-----------+ +------+ Thus YOU gets 2 different prefixes from 2 different upstreams. Ofcourse YOU could also get two /48's routed to him from these upstreams or more ofcourse. The fact is that a 'server' eg a web server will have 2 IP's; eg: www.example.com AAAA 2001:0db8:11:22::80 AAAA 3ffe:ffff:33:42::80 Ofcourse replace Cable and ADSL with the bigger lines, this is just to illustrate that the definition of 'multihoming' is quite a different thing for most people. As I said this will only work when using SCTP to 'multihome' when one of the two uplinks fail. In case two both upstreams carry "your" prefix, eg 2001:db8:11:22::/64 to the rest of the world, diagram style: +-----+ +-----------+ 2001:db8:11:22::/64 +------+ +------+ | the +---+ Cable ISP +------------------------+ R | | | | N | +-----------+ | o | | | | E | | u +----+ eth0 | | T | +-----------+ 2001:db8:11:22::/64 | t | | | | +---+ ADSL ISP +------------------------+ er | | | +-----+ +-----------+ +------+ +------+ Note that the moment you only have one physical path to the rest of the world you should not be talking about 'multihoming' any more (case 3) I always wonder why people want L3 level 'multihoming' even though their L1 and L2 path aren't.
Although my idea is to give people so much space in their initial allocation that only the biggest networks will need more than one prefix, thus keeping the routing table as close to "nPrefixes == nAS-numbers" as possible.
Every ISP that can match up to the current requirements for address space can get a /32 from all three RIRs. If you can't, you simply are not big enough and you won't have any multiple links either. If one really wants 99.9% certainty that their inet works one either needs to do it themselves and thus get multiple L1+L2 paths and the hardware along with it and then most of the times you are a big enough customer to get a /32 too. If you aren't you should just get a better upstream. Yes, I know, it all sounds quite harsh. Greets, Jeroen
--On Wednesday, March 05, 2003 22:27:51 +0100 Jeroen Massar <jeroen@unfix.org> wrote:
Case one means having more than one prefixes on the cable, or in diagram style:
+-----+ +-----------+ 2001:db8:11:22::/64 +------+ | the +---+ Cable ISP +------------------------+ eth0 | | N | +-----------+ | | | E | | YOU | | T | +-----------+ 3ffe:ffff:33:42::/64 | | | +---+ ADSL ISP +------------------------+ eth1 | +-----+ +-----------+ +------+
Thus YOU gets 2 different prefixes from 2 different upstreams. Ofcourse YOU could also get two /48's routed to him from these upstreams or more ofcourse. The fact is that a 'server' eg a web server will have 2 IP's; eg: www.example.com AAAA 2001:0db8:11:22::80 AAAA 3ffe:ffff:33:42::80
This is not what we are talking about.
Ofcourse replace Cable and ADSL with the bigger lines, this is just to illustrate that the definition of 'multihoming' is quite a different thing for most people. As I said this will only work when using SCTP to 'multihome' when one of the two uplinks fail.
In case two both upstreams carry "your" prefix, eg 2001:db8:11:22::/64 to the rest of the world, diagram style:
+-----+ +-----------+ 2001:db8:11:22::/64 +------+ +------+ | the +---+ Cable ISP +------------------------+ R | | | | N | +-----------+ | o | | | | E | | u +----+ eth0 | | T | +-----------+ 2001:db8:11:22::/64 | t | | | | +---+ ADSL ISP +------------------------+ er | | | +-----+ +-----------+ +------+ +------+
This is more to the point.
Note that the moment you only have one physical path to the rest of the world you should not be talking about 'multihoming' any more (case 3)
I always wonder why people want L3 level 'multihoming' even though their L1 and L2 path aren't.
Because even if backhoes are quite common creatures, the network engineer with fat fingers is even more common. Having said that, I agree that several redundant links are a practical prerequisite.
Although my idea is to give people so much space in their initial allocation that only the biggest networks will need more than one prefix, thus keeping the routing table as close to "nPrefixes == nAS-numbers" as possible.
Every ISP that can match up to the current requirements for address space can get a /32 from all three RIRs. If you can't, you simply are not big enough and you won't have any multiple links either.
Which is my point, sort of. But I still want the requirements slacked to fuel deployment.
If one really wants 99.9% certainty that their inet works one either needs to do it themselves and thus get multiple L1+L2 paths and the hardware along with it and then most of the times you are a big enough customer to get a /32 too. If you aren't you should just get a better upstream. Yes, I know, it all sounds quite harsh.
No disagreement there. But I do not think we talk about the same thing, or at least not in the same scale. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead.
If one really wants 99.9% certainty that their inet works one either needs to do it themselves and thus get multiple L1+L2 paths and the hardware along with it and then most of the times you are a big enough customer to get a /32 too. If you aren't you should just get a better upstream. Yes, I know, it all sounds quite harsh.
No disagreement there. But I do not think we talk about the same thing, or at least not in the same scale.
Most of the down time will most likely be waiting for BGP to converge. I think we need a new model, and a way to get there. A flag day is to optimistic. - kurtis -
32 bit AS numbers are possible, yes, but will not solve the core problem.
Not until Moore makes a 2^32 entries large routing table usable. My guess is that these issues are interdependent -- We will get routers that can handle these entries when there is an imminent risk that they will be necessary.
There are two sides to this. A) We need to buy time to get adoption of IPv6. Go for swamp or anything that is easy to implement. B) We need to fix IPv6. I am voting for 8+8 or 16+16. That will take time. We will need a way to migrate there that is relatively pain-free and that can cope with the swamp above. This will also make away with the Moore limitation (if such a thing exists). Who want's to write the drafts? - kurtis -
On Wed, 5 Mar 2003, Måns Nilsson wrote:
--On Tuesday, March 04, 2003 16:14:57 +0100 Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
I'm mainly talking about the lack of a feasible way for end-customers to get working multi-homing. This ties directly into the "PI" space question.
Multihoming today depends on the possession of an AS number. I see no alternative to that prerequisite.
No, (global) AS number is definitely not required, and if you really want, you could do without even a private ASn. A rather common scenario is to use private ASN to two providers, and leak more specifics from beyond your preferred ISP to the world -- and connect to the ISP as a secondary which owns the aggregate. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--On Wednesday, March 05, 2003 16:46:50 +0200 Pekka Savola <pekkas@netcore.fi> wrote:
No, (global) AS number is definitely not required, and if you really want, you could do without even a private ASn.
A rather common scenario is to use private ASN to two providers, and leak more specifics from beyond your preferred ISP to the world -- and connect to the ISP as a secondary which owns the aggregate.
Might be so, but even I am opposed to such ugliness. I have yet to see it, probably because most people doing so are ashamed of the practice... Furthermore, it might be possible to deprecate the behaviour of multihoming without public AS in v6, simply because few people will accept routes for smaller prefixes than /32.. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead.
Check out: http://www.ietf.org/internet-drafts/draft-savola-multi6-asn-pi-00.txt the drawback seems obvious: at least I don't want to encourage anything that would hasten the move to 32-bit AS numbers, and definitely don't want to change the problem of end-site multihoming to AS-number exhaustion problem. On Wed, 5 Mar 2003, Måns Nilsson wrote:
--On Tuesday, March 04, 2003 16:14:57 +0100 Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
I'm mainly talking about the lack of a feasible way for end-customers to get working multi-homing. This ties directly into the "PI" space question.
Multihoming today depends on the possession of an AS number. I see no alternative to that prerequisite.
Size of current v4 routing table: roughly 120000 entries Number of ASen visible : roughly 15000
So, if we simply give every AS number holder currently present in the v4 table a /32 or so, with STRICT instructions to forget getting another prefix until half that prefix is pingable, we attain several things:
* This makes the PI/PA distinction moot, or rather, we have PI only. Perhaps the mootness is temporary, but I hope not. It might be replaced with AA -- AS Allocated, ie "these addresses belong to AS1653, and cannot be placed under any other AS".
* The "v6 for services" problem will disappear. End of this discussion.
* The routing table will shrink to 12.5% of its present size.
* We will have a minor chunk of v6 space used, and all present users of v4 will be able to migrate without lack of address space.
* If the number of ASen (with one /32 per AS) visible in the v6 table increase 100% compared to todays v4 figures, the table will still be only 25% of today.
* Everybody will hunt me with both sharp and blunt objects for being a filthy pragmatic person with blasphemous opinions.
Now, please tell me why this does not work. Purity reasons will have no effect, for I am too shortsighted.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
In message <Pine.LNX.4.44.0303051648430.6753-100000@netcore.fi>, Pekka Savola w rites:
Check out:
http://www.ietf.org/internet-drafts/draft-savola-multi6-asn-pi-00.txt
You're never going to carry that motion, it would make it likely that people would start to use IPv6 in practice. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
I'm mainly talking about the lack of a feasible way for end-customers to get working multi-homing. This ties directly into the "PI" space question.
Multihoming today depends on the possession of an AS number. I see no alternative to that prerequisite.
Size of current v4 routing table: roughly 120000 entries Number of ASen visible : roughly 15000
So, if we simply give every AS number holder currently present in the v4 table a /32 or so, with STRICT instructions to forget getting another prefix until half that prefix is pingable, we attain several things:
This is what Pekka Savola proposed in his draft. People will start screaming about 32-bit ASes. It's also similiar to my draft on creating IPv6 swap space. There are less than 15000 LIRs. Each LIRs /32 is more address space than most of them have today. Add the routes from all remaining AS:es. I don't see the problem. I am still waiting for the IPv6 routing table to reach 1000 routes. Call me then. - kurtis -
Gert Doering (gert@space.net) wrote:
Changing over to IPv6 *is* painful.
... but should be considered rather soon ! just my .2 cents --jan -- Jan Ahrent Czmok - Senior Network Engineer - Access Networks Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok@gatel.de
Kurt Erik Lindqvist (kurtis@kurtis.pp.se) wrote:
Changing over to IPv6 *is* painful.
... but should be considered rather soon !
just my .2 cents
First we need to get it to work.
Hi kurtis, what is _not_ working according your opinion ? (and we're not talking about hardware vendor support - i know it lacks in some cases) Side question: do a PPPoE exist for IPv6 ? --jan -- Jan Ahrent Czmok - Senior Network Engineer - Access Networks Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok@gatel.de
Changing over to IPv6 *is* painful.
... but should be considered rather soon !
just my .2 cents
First we need to get it to work.
Hi kurtis,
what is _not_ working according your opinion ?
Tools is the first that comes to mind. If you want the larger carriers to use it they need to adopt their provisioning systems, but that is not a fault of IPv6. I think we need to urgently solve multihoming, some PI like mechanism, and I think we should take out site-locals, or at least minimize their use until it's to late and we are stuck with the RFC1918 problem and applications that won't work.
(and we're not talking about hardware vendor support - i know it lacks in some cases)
That is a problem that will be solved when there is enough demand. - kurtis -
Kurt Erik Lindqvist (kurtis@kurtis.pp.se) wrote:
Changing over to IPv6 *is* painful.
... but should be considered rather soon !
just my .2 cents
First we need to get it to work.
Hi kurtis,
what is _not_ working according your opinion ?
Tools is the first that comes to mind. If you want the larger carriers to use it they need to adopt their provisioning systems, but that is not a fault of IPv6. I think we need to urgently solve multihoming, some PI like mechanism, and I think we should take out site-locals, or at least minimize their use until it's to late and we are stuck with the RFC1918 problem and applications that won't work.
Okay, so let's address this one by one: - what ideas do we have regarding multihoming, what is/should be deprecated and what preferred ?
That is a problem that will be solved when there is enough demand.
the usual chicken/egg problem :-) --jan -- Jan Ahrent Czmok - Senior Network Engineer - Access Networks Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok@gatel.de
- what ideas do we have regarding multihoming, what is/should be deprecated and what preferred ?
Uh, uhm. There are quite a lot of ideas. Actually there is no problem with shortage of ideas. There is shortage on agreement to move forward though. Personally I (and many others) believe in a GSE like solution, 8+8 or 16+16 but that needs a lot more work so there is some meat on the bones. See the multi6 WG discussions in the IETF or the ipv6mh mailinglist. - kurtis -
Kurt;
- what ideas do we have regarding multihoming, what is/should be deprecated and what preferred ?
Uh, uhm. There are quite a lot of ideas. Actually there is no problem with shortage of ideas. There is shortage on agreement to move forward though. Personally I (and many others) believe in a GSE like solution, 8+8 or 16+16 but that needs a lot more work so there is some meat on the bones. See the multi6 WG discussions in the IETF or the ipv6mh mailinglist.
Multihoming is simple to just let hosts have multiple addresses, which is already done with IPv6, and let the hosts choose the destination address. The hard part is that there are a lot of works wrongly done with IPv6. It is wrong, for example, to have source address selection, router/host separation and complicated but poor mobility, all of which must be removed. The removal is technically easy but was politically difficult, as some people were insisting that IPv6 would be deployed immediately if the current specificaiton had been kept as is. Three years ago, they were insisting so for five years. Though I haven't checked activities of IPv6 WG for these three years, I hope they have finally give up now. There already is running code of of 8+8, transport over it, such as TCP, and applications over it, such as TCP multihomed telephony with no address reselection latency, that there is not much work remaning. Just choose it or something, if any, else. Masataka Ohta PS Never mention poor GSE. It is a poor idea useless for any purpose.
Multihoming is simple to just let hosts have multiple addresses, which is already done with IPv6, and let the hosts choose the destination address.
how to choose? randy
Randy Bush wrote:
Multihoming is simple to just let hosts have multiple addresses, which is already done with IPv6, and let the hosts choose the destination address.
how to choose?
BGPDNS for example. Host is asking BGPDNS which destination IP to take. BGPDNS server sorts a DNS reply with multiple A (AAAA) records according to BGP selected preference. Have a look at www.nrg4u.com right column. Not that I'm a fan of the current IPv6... It's too broken wrt the issues the previuous posters have told. -- Andre
Multihoming is simple to just let hosts have multiple addresses, which is already done with IPv6, and let the hosts choose the destination address.
how to choose?
Just randomly, or, as is written in draft-ohta-e2e-multihoming-02.txt, Once a full routing table is available on all the end systems, it is easy for the end systems try all the destination addresses, from the most and to the least favorable ones, based on the routing metric. Note that end to end multihoming works with the separation between inter domain BGP and intra domain routing protocols, if BGP routers, based on domain policy, assign external routes preference values (metric) of intra domain routing protocols. One may still be allowed, though discouraged, to have local configuration with dumb end systems and an intelligent proxy. But, such configuration should be implemented with a protocol for purely local use without damaging the global protocol. use routing table for reachability and metric. BGPDNS could be the intelligent proxy. Masataka Ohta
In message <200303092049.FAA02234@necom830.hpcl.titech.ac.jp>, Masataka Ohta wr ites:
Once a full routing table is available on all the end systems,
You're not serious, right ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
In message <200303092108.GAA02345@necom830.hpcl.titech.ac.jp>, Masataka Ohta wr ites:
Poul-Henning Kamp;
Once a full routing table is available on all the end systems,
You're not serious, right ?
All of us working on multihoming are serious to make the full routing table manageably small.
No wonder IPv6 isn't moving anywhere then. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Multihoming is simple to just let hosts have multiple addresses, which is already done with IPv6, and let the hosts choose the destination address.
As I said, there is no shortage of ideas. There are a number of people who will tell you that this won't scale and break a number of applications.
There already is running code of of 8+8, transport over it, such as TCP, and applications over it, such as TCP multihomed telephony with no address reselection latency, that there is not much work remaning.
Never mention poor GSE. It is a poor idea useless for any purpose.
Uh, what is the difference between 8+8 and GSE? - kurtis -
Kurt;
Multihoming is simple to just let hosts have multiple addresses, which is already done with IPv6, and let the hosts choose the destination address.
As I said, there is no shortage of ideas.
I'm saying implementations.
There are a number of people who will tell you that this won't scale and break a number of applications.
Since I proposed it in April 2000, no one told me that this won't scale. As for applications, with darty hack, it is even possible to make TCP-based applications work as is, but considering the number of users of IPv6, why do you bother?
There already is running code of of 8+8, transport over it, such as TCP, and applications over it, such as TCP multihomed telephony with no address reselection latency, that there is not much work remaning.
Never mention poor GSE. It is a poor idea useless for any purpose.
Uh, what is the difference between 8+8 and GSE?
Current IPv6, in a sense, is 8+8 and was 10+6. GSE is a poor variation of 8+8. GSE is poor because it is an attempt to make ISP operation more complex (that is, less scalable), which has been the tradition of telephone companies to maximize their revenue. Masataka Ohta
here are a number of people who will tell you that this won't scale and break a number of applications.
Since I proposed it in April 2000, no one told me that this won't scale.
That surprises me. Then again I wasn't aware of you draft until you mailed it here. What WG do see this under? I will comment to multi6 anyway...
There already is running code of of 8+8, transport over it, such as TCP, and applications over it, such as TCP multihomed telephony with no address reselection latency, that there is not much work remaning.
Never mention poor GSE. It is a poor idea useless for any purpose.
Uh, what is the difference between 8+8 and GSE?
Current IPv6, in a sense, is 8+8 and was 10+6.
???? you mean the IID being 8 and the rest the other 8? I don't agree...
GSE is a poor variation of 8+8. GSE is poor because it is an attempt to make ISP operation more complex (that is, less scalable), which has been the tradition of telephone companies to maximize their revenue.
I fail to see what GSE, 8+8 or anything have to do with telephone companies. - kurtis -
Kurt;
here are a number of people who will tell you that this won't scale and break a number of applications.
Since I proposed it in April 2000, no one told me that this won't scale.
That surprises me. Then again I wasn't aware of you draft until you mailed it here. What WG do see this under? I will comment to multi6 anyway...
The draft is: draft-ohta-e2e-multihoming-*.txt It was mailed to multi6 several times.
There already is running code of of 8+8, transport over it, such as TCP, and applications over it, such as TCP multihomed telephony with no address reselection latency, that there is not much work remaning.
Never mention poor GSE. It is a poor idea useless for any purpose.
Uh, what is the difference between 8+8 and GSE?
Current IPv6, in a sense, is 8+8 and was 10+6.
???? you mean the IID being 8 and the rest the other 8? I don't agree...
You don't have to.
GSE is a poor variation of 8+8. GSE is poor because it is an attempt to make ISP operation more complex (that is, less scalable), which has been the tradition of telephone companies to maximize their revenue.
I fail to see what GSE, 8+8 or anything have to do with telephone companies.
You don't have to, either. Just never mention GSE. Masataka Ohta
On 04-03-2003 15:11PM, "Lars Erik Gullerud" <lerik@nolink.net> wrote:
On Tue, 2003-03-04 at 14:34, Arien Vijn wrote:
With multihoming the IXP could get upstream from a number members and keep its neutrality that way. IMHO that is the way to go. Easy renumbering might help a bit too.
However both multihoming and easy renumbering are still far away. Therefore I do understand those who do not want to wait for that and prefer an exception for critical infrastructure.
Keep in mind we are talking about services here, not the peering mesh - address space for the peering mesh is already available. And the question then becomes, what services do the IXP operators need to run that would qualify as "critical infrastructure", and therefore qualify for any exception to current policies?
Whether or not the supporting services are part of he critical infrastructure is debatable indeed.
Let me put it this way, what services do the IXP operators run outside the mesh that absolutely requires IPv6 space and is considered "critical", from the perspective of requiring globally routable space? I would imagine that by the time the needs can no longer be solved through IPv4, a solution to the whole multihoming/PI problem has already been solved, otherwise I don't think that time WILL come.
I do agree with this analysis. Arien -- Arien Vijn tel: +31 205 141 718 Amsterdam Internet Exchange mobile: +31 651 836 444 http://www.ams-ix.net e-mail: arien.vijn@ams-ix.net
Let me put it this way, what services do the IXP operators run outside the mesh that absolutely requires IPv6 space and is considered "critical", from the perspective of requiring globally routable space? I
TLD DNS hosting comes to mind. - kurtis -
Hi, On Wed, Mar 05, 2003 at 08:23:35AM +0100, Kurt Erik Lindqvist wrote:
Let me put it this way, what services do the IXP operators run outside the mesh that absolutely requires IPv6 space and is considered "critical", from the perspective of requiring globally routable space? I
TLD DNS hosting comes to mind.
Why? I know that this has surfaced on the last RIPE meeting already, but I still think that a TLD name server is in no way special - it's IP address can be resolved by querying the root, so it doesn't need to have a fixed IP address "forever". If the address changes (which of course should not happen every couple of weeks) change the glue record in the root, and that's it. For the root name servers themselves, we have a "root name server IPv6 allocation policy" which permits static IPv6 allocations. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi, On Wed, Mar 05, 2003 at 09:25:16AM +0100, Gert Doering wrote:
Let me put it this way, what services do the IXP operators run outside the mesh that absolutely requires IPv6 space and is considered "critical", from the perspective of requiring globally routable space? I
TLD DNS hosting comes to mind.
Why?
Ummm, sorry. Not enough coffee yet. Actually I fully agree with you :-) - TLD DNS hosting is a very useful service to have at an IXP, and since you didn't state anything about having "critical infrastructure static IPv6 allocations" for them, there is nothing for me to disagree with. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Let me put it this way, what services do the IXP operators run outside the mesh that absolutely requires IPv6 space and is considered "critical", from the perspective of requiring globally routable space? I
TLD DNS hosting comes to mind.
Why?
I know that this has surfaced on the last RIPE meeting already, but I still think that a TLD name server is in no way special - it's IP address can be resolved by querying the root, so it doesn't need to have a fixed IP address "forever". If the address changes (which of course should not happen every couple of weeks) change the glue record in the root, and that's it.
Although I agree with you, reality is not always that simple. An advantage with locating a TLD DNS server at a IX point is that you have a easy way to get access to a large amount of carriers. We for example get transit from all members. If we today are to provide IPv6 connectivity, we are using the IPv6 space of our upstream provider. This forces us to rely on their routing policies, which might not be good from a "best for the Internet" view. This said, the reason why we are having this debate at all is the fact that we don't have a PI mechanism, that said the reason we do not have a PI mechanism is the fact that IPv6 does not solve some of the largest problems on the Internet today. But that is a different discussion and I getting enough mail on other lists...:) So - yes I agree with you, however this might lead to other unwanted problems. Best regards, - kurtis -
Let me put it this way, what services do the IXP operators run outside the mesh that absolutely requires IPv6 space and is considered "critical", from the perspective of requiring globally routable space? TLD DNS hosting comes to mind.
and why, if an ixp chooses to do this, is it any different than if anyone else does? you want to do it, you get address space from your up-stream or justify it to an rir just as any other lir does. randy
On Wed, 5 Mar 2003, Randy Bush wrote:
Let me put it this way, what services do the IXP operators run outside the mesh that absolutely requires IPv6 space and is considered "critical", from the perspective of requiring globally routable space? TLD DNS hosting comes to mind.
and why, if an ixp chooses to do this, is it any different than if anyone else does? you want to do it, you get address space from your up-stream or justify it to an rir just as any other lir does.
randy
Hello all, Imho, tld management could perfectly have the same treatment IXPs do. Perhaps the IXP communnity is a bit more v6-aware and was a lot more active at the policy discussion sessions/mailing lists. :-) Being upstream-independent should favour TLDs management's "neutrality", the same way it also favours IXPs management's "neutrality", in terms of addressing. Personnally i wouldnt be against seeing "Global IPv6 internet exchange points assignments" turning into: "Global IPv6 internet critical infrastructure assignments". On the other hand, a third category of assignments (for TLDs management only) could be created. In these cases, /48s assignments from RIRs seems very reasonable to me, not /32s. Regards, ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt <cfriacas@fccn.pt>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167
Hi, On Wed, Mar 05, 2003 at 09:11:08AM +0000, Carlos Friacas wrote:
Personnally i wouldnt be against seeing "Global IPv6 internet exchange points assignments" turning into: "Global IPv6 internet critical infrastructure assignments". On the other hand, a third category of assignments (for TLDs management only) could be created. In these cases, /48s assignments from RIRs seems very reasonable to me, not /32s.
I strongly oppose this. There is nothing special about a TLD name server (or any name server, to be precise, that is not a root name server). Neutrality doesn't come into play - as soon as the TLD holder purchases connectivity anywhere, he isn't neutral anymore anyway. I see using upstream space not significantly different from using upstream connectivity. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
There is nothing special about a TLD name server (or any name server, to be precise, that is not a root name server).
bingo! randy
Let me put it this way, what services do the IXP operators run outside the mesh that absolutely requires IPv6 space and is considered "critical", from the perspective of requiring globally routable space? TLD DNS hosting comes to mind.
and why, if an ixp chooses to do this, is it any different than if anyone else does? you want to do it, you get address space from your up-stream or justify it to an rir just as any other lir does.
See mail to Gert, what worries me is that the IX services then are locked with the upstreams routing policy. - kurtis -
See mail to Gert, what worries me is that the IX services then are locked with the upstreams routing policy.
not exactly. the NON-IX services which the IXP choses to also offer have the same circumstances as any other service provider. such is life. randy
See mail to Gert, what worries me is that the IX services then are locked with the upstreams routing policy.
not exactly. the NON-IX services which the IXP choses to also offer have the same circumstances as any other service provider. such is life.
True, but in my mail to Gert I also said that one of the reasons to locate some services at the IXs is the fact that you can work around this. But that is true only for IPv4 and IPv6. - kurtis -
On Mon, 3 Mar 2003, Arien Vijn wrote:
Pretty common definition (also in RIPE-256):
"An Internet Exchange Point is defined as a physical network infrastructure (layer 2) operated by a single entity whose purpose is to facilitate the exchange of Internet traffic between ISPs. There must be a minimum of three ISPs connected and there must be a clear and open policy for others to join"
[...]
The issues remains the IPv6 space for services. Yes, I know that this has been "discussed" before. However it seems that the discussion has not ended.
Do you see anything related to "services" in the definition above? Exactly. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On 04-03-2003 7:29AM, "Pekka Savola" <pekkas@netcore.fi> wrote:
On Mon, 3 Mar 2003, Arien Vijn wrote:
Pretty common definition (also in RIPE-256):
"An Internet Exchange Point is defined as a physical network infrastructure (layer 2) operated by a single entity whose purpose is to facilitate the exchange of Internet traffic between ISPs. There must be a minimum of three ISPs connected and there must be a clear and open policy for others to join"
[...]
The issues remains the IPv6 space for services. Yes, I know that this has been "discussed" before. However it seems that the discussion has not ended.
Do you see anything related to "services" in the definition above?
Is that required to define an IXP is? Arien
The standard allocation size as per common practice at this point is either /64 or /48. More types of sizes are being debated all the time, but to this day, no other sizes have been established. A /64 might be too small for IXPs with more than one peering mesh, so the next step up is /48.
Per the previous thread here a /64 would be for a very small IX.... - kurtis -
as an IXP-Operator I would like to comment this in three ways:
1. Requesting an Address-space be it v4 or v6 for an IXP-Infrastructure and not making it globally reachable somehow misses the point. It should be clearly reachable - ideally through *all* connected peers of the infrastructure. (they certainly can decide on the security for these destinations) ...
participants (18)
-
Andre Oppermann -
Arien Vijn -
Carlos Friacas -
Fearghas McKay -
Gert Doering -
Jan Czmok -
Jeroen Massar -
Kurt Erik Lindqvist -
Kurt Kayser -
Lars Erik Gullerud -
Masataka Ohta -
Måns Nilsson -
Pekka Savola -
Peter Galbavy -
Pim van Pelt -
Poul-Henning Kamp -
Randy Bush -
Stefan Wahl