On 17/02/2007, at 3:01 AM, Joe Abley wrote:

It's an interesting problem, though. If you ran an enterprise with 23 million employees, and an ever increasing number of them needed a permanent connection to the Internet, what would you do? On that scale, and given a certain amount of centralised control of content and infrastructure, what looks more expensive? NAT or IPv6?

End-to-end IP connectivity is so passe. I'd give them proxy servers for HTTP, and servers per network for SMTP/POP3/IMAP etc. (DNS intentionally left off - why do end users need it at this point?). Forget about SIP NAT and all that similar trash - have it talk to network local SBCs (or similar). They probably don't /really/ need to exchange IP with people outside their network, most will only care that they can browse [local auction site]. I suspect such an approach would suit [country] well, infact. Maybe [vendor H] should go in to the proxy server market. It wouldn't be hard, [vendor N] proxy servers are little more than flashed up PCs - not hard to copy^Wduplicate^Wtake inspiration from. So, now which is more expensive? NAT, IPv6, or Proxying/local servers? Consider that many organisations already run proxy servers for authentication reasons, and don't allow any end user IP outside their organisation.. -- Nathan Ward

On 17/02/2007, at 9:51 AM, Philip D'Ath wrote:

This one is easy.

Now surely we all know by now that it is never easy! :)

What you're suggesting would require thousands of servers to be deployed. And then add the server management cost to that, and it would easily be the most expensive solution - but a long way.

That's a pretty simplistic analysis. For starters, the costs associated with deploying and managing servers is well understood. The cost of deploying IPv6 networks is not. Except a lot of these devices are deployed now anyway. Many VoIP PBXs proxy both media and signalling (Nathan's session border controller) as a means to implement security policy. I'm sitting behind a transparent proxy at the moment. Most businesses these days have firewalls of some description, again to force traffic through a policy enforcement point. There are only a couple of networks where I can now reasonably expect to be able to send out on TCP/25 to anything other than the local network's nominated mail server. These things are already busting end to end connectivity. At the risk of taking this thread somewhere it shouldn't - do we even care about end to end connectivity anymore?

NAT breaks lots of protocols, and makes others more difficult to work reliably. It is going to generate more help desk calls than something which doesn't use NAT.

So perhaps we reached a point where it should be considered bad form for one to design protocols that are not NAT friendly then?

This only leaves IPv6 as the cheapest option.

That would explain the hordes rushing to deploy it then! Cheers, Jonny.

-----Original Message----- From: Nathan Ward [mailto:nznog(a)daork.net] Sent: Saturday, 17 February 2007 11:01 a.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] [Fwd: [pacnog] IPv4 exhaustion discussionsin AsiaPacific region]

On 17/02/2007, at 3:01 AM, Joe Abley wrote:

...

It's an interesting problem, though. If you ran an enterprise with 23 million employees, and an ever increasing number of them needed a permanent connection to the Internet, what would you do? On that scale, and given a certain amount of centralised control of content and infrastructure, what looks more expensive? NAT or IPv6?

End-to-end IP connectivity is so passe. I'd give them proxy servers for HTTP, and servers per network for SMTP/POP3/IMAP etc. (DNS intentionally left off - why do end users need it at this point?). Forget about SIP NAT and all that similar trash - have it talk to network local SBCs (or similar).

They probably don't /really/ need to exchange IP with people outside their network, most will only care that they can browse [local auction site]. I suspect such an approach would suit [country] well, infact. Maybe [vendor H] should go in to the proxy server market. It wouldn't be hard, [vendor N] proxy servers are little more than flashed up PCs - not hard to copy^Wduplicate^Wtake inspiration from.

So, now which is more expensive? NAT, IPv6, or Proxying/local servers?

Consider that many organisations already run proxy servers for authentication reasons, and don't allow any end user IP outside their organisation..

-- Nathan Ward

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

On 17/02/2007, at 3:23 PM, Alastair Johnson wrote:

Jonny Martin wrote:

...

At the risk of taking this thread somewhere it shouldn't - do we even care about end to end connectivity anymore?

For the majority of people? No. End-to-End has been gone for a long time, as you correctly point out.

I wonder how many large ISPs are currently looking at NATing their dialup pools. Given that most people still using dialup these days don't actually need end-to-end connectivity, and it's low-bandwidth/low-connection volume (and reasonably easy to implement on the NAS, rather than needing giant NAT boxes), it's a quick win to reclaim some address space if you're really hurting.

Indeed. It's also likely that many of those customers are running older machines, and are more susceptible to attacks of some flavor directed at their network interfaces. If they are behind a NAT, these customers are more likely to be protected. Those who need to run mail servers or something are on static IP addresses anyway. Those who want to run non-NAT-friendly applications can pay an extra $5/mo (or nothing, maybe) for the "full" service, and get a public IP when they dial in. <tongue in cheek> Then, (if you choose to charge it) use that $5/mo to fun IPv6 deployment. If that doesn't give you enough $, the bulk of your customers clearly don't need end-to-end IP that much, so go home, and have a beer. -- Nathan Ward

NAT, if my memory serves me right, is not a security mechanism - that is a by-product of it's main goal of preventing the exhaustion of the v4 address space. IMHO (and flame me for this off-list if you want) NAT should not be used as protection - that is something Windows/Microsoft jumped on because the services on the OS were vulnerable, ie it introduced security without the dev's doing much more work. IPv6 is going to give us true global end-to-end and you guys are talking about not using that?? sorry I had a few beers today. Nathan Ward wrote:

On 17/02/2007, at 3:23 PM, Alastair Johnson wrote:

...

Jonny Martin wrote:

...

At the risk of taking this thread somewhere it shouldn't - do we even care about end to end connectivity anymore?

For the majority of people? No. End-to-End has been gone for a long time, as you correctly point out.

I wonder how many large ISPs are currently looking at NATing their dialup pools. Given that most people still using dialup these days don't actually need end-to-end connectivity, and it's low-bandwidth/low-connection volume (and reasonably easy to implement on the NAS, rather than needing giant NAT boxes), it's a quick win to reclaim some address space if you're really hurting.

Indeed. It's also likely that many of those customers are running older machines, and are more susceptible to attacks of some flavor directed at their network interfaces. If they are behind a NAT, these customers are more likely to be protected.

Those who need to run mail servers or something are on static IP addresses anyway. Those who want to run non-NAT-friendly applications can pay an extra $5/mo (or nothing, maybe) for the "full" service, and get a public IP when they dial in.

<tongue in cheek> Then, (if you choose to charge it) use that $5/mo to fun IPv6 deployment. If that doesn't give you enough $, the bulk of your customers clearly don't need end-to-end IP that much, so go home, and have a beer.

