On 18-apr-04, at 4:48, Paul Jakma wrote:

...

Oh oh I see another one taking the path that leads to the dark side.

Michel, you forgot to include the audio: http://www.bgpexpert.com/darkside.mp3

Well, let's be honest, name one good reason why you'd want IPv6 (given you have 4)?

Let me count the ways... At home it's great because of the extra address space. I have a /29 at home, which is pretty luxurious compared to what most people have, but not nearly enough to give all my boxes a real address if I turn them all on at the same time. Worse, I still haven't figured out a way to give some machines always the same address (if available) but also use that address for something else if the "owner" is turned off. In IPv6 all of this is a breeze: a single /64 gives you all the addresses you'll ever need and boxes configure themselves with the same address each time they boot, even when using different routers and no need for DHCP. Another thing I really like about IPv6 is the much smarter "on-link" behavior. In IPv4, it's not uncommon to have two hosts on the same physicial subnet, but with addresses from different prefixes. These hosts will then have to communicate through a router, which in this time of cheap 10/100/1000 cards usually isn't the fastest option. In IPv6 each subnet prefix has enough addresses to hold all hosts that you can possibly connect to a layer 2 network in the first place. But it also handles this situation much better, if it comes up: routers can advertise additional prefixes as "on-link" so hosts know they can reach destinations in those prefixes directly over layer 2. Redirects also work across prefixes. (Similarly, routing protocols use link local addresses which make it possible to run RIP or OSPF between two routers that don't share any prefixes.) Since there is no need for NAT, every IPv6 host can run a server for any protocol without trouble. Because of the large address space, scanning address blocks is no longer an option. If you have multiple routers, you pretty much have HSRP/VRRP functionality automatically. Renumbering is much easier. It's also very handy to be able to log in to a box, completely screw up its IPv4 configuration and rebuild it from scratch without having to worry that the host becomes unreachable and needs a powercycle.

And, to be more on-topic, name one good reason why a network operator would want it? Especially given that, apart from the traditional bleeding edges (academic networks), no customers are asking for it.

I think "no customers" is rounding it down slightly. Yes, demand is low, but so is supply, hard to tell which causes which. And customers who do ask, are routinely turned down.

As Paul Vixie points out, without a multihoming solution beyond that offered by 4, v6 networks will look just v4 - most of it will be on non-global address space and NAT. Not really interesting..

Multihoming can be done the same way many people do it for IPv4: take addresses from one ISP and announce them to both. Obviously your /48 will be filtered, but as long as you make sure it isn't filtered between your two ISPs, you're still reachable when the link to either fails. However, this means renumbering when switching to another primary ISP. Not much fun, despite the fact that renumbering is much easier in IPv6.

[snip darth vader]

I know, what's worse is that I know it need not be so. (how's your MHAP doing? How's Iljitsch's geo-assigned addressing proposal?)

Michel is no longer in the IPv6 business, and I've failed miserably at convincing people that geographic aggregation is helpful here. So currently, multi6 is looking at approaches that allow transport protocols to jump addresses in the middle of a session.

On 18-apr-04, at 12:16, Patrick W.Gilmore wrote: [...]

Those are semi-nice features. Not sure I would use it as an excuse to migrate, though, since the need for them can easily be avoided in v4.

Sure. But I do find myself saying "if we were doing IPv6 right now we wouldn't have this problem" more and more.

...

Because of the large address space, scanning address blocks is no longer an option.

You have a /64, scanning that would be an issue. Is scanning a /96 really "no longer an option"? How about in a year? Two years?

People usually get /48s in IPv6, and you're not really supposed to use anything smaller than a /64 for most of the IPv6 address space. Let's assume a scan rate of 10 Gbps @ 64 bytes/packet. This makes it possible to probe in the order of 2^40 addresses per day, so it should take 2^24 days to scan a /64 ~= 46000 years.

...

I think "no customers" is rounding it down slightly. Yes, demand is low, but so is supply, hard to tell which causes which. And customers who do ask, are routinely turned down.

Certainly no customers on "The Web". Maybe some niche applications.

See http://countipv6.bgpexpert.com/. The different numbers under "site" represent different web pages. 8 is a fairly standard one, and it gets around 0.15% visits from people who are v6-capable. (It's a page in Dutch, though, so the results are not representative of the situation in the US.)

...

Multihoming can be done the same way many people do it for IPv4: take addresses from one ISP and announce them to both. Obviously your /48 will be filtered, but as long as you make sure it isn't filtered between your two ISPs, you're still reachable when the link to either fails. However, this means renumbering when switching to another primary ISP. Not much fun, despite the fact that renumbering is much easier in IPv6.

This does not address the issue. If my /48 is filtered, I am still at the mercy of the provider with the super-CIDR. If that network is down, so am I.

True. However, many people don't get to do better than this in v4 either.

