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.

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

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 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

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

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

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

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

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

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 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 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

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.

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.

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.

--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.

--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.

--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.

--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.

...

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 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.

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.

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

| Client side: yes, of course. Linux and BSD pppoe can do it, and "most | recent" Cisco IOSes can do that as well. | | We have a couple of PPPoE DSL customers that use IPv6. Gert, Which equipment do you use on ISP side, and which on client side ? And do you use Cisco RBE (or SuperVLANs for Riverstone/Extreme) ? I'm interrested in knowing how many customers you are connecting via your current hardware. Do you also do 'classic' PPPoA ? groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment -----------------------------------------------

Hi Gert!

...

Side question: do a PPPoE exist for IPv6 ? Client side: yes, of course. Linux and BSD pppoe can do it, and "most recent" Cisco IOSes can do that as well. We have a couple of PPPoE DSL customers that use IPv6. This sounds very interesting. We got a 6WIND-router day before yesterday and we would like to test PPPoE with IPv6 with that machine. Do you use IPv4 at all or is the whole connecting done without any IPv4 involved at all?

Christian -- JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westfaelische Wilhelms-Universitaet Muenster http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung Team: join@uni-muenster.de Roentgenstrasse 9-13 Priv: strauf@uni-muenster.de D-48149 Muenster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31653

Hi Gert!

IPv4 is still used, of course, as all customers still need IPv4 connectivity.

v6-only might work (if the client refuses IPCP), but we never tried that yet. So, if I understand you correctly, you simply dial-up and establish a normal DSL-connection via PPPoE (v4) and then assign an IPv6-address to the ppp-interface, right? Please excuse my probably trivial questions, but I'm pretty new to PPPoE in connection with IPv6. How exactly is the v6-address (or is it a whole prefix?) assigned at your customer's end? We would like to do some tests ourselves with IPv6-only dialup and I would like to find out wether or not I can leave out all v4-parts of the connection. If this is starting to get off-topic, I would really appreciate, if you could send me a private mail regarding this matter. TNX a lot in advance!

Christian -- JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westfaelische Wilhelms-Universitaet Muenster http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung Team: join@uni-muenster.de Roentgenstrasse 9-13 Priv: strauf@uni-muenster.de D-48149 Muenster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31653

Hi, On Fri, Mar 07, 2003 at 10:14:32AM +0100, Xavier Henner wrote:

1) "White Paper protocol" : you write the prefix on a sheet of paper, you give it to the custommer and he configures his router. The prefix is static. 2) Use of a new ICMP message 3) DHCPv6

4) RA messages which works 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

hi, On Fri, Mar 07, 2003 at 10:59:24AM +0100, Christian Strauf wrote:

...

4) RA messages Ok, this would be something like the RA proxy presented under 3.1.1 in draft-huitema-v6ops-unmaneval-00.txt. This and DHCPv6 sounds like a good solution to me. I will look into this. Thank you very much for the hints!

As far as I understand, there's no proxying involved. The client connects over PPP/IPv6CP, the router advertises the prefix to be used via RA messages. Of course if the client is a *router*, it needs to "relay" or proxy the RA messages to the local LAN. 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

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

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.

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

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.

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

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

Kurt;

...

...

...

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.

Interesting argumentation. You are aware that there are quite a lot of people who think that this is the only possible way forward?

Huh? Just at the time GSE was proposal, there are a few people who thought so. However, shortly after that, I have never seen anyone actively supporting GSE. Some just mention GSE without understanding its content, but that's all.

Do you have any more substantial arguments against GSE or 8+8, rather than the ones above?

I have no argument against 8+8. Masataka Ohta

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 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

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

...

...

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.

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 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

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) ...

<http://psg.com/~randy/970210.nanog/sld008.htm> randy