-- Nathan Ward

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

-- Stuart MacIntosh IT Consultancy & Technical Services Phone: +64 21 2259576 Email: stuart(a)linuxsecurity.co.nz

...

should not be used as protection - that is something Windows/Microsoft jumped on because the services on the OS were vulnerable, ie it introduced security without the dev's doing much more work.

Correct, but it is a mighty handy side effect of NAT. It's another layer of security that is better than nothing. I would hazard a guess that for the majority (i.e. residential broadband customers), nothing is the alternative.

I take it the recently reported issue of an entire country (Dubai?) being blocked from editing Wikipedia articles due to the abuse of a single user of the single IP address behind which much of the country was NAT'd, isn't an issue of this then? Security is one thing, but isn't there an obscurity issue to be raised as well? (A cheap, NAT'd and thus semi-anonymous, dialup ... hmm... am I just pessimistic about user tendencies?) Mark.

On Sat, 17 Feb 2007, Mark Foster wrote:

I take it the recently reported issue of an entire country (Dubai?) being blocked from editing Wikipedia articles due to the abuse of a single user of the single IP address behind which much of the country was NAT'd, isn't an issue of this then?

I believe that was the entire country was behind that IP since it was being used to filter web/monitor traffic, so they were not actually NATed. Personally I think NATing at this is a bad idea, you aren't gaining anything more than a (non NATing) firewall does and it breaks p2p protocols and other random apps. Charging extra money for IPs is not going to work if you are effectivly charging $5 for MSN, bitorrent or whatever to work while other companies don't apply that charge. and remember you have to remote admin Grandma's PC :) -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

Jonny Martin wrote:

On 17/02/2007, at 10:52 AM, Stuart MacIntosh wrote:

...

NAT, if my memory serves me right, is not a security mechanism - that is a by-product of it's main goal of preventing the exhaustion of the v4 address space. IMHO (and flame me for this off-list if you want) NAT should not be used as protection - that is something Windows/Microsoft jumped on because the services on the OS were vulnerable, ie it introduced security without the dev's doing much more work.

Correct, but it is a mighty handy side effect of NAT. It's another layer of security that is better than nothing. I would hazard a guess that for the majority (i.e. residential broadband customers), nothing is the alternative. I agree, the security benefits are welcome. In my IPv6 network mr. router applies security in much the same way as a NAT-IPv4 router does.

...

IPv6 is going to give us true global end-to-end and you guys are talking about not using that??

Not quite, we're indirectly asking the question of whether IPv6 is in fact the best 'next step' for internet users.

My mother doesn't care about end to end connectivity. In fact neither does anyone else in my family. However they do care about being able to 'use the internet' - which is not predicated on end to end connectivity. I think global end-to-end is the only way forward, it's either that or messy IPv4&NAT networks. And since OS's have had it far too easy thanks to NAT, security in IPv6 still needs to be applied at the router level.

The IPv4 NAT/Firewalling idiom can be implemented at the router level in v6 easily. I can't say I have much experience with netsh or IOS but in Netfilter/IPtables we just add rules to the FORWARD table with ip6tables. Something alot of people don't notice is that side-by-side, IPv6 is simpler than IPv4 and NAT.

Cheers, Jonny.

Cheers Jonny, I appreciate your feedback. -- Stuart MacIntosh IT Consultancy & Technical Services Phone: +64 21 2259576 Email: stuart(a)linuxsecurity.co.nz

Nathan Ward wrote:

On 17/02/2007, at 5:35 PM, Stuart MacIntosh wrote:

...

I agree, the security benefits are welcome. In my IPv6 network mr. router applies security in much the same way as a NAT-IPv4 router does.

Which ruins any end-to-end benefits that IPv6 was going to give over IPv4, right? (ie. SIP, etc. won't work, unless the router knows about it)

So, why are we caring about IPv6 as a means to preserve end-to-end IP, if moving to IPv6 means we don't really get it either?

Proxies etc. can be deployed, and be working for everyone (save a few corner cases, perhaps), right now. They don't require any global switchover/upgrade/etc. and on top of that, they can be used as extra revenue streams/products/etc.

If everyone had one computer (network enabled device) behind one NAT device your statement may actually start approaching truth. However, as is becoming increasingly common, this is not the case. Please play again :-) -- Steve.

Nathan Ward wrote:

On 17/02/2007, at 7:14 PM, Steve Phillips wrote:

...

Nathan Ward wrote:

...

Proxies etc. can be deployed, and be working for everyone (save a few corner cases, perhaps), right now. They don't require any global switchover/upgrade/etc. and on top of that, they can be used as extra revenue streams/products/etc. If everyone had one computer (network enabled device) behind one NAT device your statement may actually start approaching truth.

However, as is becoming increasingly common, this is not the case.

Please play again :-)

It'd still work, as far as I can see.. They wouldn't be able to do non-nat-friendly protocols to their ISP's proxy/etc. servers, but if the ISP chooses to support protocols that don't have that problem, it's not a problem.