(And don't even think about saying backbones never go down.)

Wouldn't dream of it. :-)

On 18-apr-04, at 23:25, Paul Jakma wrote:

...

Sure. But I do find myself saying "if we were doing IPv6 right now we wouldn't have this problem" more and more.

Which problem is that? ;)

(and if it involves NAT... sorry, no.)

There are actually problems in networking that don't involve NAT... :-) Here's a good one: a customer of mine is a fast growing web hosting outfit. Many of their customers start out with one or two boxes and a handful addresses, and then grow. They put a bunch of these customers in a /24, but after a while the /24 is full and/or the customer gets a subnet of their own. So far so good. They use a layer 2 setup with significant redundancy, which inevitably leads to traffic being flooded by the switches some of the time. This means a customer receives a LOT of traffic they have no interest in. The solution here would be giving each customer their own VLAN, but this is hard to do at this juncture as the IP subnets are tightly interwoven between customers. (Doing it from the start would take too much configuration and burn address space a lot faster.) And since invariably one of the first IP addresses such a customer gets is used as an authoritative DNS, they're in no hurry to renumber. With IPv6, every customer would get their own /48, whether they need a single address or thousands. This makes moving a customer from one VLAN to another very simple, allowing the flooding problem to be controlled much better.

...

See http://countipv6.bgpexpert.com/. The different numbers under "site" represent different web pages. 8 is a fairly standard one, and it gets around 0.15% visits from people who are v6-capable.

And are these sites in any way related to IPv6 or networking? (news at 11, Web sites about IPv6 get less than 1% v6 traffic ;) )

Number 8 isn't. The other ones are to different degrees. Haesu wrote:

...

...

Renumbering is much easier.

...

I like this one.

Now this is a funny one about IPv6. How is renumbering *any* easier than IPv4? Yes you have autoconf based on route advertisements/solicits on the client end from the routers, but how is that any different than IPv4+DHCP?

Is it perhaps b/c IPv6 uses "classful" styled numbering scheme? (i.e. you have /64 to end sites, where you simply s/old:old:old:old/new:new:new:new/ )

This helps in editing the config files of course. However, the main difference is that with IPv6 you can change router advertisements, and within minutes all the boxes start using the new addresses, *without* breaking running sessions toward the old addresses. With DHCP you're at the mercy of the lease time timeouts and the way operating systems handle those. (For instance, under certain circumstances Windows stores its DHCP address on disk and doesn't bother to refresh it even after a reboot. Nice.) Michel's bottom line:

- Today, what to do with IPv6 is simple: nothing. Whether you are an end-user/small business, large enterprise or provider everyone is in the same situation: is costs money to upgrade, causes trouble,

Actually it's cheaper and easier than expected: http://nwfusion.com/news/2003/1215ipv6.html

not the only thing we have to do anyway, there is no demand and therefore no ROI. It is urgent to wait.

The nice (but sometimes frustrating) thing about IPv6 is that we can take (in internet time) forever to upgrade. At this point, the most important thing is to avoid building new stuff that will get in the way of IPv6 when the time comes that deploying v6 starts making sense. Unfortunately, few people understand the idea of taking 5 or 10 years to upgrade, they think this means doing nothing for 4,5 or 9,5 years and then frantically start throwing money at the problem. Oh well.

On Apr 18, 2004, at 1:06 PM, Iljitsch van Beijnum wrote:

On 18-apr-04, at 12:16, Patrick W.Gilmore wrote:

...

Those are semi-nice features. Not sure I would use it as an excuse to migrate, though, since the need for them can easily be avoided in v4.

Sure. But I do find myself saying "if we were doing IPv6 right now we wouldn't have this problem" more and more.

If you completed that thought, you would realize, "but I'd have so many more problems which are so much harder to overcome (if it is even possible to overcome them), that it really ain't worth it." Of course, many technologies start out as inferior cousins to existing stuff. Just not usually "version 6"....

...

...

Multihoming can be done the same way many people do it for IPv4: take addresses from one ISP and announce them to both. Obviously your /48 will be filtered, but as long as you make sure it isn't filtered between your two ISPs, you're still reachable when the link to either fails. However, this means renumbering when switching to another primary ISP. Not much fun, despite the fact that renumbering is much easier in IPv6.

...

This does not address the issue. If my /48 is filtered, I am still at the mercy of the provider with the super-CIDR. If that network is down, so am I.

True. However, many people don't get to do better than this in v4 either.

Anyone who tries and does not use one of the handful of providers who filter does. IOW: This is a non-argument. The point still stands - without real multi-homing so I do not have to be dependent upon a single vendor, IPv6 is simply not an option. Quick Meta-Question: Why was was this even considered when v6 was being engineered? Are the people who started the v6 movement really that out-of-touch with reality? Or were they arrogant enough to believe they could limit control to a few entities and the user base would just go along with it? -- TTFN, patrick

At 10:32 AM +0200 4/18/04, Iljitsch van Beijnum wrote:

