On 9/21/12 6:40 AM, Jeroen Massar wrote:

On 2012-09-21 15:31 , Mark Radabaugh wrote:

...

The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction?

Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts?

The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly.

What is current best practice? The IETF BCP is to deploy Dual Stack, thus both IPv4 and IPv6 at the same time. That's likely to be congruent with the expectations of residential customers but it's not the sole model we've seen, at some point IPv4 backward compatibility plays second fiddle to your ipv6 deployment.

the alternatives do get discussed, e.g. http://tools.ietf.org/html/rfc6180

When that is not possible, as you ran out of IPv4 addresses, you should look at Dual Stack Lite (DS Lite) eg as supplied by ISC's AFTR and other such implementations.

Depending on your business model you can of course also stick everybody behind a huge NAT or require them to use HTTP proxies to get to the Internet as most people define it...

Do note that if you are asking any of these questions today you are years late in reading up and you missed your chance to be prepared for this in all kinds of ways.

Greets, Jeroen

Op 21-9-2012 21:42, Mark Radabaugh schreef:

Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. There is really very little point in spending a lot of resources on something the consumer can't currently use. I don't think saying we missed the boat really applies - and the consumer CPE ship is sinking at the dock.

Enable dual stack per default, the old routers ignore it anyhow. The new ones that do support it, and really, Linksys and D-Link as well as Netgear do support it now will use it and should just work. I recommend DHCP-PD, it seems to work well with relatively low overhead. AVM seems to know just how to make these relatively cheap all-in-ones with a great feature set and reasonable quality. There is a lot of room for improvement, there always have been. It's not like the original Linksys WRT54G was really _that_ good, was it? The other good news is that there is a new Wifi standard! You'll see a new surge of people swapping out 30$ routers because they are convinced that the new 30$ router will be a lot better then the previous one. Maybe it is. I know it's a chicken and egg problem, and shoving it out further means you just decided for the ISP that you need a far beefier CGN box in the future. I am not totally convinced that was your long term plan. Most ISPs in asia that are now pouring significant monetary resources into a CGN box that might be almost pointless in 5 years is not the investment they were looking for.

Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. There is really very little point in spending a lot of resources on something the consumer can't currently use.

Note: Some of us regular, residential customers can and do have native IPv6 at home ... off the shelf gear, default configs, etc.

* Mark Radabaugh

We can already do dual stack - that's not really a problem. I was really rather hoping to avoid the giant NAT box. I'll take a look at DS Lite and or NAT64/DNS64 and see if that makes any sense.

Both DS-Lite and NAT64 contain some form of a «giant NAT box» as part of the solution, I'm afraid. Same shit, different wrapping. You might want to look into MAP, which to the best of my knowledge is the only solution that facilitates IPv4 address sharing between subscribers without any form of (centralised) NAT.

Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart.

In that case, running IPv6-only to your subscribers isn't a realistic proposition at this point in time. Unfortunately. If you're running out of IPv4 addresses, you better try to get your hands on more of them, somehow, or start planning for the «giant NAT box» you're going to need. Alternatively, you could begin providing all your *new* subscribers with managed CPEs that support DS-Lite, MAP, NAT64/DNS64/464XLAT (or whichever other IPv4 life-support technology you end up choosing), while at the same time letting your old subscribers with their IPv4-only Walmart CPEs hang on to their public IPv4 address for as long as they need it. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/

In message <m28vc2fglk.wl%randy@psg.com>, Randy Bush writes:

...

Both DS-Lite and NAT64 contain some form of a =ABgiant NAT box=BB as part of the solution, I'm afraid. Same shit, different wrapping.

ds-lite is in the provider core. talk to the telco's lawyers when you want to use a new protocol.

DS-lite can be deployed between between customer and anyone that wants to provide IPv4 service for that customer. I would expect DS-lite to be out sourced by ISPs.

nat64 is at my cpe border.

randy

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On 9/22/12 4:03 AM, Tore Anderson wrote:

* Mark Radabaugh

...

We can already do dual stack - that's not really a problem. I was really rather hoping to avoid the giant NAT box. I'll take a look at DS Lite and or NAT64/DNS64 and see if that makes any sense. Both DS-Lite and NAT64 contain some form of a «giant NAT box» as part of the solution, I'm afraid. Same shit, different wrapping.

You might want to look into MAP, which to the best of my knowledge is the only solution that facilitates IPv4 address sharing between subscribers without any form of (centralised) NAT.

...

Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. In that case, running IPv6-only to your subscribers isn't a realistic proposition at this point in time. Unfortunately. If you're running out of IPv4 addresses, you better try to get your hands on more of them, somehow, or start planning for the «giant NAT box» you're going to need.

