Throw me a IPv6 bone (sort of was IPv6 ignorance)

Mailman List Mirror (Read Only)
1

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?

2

The IETF BCP is to deploy Dual Stack, thus both IPv4 and IPv6 at the
same time.

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

3

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?

This all depends on how your manage your last-mile and terminate users now. I have a friend with a local WISP here and he gives everyone a /24 out of 172.16/12 and dumps them through his load-balancer for his few connections. His "CGN" box seems to handle this fine.

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?

I would say you want to do dual-stack, but shift the users that don't *need* public IPs into 1918 space and deliver v6 native as feasible. If you have a server lan, you can do this with SLAAC, but to get the other information to your hosts, either via RA's and otherwise, it's just becoming easier to do.

PPPo* you can get IPv6 IPCP up and going, but the device has to support it.

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.

ASR1K and other devices can serve as nat64.. (I think Juniper does the same, but I don't recall their roadmap/product set). I'm sure you can do it with a Linux or *BSD box as well.

What is current best practice?

I would say there is none as it largely depends on how you terminate that transport, and there are a few ways one can do that.

Hope this helps,

- Jared

4

The folks that have done the most work in enabling IPv6-only end users seem
to be CERNET2 in China. To let people get to v4, they're using what they
call IVI (get it?), which is basically NAT64+DNS64.
<http://tools.ietf.org/html/rfc6219>
<http://en.wikipedia.org/wiki/NAT64>

If you don't mind running IPv4 in a tunnel over that IPv6 network, you can
do DSlite or 4rd
<http://tools.ietf.org/html/rfc6333>
<http://tools.ietf.org/html/draft-despres-intarea-4rd-01>
<
http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#Dual-Stack_Lite_.28DS-Lite.29

5

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

6

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.

Dual stack isn't all that hard to deploy in the enterprise, perhaps even IPv6 only with NAT for backward compatibility.

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.

7

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.

8

You *do* realize that the reason my site runs like 60% IPv6 traffic *now*
is because we spend the resources 5 and 10 years ago getting ready for
when Microsoft and Apple shipped stuff that worked for the end user, right?

Of course, if you want to wait to get *started* on the deployment curve
until everybody's replaced their stuff, that's fine by me. But I'd double-check
if you have any competitors that have an earlier schedule.

9

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.

10

But you have to admit it works a lot better if you're a customer of an ISP that
isn't waiting to spend the resources... :slight_smile:

11

Dhcpv6, radius .. take your pick

--srs (htc one x)

12

No. Use RFC 6598 space which was allocated for this purpose.

Mark

13

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

14

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.

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

nat64 is at my cpe border.

randy

15

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

16

* Randy Bush

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.

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

nat64 is at my cpe border.

Mark was asking about how to run IPv6-only to his subscribers. I don't
see how doing NAT64 in the CPE could possibly help him with that, as the
NAT64 function would require an IPv4 address for its outside interface.

17

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.

18

* Mark Radabaugh

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.

Okay. In this case I would pay very close attention to MAP/4RD. Here are
some drafts to get you started:

http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00
http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01
http://tools.ietf.org/html/draft-despres-softwire-4rd-u-06

There are different flavours, but as I understand it, the basic idea is
the same... You won't find shipping products today, but there will
probably be by the time you need it. Like DS-Lite, it assumes an
IPv6-only access network, with the CPE communicating with a centralised
component over IPv6 to provision IPv4 service for the subscriber's LAN.

Unlike DS-Lite, however, the central component does not perform NAT or
any other stateful translations - what it essentially does is to steal
bits from the TCP/UDP port space for routing, so (oversimplified)
subscriber A gets ports 2000-2999, B gets 3000-3999, and so forth. The
subscriber will be able to receive internet-initiated traffic to his
assigned port range. The NAT44 function in the CPE works pretty much
like today, except that it must ensure the source ports are rewritten to
fall inside its assigned range. You can also provision an �entire IPv4�
to a single CPE also, for example as a premium service.

The central component is operating in stateless mode, so it'll be easier
to scale than any centralised NAT, and you can also anycast it, load
balance between several instances using ECMP, and so on.

In my opinion, it looks like a much better approach than DS-Lite, both
for the subscriber and the service provider - as long as you can wait
for it a little while.

Best regards,

19

* 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-2012.pdf

Best regards,

20

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?

Cheers,

aid