And customers who do ask, are routinely turned down.

Change providers. A request for new functionality from existing customers may not always get the attention it deserves, but I don't know of a provider that doesn't sit up and pay attention when a customer leaves to the competition. And what does it say if you're not willing to go through the hassle to change providers to get IPv6 services? :-) /John

On Sun, 18 Apr 2004, Iljitsch van Beijnum wrote:

Let me count the ways... At home it's great because of the extra address space. I have a /29 at home, which is pretty luxurious compared to what most people have, but not nearly enough to give all my boxes a real address if I turn them all on at the same time.

Not that luxurious really, if you have a need, find a reasonable ISP and ask and you'll receive.

this is a breeze: a single /64 gives you all the addresses you'll ever need and boxes configure themselves with the same address each time they boot, even when using different routers and no need for DHCP.

Right, the sparse density of v6 is definitely a win. But why care about getting same address? Anyway, see below about the NAT premise. (v4 also has reasonably abundant site-local space).

Another thing I really like about IPv6 is the much smarter "on-link" behavior.

Right, yes, but hardly a killer feature.

But it also handles this situation much better, if it comes up: routers can advertise additional prefixes as "on-link" so hosts know they can reach destinations in those prefixes directly over layer 2. Redirects also work across prefixes. (Similarly, routing protocols use link local addresses which make it possible to run RIP or OSPF between two routers that don't share any prefixes.)

Yep.

Since there is no need for NAT, every IPv6 host can run a server for any protocol without trouble.

But there _will_ be NAT, that is the very premise of this discussion, as offered by Paul Vixie. So that one doesnt count, unless you knock down the premise: There will be site-local and NAT with v6 because of the multihoming problem.

Because of the large address space, scanning address blocks is no longer an option.

If you have multiple routers, you pretty much have HSRP/VRRP functionality automatically.

Right, but you can do this router-side with v4 anyway. v6 makes it more integrated, but its hardly something which v4 does not have.

Renumbering is much easier.

I dont see how though. I can switch v4 addresses with DHCP as easily as with RAs on v6. Sure, the routing will be slightly more fluid with v6, but I can route multiple logical subnets with v4 anyway during transition. The hard bits of renumbering are _not_ in changing the actual assigned and used addresses IMHO.

It's also very handy to be able to log in to a box, completely screw up its IPv4 configuration and rebuild it from scratch without having to worry that the host becomes unreachable and needs a powercycle.

That's hardly a reason to upgrade to v6. You could as well insert any non-v6 protocol in there that gives you access. That is as much an argument for running DEC LAT as it is for IPv6. :) (http://linux-decnet.sourceforge.net/lat.html)

Multihoming can be done the same way many people do it for IPv4: take addresses from one ISP and announce them to both.

Obviously yes. In which case, why bother? If you have a need for PI IPv4 addresses you can get them, and v6 will operate the same way - demonstrate need and you get them. If you cant demonstrate a need, you'll have to use PA. Indeed, for v4 the bar is much _lower_, if you can show you would use 10 bits of routable space you very likely will get PI assigned space, however, for v6 not only must you be able to show reasonable usage of the 16 bits provided for by standard PA, you would need to demonstrate you have a further need for the additional 16 bits needed for the minimum v6 PI assignments. So, for smaller players wishing to get PI, v4 is much easier. (and yes, i know at moment RIR requirements are relaxed, but only so as to encourage some kind of v6 up take, and its still very low.)

Obviously your /48 will be filtered, but as long as you make sure it isn't filtered between your two ISPs, you're still reachable when the link to either fails.

So you're restricted to upstreams who not only peer with each other, but will cooperate sufficiently to allow a joint customer to announce sub-assignment of one to the other. The vague impression I have is that this is extremely rare :)

ISP. Not much fun, despite the fact that renumbering is much easier in IPv6.

Hence the premise of this thread, v6 will have site-local and NAT.

Michel is no longer in the IPv6 business, and I've failed miserably at convincing people that geographic aggregation is helpful here.

Very very sad. But obviously geo-aggregration is not in providers interests, so...

So currently, multi6 is looking at approaches that allow transport protocols to jump addresses in the middle of a session.

And these approaches will equally apply to v4. Still no reason to switch to v6. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam@dishone.st Fortune: Technological progress has merely provided us with more efficient means for going backwards. -- Aldous Huxley

--On 18 April 2004 03:48 +0100 Paul Jakma <paul@clubi.ie> wrote:

Well, let's be honest, name one good reason why you'd want IPv6 (given you have 4)?

As an IPv6 skeptic I would note that some protocols NAT extremely badly (SIP for instance), and the bodges to fix it are costly. So if IPv6 means I can avoid NAT, that can actually save $$$. Alex

We need one (or more) of the p2p vendors to support it.

ask not what X can do for you, but what you can do for X. i.e., what does ipv6 do for the p2p vendors? randy