Like most peer to peer type protocols (that 'sorta work on some devices') like - um.. xbox live ? msn (file transfer and video calling) etc etc. having individually numbered devices and standard firewall rules is like having one to one NAT, which is desirable. what's desirable and what tends to get implemented however may not be the same thing, but seriously, are you saying that we _shouldn't_ be striving for this ? (I did note you said you 'don't think IPv6 deployment is a good thing' <g>) -- Steve.

Right, but NAT breaks those protocols now, and those protocols don't do IPv6 either[1].

Many do support IPv6 now, and those that don't either have it in their roadmap or could implement it if there was demand. NAT is a constant irritation every day for me with SIP. We do use SBC's, but NAT still causes problems from time to time when we run into a device that times out connection states incredibly quickly, or implements a highly restrictive form of NAT. Using NAT to free up IP space is only a half-assed short term quick fix: what happens when the next big application comes along that needs end to end connectivity and suddenly operators find they have to migrate to IPv6 very quickly? IPv6 is the logical progression, it probably is premature to migrate to it immediately, but there certainly should be pressure applied to hardware vendors to support it as this will make implementation far easier. -Scott

Or worse still, everyone starts using tunnelled IPv6 connections. Meaning at the IPv4 layer you see nothing useful anymore, and traffic engineering (aka shaping and rate limiting) will become much harder. -----Original Message----- ...

Which ruins any end-to-end benefits that IPv6 was going to give over IPv4, right? (ie. SIP, etc. won't work, unless the router knows about

it)

IPSec support is a requirement of the IPv6 specification. If people start blocking protocols on firewalls, or throttling/ratelimiting them then end users are just going to start enabling ESP. We already see this in a crude manner with people deliberately avoiding various TCP/IP ports that are "well known" to be related to bandwidth intensive applications because of real or percieved bandwidth limitations.

Proxies etc. can be deployed, and be working for everyone (save a few

corner cases, perhaps), right now. They don't require any global switchover/upgrade/etc. and on top of that, they can be used as extra

revenue streams/products/etc.

That's all fine for perhaps HTTP, HTTPS, DNS and SIP. What about bittorrent? How do you suggest you proxy that?

Nathan Ward wrote:

On 17/02/2007, at 3:23 PM, Alastair Johnson wrote:

...

Jonny Martin wrote:

...

At the risk of taking this thread somewhere it shouldn't - do we even care about end to end connectivity anymore?

For the majority of people? No. End-to-End has been gone for a long time, as you correctly point out.

I wonder how many large ISPs are currently looking at NATing their dialup pools. Given that most people still using dialup these days don't actually need end-to-end connectivity, and it's low-bandwidth/low-connection volume (and reasonably easy to implement on the NAS, rather than needing giant NAT boxes), it's a quick win to reclaim some address space if you're really hurting.

Indeed. It's also likely that many of those customers are running older machines, and are more susceptible to attacks of some flavor directed at their network interfaces. If they are behind a NAT, these customers are more likely to be protected.

This is becoming less true as every protocol under the sun tries to deal with "breaking through" NAT. Programs need to talk to someone that's not behind NAT to provide a temporary port forward. These machines they talk to are now high value targets as they contain lists of large numbers of computers that are running a particular piece of software and a way to connect back to them even through a connection tracking firewall or NAT box.

Alastair Johnson wrote:

Jonny Martin wrote:

...

At the risk of taking this thread somewhere it shouldn't - do we even care about end to end connectivity anymore?

For the majority of people? No. End-to-End has been gone for a long time, as you correctly point out.

Has it really? Some of the common protocols are: HTTP, HTTPS, IMAP, POP3, SMTP, bittorrent, emule, gnutella, napster, DC, NNTP. IRC, MSN, Windows traffic (SMB, Winpopup etc), warcraft, CitrixICA, RTSP, Counter Strike, DNS, Battlefield 2, XBox, WMP, GRE, IPSec, SIP, IAX2. (and so on) Of these protocols: * Doesn't care about E2E as long as the server is public: HTTP, HTTPS, IMAP, POP3, SMP, NNTP, CitrixICA, RTSP(?), Warcraft, CounterStrike, DNS, Battlefield2, XBox (?), WMP, IAX2. * Has reduced functionality in the presence of NAT: Bittorrent, emule, gnutella, napster, DC, IRC (DCC doesn't work), MSN (I believe), Windows traffic, GRE, IPSec, SIP. Now many of the protocols in the "reduced functionality" area are aware of NAT and try (some more successfully than others) to soften it's effects. Most still require, or at least perform better if you statically forward a port from the NAT gateway (and many will try and do this via UPnP if possible). Some can work via NAT so long as only one client at a time uses them from behind the NAT. All the ones in the first category require you run a server thats not NATted (or at least portforwarded). Of those protocols, HTTP, HTTPS and DNS are the only ones that can be trivially proxied. Most of the others work over a web proxy, many of the later ones are UDP or IP based and can't be transported over an HTTP Proxy. The interesting question is what proportion of an ISP's customers are only using POP3/SMTP/HTTP and are unlikely to notice NAT. Then we get into issues about your NAT box. For instance TCP's WindowScale option is often corrupted by state tracking firewalls causing TCP connections to falter and stall if your TCP stack is optimised for high bandwidth delay networks. Does your NAT box understand all TCP options, (including the weird ones like MD5 signatures or T/TCP?), Does your NAT box correctly deal with all ICMP codes? What about non UDP/ICMP/TCP protocols such as GRE, IPSec (AH and ESP?), DCCP, or SCTP? How much state can these boxes deal with? Can they deal with one client suddenly creating a few thousand or million state entries?

I wonder how many large ISPs are currently looking at NATing their dialup pools. Given that most people still using dialup these days don't actually need end-to-end connectivity, and it's low-bandwidth/low-connection volume (and reasonably easy to implement on the NAS, rather than needing giant NAT boxes), it's a quick win to reclaim some address space if you're really hurting.

Are all the users that are trying to use the more sophisticated protocols all using broadband? Is broadband available in their areas? How good is the NAT implementation in these boxes?