Alternatively, you could begin providing all your *new* subscribers with managed CPEs that support DS-Lite, MAP, NAT64/DNS64/464XLAT (or whichever other IPv4 life-support technology you end up choosing), while at the same time letting your old subscribers with their IPv4-only Walmart CPEs hang on to their public IPv4 address for as long as they need it.

Best regards,

Thanks for the help. We are actually in decent shape with respect to IPv4, probably at least 1 if not 2 years at current growth rate. We can deliver dual stack with public IPv4/6 to customers now. This is the planning stage for <<giant NAT box>>, assuming there are no better options. We are starting to provide some customers with managed CPE and your alternative suggestion may be the way to go. There are several other business/management/support advantages to Amplex supplying the CPE. This may be reason enough to expand that program. I didn't really think we would be able to run IPv6 only in the near future but wanted to make sure I wasn't missing something obvious. -- Mark Radabaugh Amplex mark@amplex.net 419.837.5015

* Tore Anderson

I would pay very close attention to MAP/4RD.

FYI, Mark Townsley had a great presentation about MAP at RIPE65 today, it's 35 minutes you won't regret spending: https://ripe65.ripe.net/archives/video/5 https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24-201... Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/

On 24 September 2012 21:11, Adrian Bool <aid@logic.org.uk> wrote:

On 24 Sep 2012, at 17:57, Tore Anderson <tore.anderson@redpill-linpro.com> wrote:

...

* Tore Anderson

...

I would pay very close attention to MAP/4RD.

FYI, Mark Townsley had a great presentation about MAP at RIPE65 today, it's 35 minutes you won't regret spending:

https://ripe65.ripe.net/archives/video/5 https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24-201...

Interesting video; thanks for posting the link.

This does seem a strange proposal though. My understanding from the video is that it is a technology to help not with the deployment of IPv6 but with the scarcity of IPv4 addresses. In summary; it simply allows a number of users (e.g. 1024) to share a single public IPv4 address.

My feeling is therefore, why are the IPv4 packets to/from the end user being either encapsulated or translated into IPv6 - why do they not simply remain as IPv4 packets?

If the data is kept as IPv4, this seems to come down to just two changes,

* The ISP's router to which the user connects being able to route packets on routes that go beyond the IP address and into the port number field of TCP/UDP. * A CE router being instructed to constrain itself to using a limited set of ports on the WAN side in its NAT44 implementation.

Why all the IPv6 shenanigans complicating matters?

While you could do something similar without the encapsulation this would require that every router on your network support routing on port numbers, by using IPv6 packets it can be routed around your network by existing routers. And it's not like anyone is going to be deploying such a system without also deploying IPv6, so it's not adding any additional requirements doing it that way. - Mike

* Adrian Bool

On 24 Sep 2012, at 22:42, Mike Jones <mike@mikejones.in> wrote:

...

While you could do something similar without the encapsulation this would require that every router on your network support routing on port numbers,

Well, not really. As the video pointed out, the system was designed to leverage hierarchy to reduce routing complexity. Using the hierarchy, port number routing is only required at the level where a routes diverge on a port basis - which if you're being sensible about such a deployment would only be at the edge of the access layer.

While that might be true, the access network would normally be the largest part of an SP's network, when it comes to router count. The access part might have 100s or 1000s of times more routers than the core/border. The cone gets wider the closer to the customer edge you get. Slide 6 illustrates this well. By not doing translation or encapsulation of the IPv4 packets, instead relying on the access routers to natively route based on A+P, we would have made sure that the ISPs that have already deployed IPv6 could not use the technology, and that ISPs that have not yet deployed IPv6 and think the technology looks interesting have a huge incentive to put off the entire project for several years, while they wait for new router products or software images that support A+P to be made available. Not exactly desirable. There are also other problems with the idea - not only do you need the router to be able to forward based on A+P, you would also need to distribute these A+P routes in the network. Which means we would need to update OSPFv2, IS-IS, or whatever else the SP might be using. We would have to update DHCPv4 (both the protocol and the SP's server) too, as there is currently no way it can give you a lease for a "partial" IPv4 address. This would also touch on layer 2 devices doing layer 3 inspection and policing, such as DHCP Snooping. You'd also need to update ARP, as there is currently no way to send an "ARP who-has 192.0.2.1 port 1234" request, which you would have to do. The amount of changes required is so large that you might as well call the result IPv4½ instead of MAP. Finally, operating a single-stack network (regardless of that single stack being IPv4 or IPv6) is much preferable to operating a dual-stack one. Less complexity, less things to trouble-shoot, less things to set up, less things to monitor, less things to train staff in, and so forth. That MAP (and DS-Lite) means single-stack IPv6 in the vast majority of the network is a very desirable trait, in my opinion. Your proposal would remove this benefit, instead we'd end up with a dual-stack IPv4½/IPv6 network. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com