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

[Rajiv Asati (rajiva)]

Adrian,

MAP facilitates both IPv6 deployment and IPv4 address exhaustion without
involving any CGN mess in the network. This allows the home networks to
stay dual-stack, use IPv6 as possible, and resort to IPv4 if IPv6 is not
feasible for the intended destinations.

One could promote the intent being that as more and more traffic goes over
IPv6, less and less IPv4 will be needed (thereby shrinking the reliance on
IPv4 ports sharing).

Note that MAP Translation mode (i.e. MAP-T) does not involve any
encapsulation, so, any QoS or Security or LI or DPI or Caching needing
access to Layer4 info (i.e. UDP/TCP ports) would work just fine anywhere
in the network. In case of MAP-E (Encapsulation mode), layer4 info (i.e.
UDP/TCP ports) is not available in the network (until at boundary of the
network where decapsulation is done).

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

Nope. The routers still follow the dynamic IPv4 and IPv6 routing for
packet forwarding. That is UNCHANGED.

The routers (expected to the boundary routers/ASBR, not the PE routers
connecting the users) must have to look at the ports for IPv4->IPv6
stateless translation. Once translated, routing lookup as usual.


> * A CE router being instructed to constrain itself to
> using a limited set of ports on the WAN side in its
> NAT44 implementation.

Indeed. And it is not much different from how it works today. Almost all
CPEs (I.e. Residential routers) work with limited set of ports (typically
2000) for dynamic NAT44 anyway. Of course, when MAP is enabled, the range
would no longer be the default (as is the case today), rather something
that is assigned using DHCP or TR069. That's in the control plane.


Cheers,
Rajiv

-Original Message-
From: "nanog-requ...@nanog.org" 
Reply-To: "nanog@nanog.org" 
Date: Tuesday, September 25, 2012 12:08 AM
To: "nanog@nanog.org" 
Subject: NANOG Digest, Vol 56, Issue 84

>Date: Mon, 24 Sep 2012 22:42:46 +0100
>From: Mike Jones 
>To: Adrian Bool 
>Cc: "nanog@nanog.org" 
>Subject: Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
>Message-ID:
>   
>Content-Type: text/plain; charset=UTF-8
>
>On 24 September 2012 21:11, Adrian Bool  wrote:
>>
>>On 24 Sep 2012, at 17:57, Tore Anderson
>> 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
>>>-2012.pdf
>>
>>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
>
>
>
>--
>
>Message: 3
>Date: Mon, 24 Sep 2012 23:34:30 +0100
>From: Adrian Bool 
>To: "nanog@nanog.org" 
>Subject: Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
>Message-ID: <8beebcda-b6fa-4407-bf95-e122b26f4...@logic.org.uk>
>Content-Type: text/plain; charset=us-ascii
>
>
>On 24 Sep 2012, at 22:42, Mike Jones  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.
>
>aid
>

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

[Tore Anderson]

* Adrian Bool
> 
> On 24 Sep 2012, at 22:42, Mike Jones  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

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

[Owen DeLong]

You can avoid the giant NAT box as long as you don't have to add a new customer 
for whom you don't have an available IPv4 address.

At that point, you either have to implement the giant NAT box for your future 
(and possibly an increasing percentage of your existing) customers, or, stop 
adding new customers.

In terms of the CPE situation, until you solve that, IPv6-only isn't going to 
work for them, either, so the CPE issues simply can't be avoided no matter 
what. We need to find a way to get the vendors to make that float.

Owen

On Sep 21, 2012, at 12:42 , Mark Radabaugh  wrote:

> On 9/21/12 9: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.
>> 
>> 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
>> 
> 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.
> 
> 
> -- 
> Mark Radabaugh
> Amplex
> 
> m...@amplex.net  419.837.5015
> 

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

[Adrian Bool]

On 24 Sep 2012, at 22:42, Mike Jones  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.

aid

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

[Mike Jones]

On 24 September 2012 21:11, Adrian Bool  wrote:
>
> On 24 Sep 2012, at 17:57, Tore Anderson  
> 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-2012.pdf
>
> 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

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

[Adrian Bool]

On 24 Sep 2012, at 17:57, Tore Anderson  
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-2012.pdf

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

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

[Tore Anderson]

* 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,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

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

[Tore Anderson]

* 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 <>, 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,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

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

[Mark Radabaugh]

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

m...@amplex.net  419.837.5015

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

[Tore Anderson]

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

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

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

[Mark Andrews]

In message , 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: ma...@isc.org

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

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

randy

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

[Tore Anderson]

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

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

[Mark Andrews]

On 22/09/2012, at 12:04 AM, Jared Mauch  wrote:

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

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

Mark

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

[Suresh Ramasubramanian]

Dhcpv6, radius .. take your pick

--srs (htc one x)
On Sep 21, 2012 7:04 PM, "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?
>
> --
> Mark Radabaugh
> Amplex
>
> m...@amplex.net  419.837.5015
>
>
>

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

[Valdis . Kletnieks]

On Fri, 21 Sep 2012 19:22:18 -0400, TJ said:
> > 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.

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



pgpUScnDkORu5.pgp
Description: PGP signature

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

[TJ]

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

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

[Valdis . Kletnieks]

On Fri, 21 Sep 2012 15:42:20 -0400, Mark Radabaugh said:

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

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.


pgpWeTzEVALKZ.pgp
Description: PGP signature

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

[Seth Mos]

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.

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

[Mark Radabaugh]

On 9/21/12 9: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.

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

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.



--
Mark Radabaugh
Amplex

m...@amplex.net  419.837.5015

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

[joel jaeggli]

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

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

[Richard Barnes]

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.



If you don't mind running IPv4 in a tunnel over that IPv6 network, you can
do DSlite or 4rd


<
http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#Dual-Stack_Lite_.28DS-Lite.29
>


On Friday, September 21, 2012, 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?
>
> --
> Mark Radabaugh
> Amplex
>
> m...@amplex.net  419.837.5015
>
>
>

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

[Jared Mauch]

On Sep 21, 2012, at 9:31 AM, 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?

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

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

[Jeroen Massar]

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.

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

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

[Mark Radabaugh]

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?

--
Mark Radabaugh
Amplex

m...@amplex.net  419.837.5015