Can you explain how you arrived at this? Some starters: - Are you finding server ports by counting incoming packets to that port or outgoing packets from that port? - Bits or packets? (this may explain NTP, etc.) - Are these NZ, or international (you might not be able to answer that, though. I'm not asking who, of course, just locality.) - Are you looking at end users, or any endpoint IP address that you see? (ie. internal endpoints or external endpoints or both?) On 21/02/2007, at 12:52 AM, Perry Lorier wrote:

(Sorry for the late reply to this email, I've been doing this in my spare time and it takes at least 4 hours to processes these files)

...

For the majority of people? No. End-to-End has been gone for a long time, as you correctly point out.

Many people run their own NAT's. That means you can configure your own port forwards, and your modem can support UPnP. People may also be avoiding nat by using USB/Internal modems.

So, how many people actually do more than just "email and web"?

Well, I ran an analysis of DSL customers[1] over the space of 24 hours [4] to see how many different protocols people were using. For each IP I kept track of the number of unique "server ports"[2] were used.[3]

10% of people use =< 5 protocols, 20% use =< 6 30% use =< 11 40% use =< 23 50% use =< 35 60% use =< 58 70% use =< 138 80% use =< 427 90% use =< 2144

At a guess, people that have more than 20 "server ports" are probably involved in some kind of p2p (which usually doesn't interact well with NAT).

Heres some of the top port groups that people use:

1 server port per IP: 21/tcp, 22/tcp, 53/udp, 123/udp, 135/tcp, 445/tcp. 2 server ports per IP: 25/tcp 110/tcp 53/udp 80/tcp 53/udp 110/tcp 53/udp 123/tcp 3 server ports per IP: 21/tcp 53/udp 123/udp 22/tcp 53/udp 80/tcp 25/tcp 53/udp 110/tcp 53/udp 80/tcp 110/tcp 53/udp 80/tcp 123/udp 53/udp 80/tcp 443/tcp 4: 22/tcp 53/udp 80/tcp 443/tcp 25/tcp 53/udp 80/tcp 110/tcp 53/udp 80/tcp 110/tcp 123/udp 53/udp 80/tcp 110/tcp 443/tcp 53/udp 80/tcp 123/udp 443/tcp 5: 22/tcp 53/udp 80/tcp 110/tcp 443/tcp 25/tcp 53/udp 80/tcp 110/tcp 123/udp 53/udp 80/tcp 110/tcp 123/udp 443/tcp 25/tcp 53/udp 80/tcp 110/tcp 443/tcp 20/tcp 21/tcp 53/udp 80/tcp 443/tcp 6: There are too many combinations to list, so heres some highlights: 9/udp, 20/tcp, 21/tcp, 25/tcp, 53/udp, 80/tcp, 110/tcp, 123/udp, 443/tcp, 1935/tcp, 8081/tcp,

Highlights from the rest of the data: 21/tcp, 22/tcp 25/tcp, 53/udp, 80/tcp, 110/tcp, 123/udp, 135/tcp, 139/tcp, 443/tcp, 445/tcp, 1433/tcp 5900/tcp, 6000/tcp 7001/udp, 8080/tcp.

Around about position #50 turns up the bittorrent default port numbers if that means anything anymore.

I must say I'm surprised at the amount of ntp (123/udp) traffic there is around, although it makes sense I guess.

If anyone can think of any other interesting stats to get from this data that might be relevant let me know and I'll see what I can do. ---- [1]: yeah, I don't have any dialup info sorry. If someone wants to give me some dialup data I'll redo the stats for them. [2]: The precise definition of server port is complicated, and to be honest, boring. Basically "port 80" "port 25", for some stuff that avoids having a fixed server port, one end is picked. [3]: This analysis is all stuff I've done in my spare time, and isn't very rigorous, so don't treat it as gospel, but I hope it's representative of whats going on. [4]: I could do longer, but then it just takes longer to get results. Hopefully 24 hours is more or less representative.

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

!DSPAM:22,45dae10b258783621613398!

-- Nathan Ward

Nathan Ward wrote:

Err, ignore the bits/packets bit. It's late, shush.

I'll replace it with: - Did you allow for dynamic IP addresses, or is that not relevant here?

I'm assuming they're unlikely to change over the course of a day. I think the assumption is fairly safe. I've not had time to do any work on seeing how valid this assumption is.

On Wed, 2007-02-21 at 00:52 +1300, Perry Lorier wrote:

(Sorry for the late reply to this email, I've been doing this in my spare time and it takes at least 4 hours to processes these files)

...

For the majority of people? No. End-to-End has been gone for a long time, as you correctly point out.

Many people run their own NAT's. That means you can configure your own port forwards, and your modem can support UPnP. People may also be avoiding nat by using USB/Internal modems.

So, how many people actually do more than just "email and web"?

Well, I ran an analysis of DSL customers[1] over the space of 24 hours [4] to see how many different protocols people were using. For each IP I kept track of the number of unique "server ports"[2] were used.[3]

10% of people use =< 5 protocols, 20% use =< 6 30% use =< 11 40% use =< 23 50% use =< 35 60% use =< 58 70% use =< 138 80% use =< 427 90% use =< 2144

At a guess, people that have more than 20 "server ports" are probably involved in some kind of p2p (which usually doesn't interact well with NAT).

Heres some of the top port groups that people use:

Interesting analysis Perry. What makes you certain that actual people are generating use on these ports vs trojans, worms and the like? jamie

Perry, Excellent work. I've always been tempted to say "prove it" when people say [x]% of users only use email and http but end up just accepting that it's probably true. I think the amount of "protocol diversity" here is a bit higher than a truly random sample if the following is true: 1. Netizens with less clue use less ports. 2. Most netizens with less clue use dialup. 3. Most DSL netizens with less clue use xtra. 4. You didn't have access to data from xtra customers. Having said that, I think we can say *with some proof* that a large percentage of users would have serious problems if an ISP were to NAT everyone. And, if it's possible to draw one conclusion from the massive v6 thread (which I don't think it is but I'll try anyway), since NAT is not going to work at an ISP level even as a delay tactic - IPv6 must be implemented once IPv4 address space runs out. The only questions are, will people invest early to make this a smooth transition? Will one/two/more/all vendors have such an easy migration path that you don't need to migrate early? Once again, thanks to Perry, Jonathan Perry Lorier wrote:

Well, I ran an analysis of DSL customers[1] over the space of 24 hours [4] to see how many different protocols people were using. For each IP I kept track of the number of unique "server ports"[2] were used.[3]

10% of people use =< 5 protocols, 20% use =< 6 30% use =< 11 40% use =< 23 50% use =< 35 60% use =< 58 70% use =< 138 80% use =< 427 90% use =< 2144

Hi Perry, Very interesting analysis... On Wed, 2007-02-21 at 00:52 +1300, Perry Lorier wrote:

I must say I'm surprised at the amount of ntp (123/udp) traffic there is around, although it makes sense I guess.

My guess is that this is due to a large number of DSL routers sold now having NTP servers in them to set their clocks. Even if the end users don't know they're using NTP (or WTF NTP is), they are.

If anyone can think of any other interesting stats to get from this data that might be relevant let me know and I'll see what I can do.

I'd be very interested in the amount of 6in4 and Teredo traffic on DSL now. Especially to see if is increasing due to the Vista release. Cheers! -- Andrew Ruthven, Wellington, New Zealand At home: andrew(a)etc.gen.nz | This space intentionally | left blank.

-----Original Message----- From: Andrew Ruthven [mailto:andrew(a)etc.gen.nz] Sent: Wednesday, 21 February 2007 09:56 To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] ISP's Natting customer pools Hi Perry, Very interesting analysis... On Wed, 2007-02-21 at 00:52 +1300, Perry Lorier wrote:

I must say I'm surprised at the amount of ntp (123/udp) traffic there is around, although it makes sense I guess.

My guess is that this is due to a large number of DSL routers sold now having NTP servers in them to set their clocks. Even if the end users don't know they're using NTP (or WTF NTP is), they are. <snip> Are you aware that Windows XP (SP2 at least) enables NTP by default... Just a thought, James Butler, CHCH NZ

On Wed, 21 Feb 2007, Perry Lorier wrote:

...

Are you aware that Windows XP (SP2 at least) enables NTP by default...

yeah, windows enables it, I believe macos enables it, and I presume most linux distros do too[1]. If it's so prevalent then why don't we see 123/udp from all IP's then? Why do we only see things like port 80 + port 53 traffic on some IP's? Surely they should also be doing NTP?

The installed base of machines that are not running any flavour of XP, never mind XPSP2, is pretty significant. There are still 'net-connected computers out there running Win95! Prior to XP, Windows didn't come with an NTP app at all, AFAIK, and even the XP and (IIRC) XPSP1 shipped with it disabled by default. Most users don't care if their clock is out of sync, unless it's so far out that they actually notice. -- Matthew Poole "Don't use force. Get a bigger hammer."

The original poster was talking about a network with 24 million nodes on it. I think you'll find that many very large networks like this have already deployed IPv6, or are seriously looking at doing it within the next three years. -----Original Message-----

This only leaves IPv6 as the cheapest option.

That would explain the hordes rushing to deploy it then! Cheers, Jonny.

And not forgetting Vista being shipped with IPv6 being shipped enabled and preferred. Within three years there will be tens of millions of nodes wanting to use IPv6 over IPv4. -----Original Message----- From: Mike [mailto:mike(a)nzbox.com] Sent: Sunday, 18 February 2007 5:38 a.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] [Fwd: [pacnog] IPv4 exhaustion discussionsinAsiaPacific region] On Feb 16, 2007, at 8:38 PM, Philip D'Ath wrote:

-----Original Message-----

...

This only leaves IPv6 as the cheapest option.

That would explain the hordes rushing to deploy it then!

Apple would seem to think so..... There new Wireless basestation self configures 6 to 4 out of the box.... Mike

From: "Todd Woodward" Date: February 15, 2007 11:28:19 AM PST To: Subject: AirPort Extreme Firewall not filtering IPv6 by default?

According to an Infinite Loop article on Ars Technica, the AirPort Extreme base station (AEBS) firewall can reject "incoming sessions over IPv4" but "lets incoming IPv6 sessions straight through."

http://arstechnica.com/journals/apple.ars/2007/2/14/7063

The article discusses the issue and provides some potential workarounds.

I haven't used an AirPort base station since I worked for Apple 4 years ago, so any recent experience and commentary from those who have and use an AEBS is welcomed.

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Negative. We don't want to tunnel an IPSec tunnel mode connection inside of another tunnel UDP packet. This is only done to make it work through NAT, but is obviously less efficient. In a pure IPv6 world where every end point is uniquely addressed we may even be able to change over to using pure transport mode IPSec, since no tunnelling would be required to make it work at all. Lets not waste anymore time making protocols works through NAT. Lets start making them work with IPv6. -----Original Message----- From: Don Stokes [mailto:don(a)daedalus.co.nz] Sent: Sunday, 18 February 2007 4:28 p.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] [Fwd: [pacnog] IPv4 exhaustion discussionsin AsiaPacific region] Jonny Martin wrote:

So perhaps we reached a point where it should be considered bad form for one to design protocols that are not NAT friendly then?

Ugh. Like damn near every major VPN protocol. I notice though that IPSEC now has a UDP mode, which will work through any sensible NAT. Both ESP and AH needed to die ...

Jonny Martin wrote:

Wow, a few hours away from the internets, and this thread has run away!

Withdrawl symptoms starting to wear off now I hope? :)

On 18/02/2007, at 12:43 PM, Philip D'Ath wrote:

...

In a pure IPv6 world where every end point is uniquely addressed we may even be able to change over to using pure transport mode IPSec, since no tunnelling would be required to make it work at all.

Correct - assuming we get to that IPv6 world. And as is evident so far (which is over 10 years), we are still searching for the correct hammer to make sure this happens. And this point can't be argued as if we did have the correct [policy, technical, economic, vista-ical] hammer we would all be sitting here using IPv6 rather than talking about it.

And if we can't find the correct hammer then we better hurry and think through an alternative. A more efficient status quo _is_ a valid alternative.

Windows (an arguable large proportion of the hosts on the Internet) hasn't had IPv6 enabled by default until the release of Vista. Before then it's required obscure cli commands to activate. There doesn't appear to have been much point in doing v6 if a large chunk of your customers couldn't use it. Now they can.

I think you'll find people will start publishing their content so that it is available via IPv4 and IPv6. Then customers using both protocols will be able to access it. I highly doubt anyway will make their content available using just one transport version. -----Original Message----- From: Alastair Johnson [mailto:aj(a)sneep.net] ... Perry Lorier wrote: ... Ah, but now the reverse problem occurs: There's little to absolutely no v6 content. Who's going to want to publish their content on v6, when for the 99.9% of Vista v6 enabled PCs are going to have to reach it via 6to4 or ...

On 18-Feb-2007, at 01:08, Alastair Johnson wrote:

Philip D'Ath wrote:

...

I think you'll find people will start publishing their content so that it is available via IPv4 and IPv6. Then customers using both protocols will be able to access it. I highly doubt anyway will make their content available using just one transport version.

I think you completely missed the point I was trying to make: If v6 is suboptimal (the previously mentioned 6to4 anycast traffic hitting Europe, excessive RTTs, packet loss, etc), then why would anyone WANT to publish their content on v6 so that Vista-v6 customers, which will try v6 first, will get a substandard experience? Customers will complain, and go elsewhere.

Incidentally, running up a 6to4 relay on a dual stack cisco is trivial; it's about 15 lines of config. If we assume for a reason that there's at least one dual-stack network in New Zealand that has at least one dual-stack cisco in its network, then surely this is a trivial problem to solve.

(nb. I do encourage the wider deployment of 6to4 gates, but we have to be realistic here. This is a problem, and I'm sure that one of the first helpdesk troubleshooting steps is going to be, "disable v6")

If I could avoid one helpdesk call by pasting in a 6to4 relay config into a single cisco, I'd do it. Joe

Alastair Johnson wrote:

Perry Lorier wrote:

...

Windows (an arguable large proportion of the hosts on the Internet) hasn't had IPv6 enabled by default until the release of Vista. Before then it's required obscure cli commands to activate. There doesn't appear to have been much point in doing v6 if a large chunk of your customers couldn't use it. Now they can.

Ah, but now the reverse problem occurs: There's little to absolutely no v6 content.

Who's going to want to publish their content on v6, when for the 99.9% of Vista v6 enabled PCs are going to have to reach it via 6to4 or Teredo, over Anycast through Timbuktu? Users are now complaining that your site is slow, and your traffic drops, your revenue goes away, and your v6 experiment fails.

So one thing that Windows does[1], which I thought was extremely clever is look where replies come from and investigate (via a ping) to see if it can use the gateway in the reverse direction. eg: hostA sends a message to hostB via the 192.88.99.1 anycast gateway (GwA). hostB replies to hostA via a gateway local to hostB (GwB). hostA receives the v6 packet, with the v4 source address of GwB, and remembers GwB's address. hostA then "validates" GwB's address by sending itself an ICMPv6 ping via GwB. if HostA receives a reply then it will consider using GwB to talk to HostB as it presumably has a much more direct path. So the practical upshot of this is that if you put a 6to4/Teredo gateway in your datacenter,, even if you don't publically announce them into the global routing table, then 6to4/teredo routes from your servers will follow the same routes as v4. Presumably internal addressing works just as well for them. --- [1]: I'm not 100% sure of this, but I'm fairly this is true. Some of the details may be slightly incorrect.

I have noticed that v6-capable BitTorrent clients seem to have little problem finding other v6-capable peers. How much of your traffic currently is BitTorrent?

Interesting, where did you collect this data from? Which clients etc? My experience has been the complete opposite. Bittorrent clients tend to form a v4 or a v6 only swarm, but not a mixed v4/v6 swarm. I must admit I looked at this a couple of years ago and this may have significantly changed.

So perhaps we reached a point where it should be considered bad form for one to design protocols that are not NAT friendly then?

It's not hard to write a program that works well with NAT so long as the other end isn't also behind NAT. If /both/ ends are behind NAT it gets complicated. RFC 3459 classifies NAT's into 1 of 4 categories. Using the 4th category (Symmetric) it is impossible for two boxes both behind NAT to talk to each other without using an intermediate relay. You have to send "keep alives" to keep your "port forward" active, how often you send this extra (wasted) traffic is anyones guess. Many NAT boxes believe UDP is only used for DNS, and have timeouts appropriate for DNS queries or other protocols that don't have a large quiet times. Silence suppression on VoIP can be enough to break a NAT traversal. NAT traversal only really works for UDP. While in theory it is possible to do nat traversal with TCP, I've never head of it being practically used outside the lab. So if I have a "bulk transfer" program between two applications both behind NAT, the answer is it's effectively impossible (to my understanding). If what you're doing is "realtime" enough that you can use UDP with a straight face, then you can "mostly" get it right for NAT<->NAT boxes by using nat traversal techniques. Unless one end of them uses a Symmetric NAT. You can use UPnP and pray the users router is smart enough to deal with it. You could use "supernodes" (anyone running your program on a realworld IPv4) as proxies. But then who wants to be a supernode and have an increasing amount of traffic route through them? You could also use STUN as a proxy. How many STUN proxies are going to stick around if people keep using them as proxies tho? What happens if someone decides that since Nat traversal works with UDP so they start doing bulk transfers through UDP? Well, unless they fully implement congestion control without any glaring bugs, chances are the Internet would melt under congestion collapse. To me the only viable solution is to use IPv6 and require 6to4, Teredo or even a statically configured IPv6 over IP tunnel for NAT traversal. At least XP and Vista give this to me for free so I don't have to implement stuff to deal with all of this and the code I have to write and debug for this is minimal and easily tested.

Joe Abley wrote:

[Everybody here who wasn't configuring routers ten years ago please go find "Rise of the Stupid Network" by David S. Isenberg and read it twice before replying to that paragraph.]

http://www.rageboy.com/stupidnet.html Gerard

I can recommend the wired article to everyone. Be warned, takes about 20 minutes to read, but very amusing. ________________________________ From: Donovan Jones [mailto:hta.lists(a)gmail.com] Sent: Sunday, 18 February 2007 10:49 a.m. To: Gerard Creamer Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] [Fwd: [pacnog] IPv4 exhaustion discussionsin AsiaPacific region] http://www.rageboy.com/stupidnet.html And if you liked that try 'Netheads vs Bellheads' (from Wired October 1996) http://www.wired.com/wired/archive/4.10/atm_pr.html Donovan

Using the anycast addresses usually adds so much latency that it results in large parts of the IPv6 internet not being accessible. Hopefully we'll get a local 6to4 gateway anycast reachable in the near future. -----Original Message----- ... I've not played with vista directly, but I have experimented with 6to4 and Teredo. Both are reliant on decent anycast gateways, which would be fairly easy for ISP's to deploy within their networks. Which gateway we see from New Zealand often varies but it's not unusual for it to be in Europe somewhere which is likely to cause excessive latency increases to native IPv6 sites. Of course 6to4 to 6to4 and teredo to teredo routes follow the same route as the IPv4 Internet, and the overhead is precisely 20 bytes per packet.

On 17/02/2007, at 10:12 PM, Joe Abley wrote:

On 16-Feb-2007, at 17:00, Nathan Ward wrote:

...

End-to-end IP connectivity is so passe.

But it's arguably what allowed the Internet to grow and flourish. If the network controls the applications that users can deploy, then either the provider will be permanently playing catch-up, the user will be permanently disappointed, or (if the disease is sufficiently widespread) people will stop dreaming up new applications for users to run, and will instead concentrate on packages they can sell to carriers and ISPs. This all starts to sound a bit like the telco network.

Which is a problem if we are reliant on the telco's to move to IPv6. Why would any sane [NZ] telco spend serious money changing to a technology which further relegates them to a common bit pusher? There is an argument here that IPv4 exhaustion provides a technical rational for telcos to provide walled garden, proxy-style services. So if we want the Internet to further grow and flourish, we need to retain end to end connectivity, which means we need IPv6 (or some other solution providing similar outcomes), which means we need the telcos to play ball, or we need lots more independent infrastructure. Oh, and an economic incentive to do such :). At this stage I can't figure out a way forward, other than to get as many people playing with IPv6 as possible in the hope that it will actually become the transport of choice in the not so distant future. Alternatively, we accept our fate as one of multiple global IPv4 VRF tables and MPLS aware endpoints, using DNS trickery and multiple next hops to select between these meta-internets. (That is very tongue in cheek.) So post IPv6, what should be the scope of the 'global' routing table? As the internet keeps expanding, should we be striving for end to end connectivity for ever after? At some point it's likely to fracture - at what point should we accept it is inevitable? Perhaps having multiple IPv4 and IPv6 internets with re-used number space and some form of complex NAT on the boundaries between them isn't such a bad alternative. Cheers, Jonny.

Because we want native IPv6 transit. But people can start with [and will have to] by using tunnels. -----Original Message----- From: Joe Abley [mailto:jabley(a)ca.afilias.info] ...

Which is a problem if we are reliant on the telco's to move to IPv6.

Why are you reliant on the telcos to move to IPv6?

Because we need international transit. -----Original Message----- From: Donald Neal [mailto:Donald.Neal(a)telecom.co.nz] ...

Because we want native IPv6 transit. But people can start with [and will have to] by using tunnels.

...

-----Original Message----- From: Joe Abley [mailto:jabley(a)ca.afilias.info] ... Which is a problem if we are reliant on the telco's to move to IPv6.

Why are you reliant on the telcos to move to IPv6?

So if you're an ISP run IPv6 over a telco layer 2 access network and over peering links. Unless you can't find any demand for IPv6? :{)* ...

I've asked pretty much every single provider there is, and no one would sell it to me. -----Original Message----- From: Nathan Ward [mailto:nznog(a)daork.net] Sent: Monday, 19 February 2007 11:30 a.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] [Fwd: [pacnog] IPv4 exhaustion discussionsin Asia Pacific region] Philip D'Ath wrote:

Because we need international transit.

And what did your account manager at ANC/MCI/Sprint/GlobalGateway/(who else?) say when you asked if they could provide IPv6 services? ... or did you just assume that they couldn't? If they can't, there are other options to native international v6 transit right now - for example, get a [vendor] [mid-range router] and drop it overseas somewhere that /does/ provide native v6, and build a tunnel. If you're concerned about that negatively impacting RTTs, drop several. -- Nathan Ward _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Philip D'Ath wrote:

I've asked pretty much every single provider there is, and no one would sell it to me.

no one will sell it to you ? or no one will sell it to you at a price that meets your expectations ? -- Steve.

On Mon, 19 Feb 2007, Steve Phillips wrote:

Philip D'Ath wrote:

...

I've asked pretty much every single provider there is, and no one would sell it to me.

no one will sell it to you ? or no one will sell it to you at a price that meets your expectations ?

Deja vu! Before this argument goes around AGAIN please refer to the thread in this very list during Nov 2006 http://list.waikato.ac.nz/pipermail/nznog/2006-November/thread.html or http://list.waikato.ac.nz/pipermail/nznog/2006-November/date.html#12178 Discussion was started by Philip himself on Nov 28th with this message: http://list.waikato.ac.nz/pipermail/nznog/2006-November/012178.html His reply to the question above can probably be found here: http://list.waikato.ac.nz/pipermail/nznog/2006-November/012242.html and was further discussed/examined So we appear to be at a point where we think that a. IPv4 is exhausted, and b. Some say there are ways to solve the problem without going to IPv6, while, c. Others advocate IPv6 is the only way to solve the problem. Just out of curiousity... Has anyone advocated IPv6 for its own sake, perhaps as a new and exciting technology development, rather than as technology that has been developed to resolve the problem of running out of IPv4 address space? regards lin

Nathan Ward wrote:

Lin Nah wrote:

...

Just out of curiousity... Has anyone advocated IPv6 for its own sake, perhaps as a new and exciting technology development, rather than as technology that has been developed to resolve the problem of running out of IPv4 address space?

I think we all would, (except perhaps ATM-AJ) but as it's largely transparent to the end user, and doesn't really give them any tangible benefits right now, it's a hard sell to the bean counters.

Beyond that, does anyone really look at it as anything beyond a solution for v4 address shortages? It's never even been a consideration from anyone I've spoken to that v6 supports something "we need", except for larger addressing possibilities. I suspect the excitement in wheel reinventing may have allowed v6 to lose sight of doing something neat, like remaining compatible with v4, and allowing full adoption of ATM everywhere. aj. -- slightly tongue in cheek.

Beyond that, does anyone really look at it as anything beyond a solution for v4 address shortages? It's never even been a consideration from anyone I've spoken to that v6 supports something "we need", except for larger addressing possibilities.

I suspect the excitement in wheel reinventing may have allowed v6 to lose sight of doing something neat, like remaining compatible with v4, and allowing full adoption of ATM everywhere.

The "good bits" of v6 have mostly been rolled back into IPv4. For example IPSec, Link locals, Mobile IP have all been backported to IPv4 from the IPv6 specification with varying degrees of success. This is why they have weird limitations, because they were originally designed with v6 in mind. Mobile IP doesn't work because no v4 stack supports it properly, yet it's a requirement to be able say your stack supports IPv6. Also IPv6 doesn't have "IP options" as such, so you don't get your traffic filtered by ignorant middle boxes. IPSec doesn't interact nicely with NAT[1] because nobody ever considered that you'd need to NAT IPv6. Link locals work better with v6 because v6 is designed with interfaces having multiple addresses on an interface in mind, where as v4 has one IP per Interface. I'm sure there are other examples around that can be given of technologies that were originally developed for v6 and were deemed useful so they were backported to v4 even tho they didn't "fit" quite as nicely. ---- [1]: Yes, I know there are work arounds for this.

Why are you reliant on the telcos to move to IPv6?

Sure they could play the 6-to-4 game, but that just highlights one problem with v6: there no effective migration path from v4 to v6... Besides, 6-to-4 looks a lot like NAT, and it is almost universally agreed that NAT is teh suck In order to offer native v6 content, a content provider will need an upstream intartubes provider...but since there is no (effective) end-site multi-homing in IPv6, they can only pick one provider, so they have to hope that it is a good one [tm]... my $0.02 /joshua -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. - Douglas Adams -

joshua sahala wrote:

Sure they could play the 6-to-4 game, but that just highlights one problem with v6: there no effective migration path from v4 to v6... Besides, 6-to-4 looks a lot like NAT, and it is almost universally agreed that NAT is teh suck

Wait, what? I'm not sure that 6to4 is a lot like v4 NAT at all, which shares a single public address among many privately addressed machines. (by public and private, I don't mean RFC1918, necessarily) Instead, it gives you a way to get an IPv6 /48 per IPv4 public (in the RFC1918 sense) address, and a tunneling mechanism to get that host's v6 traffic to the `6-bone' and back. No hiding of your public v6 address takes place. If your router supports it, you can give each of your internal machines a 6to4 address. An effective migration path might be: 1) Get a v6 border+transit and/or a v6 capable Linux box+tunnels. 1.5) Don't forget to get to Citylink somehow. 2) Get your customers (who want them) v6 routers and configs. 3) Serve up a 6to4 relay to your customers, and have them configure their routers to use it. 3.5) Consider doing static tunnels with your publicly allocated IPv6 space from [RIR]. 4) When your access network can do v6, and you've got it all tested etc. turn it on, and if you didn't assign numbers in step 3.5, do so. 5) Profit (may not be applicable, but it always seems to come at the end of these type of lists) You can do steps 1-3 in less than a day, even a few hours. It doesn't require any knowledge of v6 really, you just need some tunnels to send IPv6 traffic out over (other 6to4 routers will be used for the return path, of course, it'll look just like IPv4:41 traffic to you). -- Nathan Ward

joshua sahala wrote:

...

An effective migration path might be: 1) Get a v6 border+transit and/or a v6 capable Linux box+tunnels.

as has been pointed out in another email here, there is no v6 provider offering services in NZ...so the connections will have to be tunneled: this means additional hardware, transit, and colo costs (and decreased performance)

Hardware? Until you really need that sort of capacity, you can go to places overseas and buy (for $x, where x is often 0) v6 tunnel endpoints. When your bandwidth requirements dictate that you need hardware to run your own tunnels to your own routers and peer at international IXs, you're probably in a position to get native v6 transport from your transit provider(s), because there will be enough content flowing over this IPv6 thing that world will be in a place where IPv6 is common enough that transit providers have it out of the lab.

...

1.5) Don't forget to get to Citylink somehow.

There's native v6 there? With (native) connectivity to the rest of the world? (I don't think so)

There is native v6 at the IXs (APE and WIX, anyway). You can use them to get to other NZ v6 capable hosts. TradeMe is a good example of an NZ host that might get some v6 space one day - they probably need to have a think about how Vista and friend might play if they did that, though.

...

2) Get your customers (who want them) v6 routers and configs.

You are making some very sweeping assumptions here: namely, that I am an intarwebs provider with customers. Perhaps I am a clueful content provider whose customers are someone else's end users (think YouTube or flickr)

So fortunately, as a content provider, I don't have to come up with the money to provide lots of hardware to anyone except myself... unfortunately, I can't get IPv6 space since I have no end users...DOH!!!

Most large content providers have their own ASNs, which to me suggests that they wouldn't have any problems getting IPv6 space to live on. See below for discussion about transit.

...

3) Serve up a 6to4 relay to your customers, and have them configure their routers to use it.

see above regarding my "customers"

presuming that I configure all of my content servers to use a 6-to-4 relay, local or remote doesn't really matter, performance is teh suck [tm] - the effective throughput of most tunnel servers/relays is a few-hundred Mbps (at best). This is wholly inadequate for a modern content network.

Why would you configure your large content network to use 6to4? 6to4 is really for people who can't get native transit.. I'd be surprised if YouTube were told "No" to "Can we have native IPv6 please". Of course, YouTube peers at a bunch of IXs, so they can just turn on v6 to those who will listen. Anyway, they're probably not going to turn it on until they have enough v6-eyeballs. So, be first, offer a nearly-solution to your customers, and break out of the chicken+egg, etc.

...

3.5) Consider doing static tunnels with your publicly allocated IPv6 space from [RIR].

still won't improve performance

I suspect it probably would in some cases, actually. The benefit here is that your customers get non-6to4 addresses, or can use the portable assignments that they have got from [RIR].

...

4) When your access network can do v6, and you've got it all tested etc. turn it on, and if you didn't assign numbers in step 3.5, do so.

see #2

...

5) Profit (may not be applicable, but it always seems to come at the end of these type of lists)

well, so far I have spent a lot of money on extra hardware for mediocre performance from a lot of mostly hand-maintained tunnels... so no profit, just a lot of additional CAPEX and OPEX

Perhaps, luckily 1-3 were talking about migration, not end goal, I'm pretty sure most migrations involve extra OPEX, at least. Once you've done 4 ofcourse, you've got native IPv6 to your customers, and you're all migrated and happy. What we're aiming for here is to get your network of mostly end users to have IPv6 connectivity. The YouTubes of the world can v6-ify when they're ready, and all they have to do to get there is to get v6 transport. (Discussed above)

...

You can do steps 1-3 in less than a day, even a few hours. It doesn't require any knowledge of v6 really, you just need some tunnels to send IPv6 traffic out over (other 6to4 routers will be used for the return path, of course, it'll look just like IPv4:41 traffic to you).

Whilst it is possible to set up a tunnel (or three), perhaps even over existing connectivity, 6-to-4 relays do not have the performance to support more than a moderate amount of traffic. So without native v6 services, I have little/no incentive to even try (ignoring the lack of multihoming).

Sure, luckily we're not talking about pushing large amounts of traffic. If you're a v6-enabled provider of either content or `Internet access' and performance becomes a problem, you can drop in your own 6to4 relay router. Or turn 6to4 relaying on on one, or all, of your routers (ie. no extra hardware). I hope I covered it all, but as I'm in a hurry to go check out apartments I might not have, so let me know and I'll fill in gaps. Cheers, -- Nathan Ward

Joe Abley wrote:

There are two working options for multi-homing in IPv6 today:

1. Obtain PI IPv6 space, and do what you do with IPv4 PI space. This option is open to all ISPs, per current APNIC policies. This doesn't apply to end-sites in the APNIC region, though (ARIN policies differ), which is what you're talking about. I mention it for completeness.

Fortunately, there is a policy proposal under action with APNIC right now to allow for /48 assignments for multihoming. http://www.apnic.net/docs/drafts/draft-ipv6-address-policy-v004.txt (in particular, section 5.8.1). http://www.apnic.net/docs/policy/proposals/prop-035-v002.html for the proposal status.

2. Take one PA assignment from each of your upstreams, assign an address from each of those PA blocks to each customer, and let the customers decide which address to use. This is the current IETF- blessed multihoming approach.

There work going on at the IETF to provide additional multihoming mechanisms, principally because operators were underwhelmed with (2) above, and because there are scaling concerns with (1). However, I don't think it's accurate to say that there's no effective end-site multi-homing in IPv6.

"Underwhelmed" is the polite way of putting it. aj.

Joe Abley wrote:

On 19-Feb-2007, at 18:06, Alastair Johnson wrote:

Interestingly, though, finding operators who can describe what is wrong with it beyond "that's not how we were taught things work" is quite difficult.

Well, as I recall, the idea behind using multiple provider address blocks for multihoming was that you would use dynamic configuration to figure out where you were in the world, and A6/DNAME DNS records to get services back to where you wanted to them go. A6 and DNAME have long since been consigned to the "too hard" basket. I think the problem is simply that no-one has really convincingly demonstrated that multihoming on different blocks is "nice", especially with DNS caching, connection caching etc. Multihoming on multiple addresses pushes a lot of the smarts onto the client (as opposed to doing it in the network), which rather increases the scope for things to go wrong. The thing is that IPv6 was seen as a chance to do everything over. Most of the promises have either fallen by the wayside or been layered on top of IPv4. The only thing that IPv6 really promises that can't be delivered with IPv4 is long addresses. Depressingly, the TUBA proposal (TCP and UDP over Big Addresses), which would have just replaced IP datagrams with OSI connectionless service datagrams, was dropped (along with a couple of other proposals) in favour of what became IPv6, OSI CLNS was widely implemented (albeit rarely deployed) at the time, and while the proposal needed some work, it could have delivered the needed long addresses much, much sooner. But of course religious wars, NIH and second system syndrome together put paid to that idea. (That and a complete disconnect between the people defining the protocol and the people who knew how to make routers switch packets fast; the former simply failed to believe that CLNS variable length addresses could be switched as fast as fixed length ones, while the latter knew damn well that they could.) -- don