subject:"Verizon DSL moving to CGN"


On Sun, 7 Apr 2013, Owen DeLong wrote:

I don't disagree. You are actually making the exact point I was 
attempting to make. The need for CGN is not divorced from the failure to 
deploy IPv6, it is caused by it.


Absolutely. That doesn't mean that any individual ISP right now can choose 
to *not* implement CGN and deploy IPv6. That won't solve IPv4 address 
depletion *for that ISP*.


This is an industry-wide failure that no individual part of the industry 
can work around. For most ISPs, deploying some kind of CGN is the only 
rational decision at this time.


We can discuss what could have should have happened earlier, but now we're 
here. Yes, ISPs should deploy IPv6. Everybody should deploy IPv6.


But I still believe that CGN is mostly orthogonal to IPv6 deployment. 
Saying ISPs today are wrong to deploy CGN and that they should deploy IPv6 
(the word instead is usually not there, but it still seems to be 
implied), I just don't understand that argument.


Is it just that the ISP in question hasn't announced their IPv6 plans in 
the same announcement that is the problem? So that people believe CGN is 
part of a future-proof strategy?


So if the ISP says we're going to deploy CGN for select customers during 
2H-2013 due to IPv4 run-out, and at the same time we're planning to start 
rolling out IPv6 for customers who have upgradable equipment, does that 
help? If the ISP has been around for a while, it's still a huge part of 
the customer base that won't be upgradable, and those customers will be 
stuck behind NAT444 until they do something.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Verizon DSL moving to CGN

* Owen DeLong

 The need for CGN is not divorced from the failure to deploy IPv6, it
 is caused by it.

In a historical context, this is true enough. If we had accomplished
ubiquitous IPv6 deployment ten years ago, there would be no IPv4
depletion, and there would be no CGN. However, that ship has sailed long
ago. You're using present tense where you should have used past.

 I was responding to Mikael's claim that pushing content providers to
 deploy IPv6 was orthogonal to the need for CGN.

If we put down the history books and focus on today's operational
realities, it *is* orthogonal. If you're an ISP fresh out of IPv4
addresses today, pushing content providers to deploy IPv6 is simply
not a realistic strategy to deal with it. CGN is.

 Clearly your statement here indicates that you see my point that it
 is NOT orthogonal, but, in fact the failure of content providers to
 deploy IPv6 _IS_ the driving cause for CGN.

I'm not sure why you are singling out content providers, BTW. There are
no shortage of other things out there that have an absolute hard
requirement on IPv4 to function properly. Gaming consoles, Android
phones and tables, iOS phones and tablets[1], home gateways, software
and apps, embedded devices, ... - the list goes on and on.

If the only missing piece of the puzzle was the lack of IPv6 support at
the content providers' side, IPv6+NAT64 would constitute a perfectly
viable residential/cellular internet service. As far as I know, however,
not a single provider is seriously considering this strategy going
forward. That's telling.

Tore

[1] From what I hear, anyway. They used to work fine on IPv6-only
wireless networks, I've seen it myself, but I've been told that it's
taken a turn for the worse over the course of the last year.

Re: Verizon DSL moving to CGN


On Apr 7, 2013, at 23:27 , Tore Anderson t...@fud.no wrote:

 * Owen DeLong
 
 The need for CGN is not divorced from the failure to deploy IPv6, it
 is caused by it.
 
 In a historical context, this is true enough. If we had accomplished
 ubiquitous IPv6 deployment ten years ago, there would be no IPv4
 depletion, and there would be no CGN. However, that ship has sailed long
 ago. You're using present tense where you should have used past.
 

Respectfully, I disagree. If the major content providers were to deploy
IPv6 within the next 6 months (pretty achievable even now), then the
need for CGN would at least be very much reduced, if not virtually
eliminated.

 I was responding to Mikael's claim that pushing content providers to
 deploy IPv6 was orthogonal to the need for CGN.
 
 If we put down the history books and focus on today's operational
 realities, it *is* orthogonal. If you're an ISP fresh out of IPv4
 addresses today, pushing content providers to deploy IPv6 is simply
 not a realistic strategy to deal with it. CGN is.
 

This does not represent a reason to stop pushing content providers. While
CGN may be a necessary stop-gap measure today for some, there are
many more who aren't facing that decision for a few months. Even for those
that do have to deploy it, the reality is that CGN is fragile, unwieldy, 
expensive,
and high-maintenance. Further, it provides a lousy customer experience.

The less you have to depend on CGN as an ISP, the better your life will be.

As such, it is even more vital today than it was in history to keep the pressure
for IPv6 content strong.

 Clearly your statement here indicates that you see my point that it
 is NOT orthogonal, but, in fact the failure of content providers to
 deploy IPv6 _IS_ the driving cause for CGN.
 
 I'm not sure why you are singling out content providers, BTW. There are
 no shortage of other things out there that have an absolute hard
 requirement on IPv4 to function properly. Gaming consoles, Android
 phones and tables, iOS phones and tablets[1], home gateways, software
 and apps, embedded devices, ... - the list goes on and on.

All of those things are actually driven primarily by content. iOS phones and
tables are perfectly capable of IPv6 where IPv6 is available over WiFi.
iPhone 5 can do IPv6 over the carrier network. I know, my iPhone 5 works
great with IPv6 on its network. Home gateways are going to need to be
replaced. There are plenty of them that do support IPv6.

Gaming consoles are entirely under the control of content providers.
Most of the embedded devices are either going to need to be replaced
over time, upgraded, or we're going to need some form of set-top box
to deal with them in the future.

Bottom line, content providers are the low-hanging fruit in terms of the
easiest and fastest way to have the biggest impact in reducing the need
for and load on CGN deployments.

 If the only missing piece of the puzzle was the lack of IPv6 support at
 the content providers' side, IPv6+NAT64 would constitute a perfectly
 viable residential/cellular internet service. As far as I know, however,
 not a single provider is seriously considering this strategy going
 forward. That's telling.

It's not the only piece, just the easiest one to solve immediately with the
biggest payoff.

 
 Tore
 
 [1] From what I hear, anyway. They used to work fine on IPv6-only
 wireless networks, I've seen it myself, but I've been told that it's
 taken a turn for the worse over the course of the last year.

Actually it took a brief turn for the worse due to a bug which has now
been (partially) resolved. Apparently the phones used to prefer
IPv6 over carrier if they were on a wireless v4-only network which
ran up some (startling) data charges for some users.

Now they've made it so that if you have a wifi connection, you simply
won't use the cellular network no matter what. This unfortunately means
that you cannot surf an IPv6-only site while you are connected to an
IPv4-only wifi network even if you have dual-stack carrier connectivity,
but I think that's a reasonable tradeoff for now.

Prior to this latest software/carrier settings update, they had simply turned
off IPv6 on the carrier side, but the wifi side has always worked since
one of the later versions of IOS4 or one of the earlier versions of IOS5,
I forget which.

Owen

Re: Verizon DSL moving to CGN

2013-04-08 Thread Simon Lockhart

On Mon Apr 08, 2013 at 01:41:34AM -0700, Owen DeLong wrote:
 Respectfully, I disagree. If the major content providers were to deploy
 IPv6 within the next 6 months (pretty achievable even now), then the
 need for CGN would at least be very much reduced, if not virtually
 eliminated.

Surely the case is that you've still got the same number of users who need an
IPv4 address to be able to access legacy IPv4 sites on the Internet - until
100% of content is accessible via IPv6.

What it does, however, change is the amount of traffic which would need to 
flow through a CGN box.

Unfortunately, CGN is here until either everything is available over IPv6, or
a better version of NAT64 which doesn't depend on DNS rewriting is designed
and deployed.

Simon

Re: Verizon DSL moving to CGN

2013-04-08 Thread Arturo Servin



On 4/8/13 9:41 AM, Owen DeLong wrote:
 On Apr 7, 2013, at 23:27 , Tore Anderson t...@fud.no wrote:
 
  * Owen DeLong
  
  The need for CGN is not divorced from the failure to deploy IPv6, it
  is caused by it.
  
  In a historical context, this is true enough. If we had accomplished
  ubiquitous IPv6 deployment ten years ago, there would be no IPv4
  depletion, and there would be no CGN. However, that ship has sailed long
  ago. You're using present tense where you should have used past.
  
 Respectfully, I disagree. If the major content providers were to deploy
 IPv6 within the next 6 months (pretty achievable even now), then the
 need for CGN would at least be very much reduced, if not virtually
 eliminated.
 


I though that they have done it last year around June 8th.  ;-)

In fact, the need for CGN has been reduced if you count that 30-40% of
your traffic would go to those places. Although CGN is going to be a
necessary evil, deploying CGN without IPv6 would be a mistake IMHO.

/as

Re: Verizon DSL moving to CGN


On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote:

Thankfully, MAP is not CGN. Correctly stated, unlike DS-Lite, MAP 
doesn't require any CGN that causes the SP network to put up with the 
NAT state. This means that all the subsequent issues of CGN/DS-Lite no 
longer apply.


For me as an operator, MAP is most likely going to be implemented in a 
CGN-like box. Yes, it's stateless. Doesn't matter, I still need to flow 
traffic through a dedicated box because MAP won't be implemented in my 
regular routers (if you know otherwise, please speak up).


MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled 
access. MAP makes much more sense in any SP network having its internet 
customers do IPv4 address sharing and embrace IPv6.


It's still NAT.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Verizon DSL moving to CGN

* Mikael Abrahamsson

 On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote:
 
 MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled
 access. MAP makes much more sense in any SP network having its
 internet customers do IPv4 address sharing and embrace IPv6.
 
 It's still NAT.

AIUI, the standards-track flavour of MAP, MAP-E, is *not* NAT - it is
tunneling, pure encap/decap plus a clever way to calculate the outer
IPv6 src/dst addresses from the inner IPv4 addresses and ports. The
inner IPv4 packets are not modified by the centralised MAP tunneling
routers, so there is no Network Address Translation being performed.

The tunnel endpoint will 99.99% of cases be a CPE with a NAPT44
component though, so there is some NAT involved in the overall solution,
but it's pretty much the same as what we have in today's CPEs/HGWs. The
only significant difference is that a MAP CPE must be prepared to not
being able to use all the 65536 source ports.

Tore

Re: Verizon DSL moving to CGN

* Owen DeLong

 Respectfully, I disagree. If the major content providers were to deploy
 IPv6 within the next 6 months (pretty achievable even now), then the
 need for CGN would at least be very much reduced, if not virtually
 eliminated.

I agree with very much reduced. However, and IMHO, virtually
eliminated is completely unrealistic.

 The less you have to depend on CGN as an ISP, the better your life will be.
 
 As such, it is even more vital today than it was in history to keep the 
 pressure
 for IPv6 content strong.
[...]
 Bottom line, content providers are the low-hanging fruit in terms of the
 easiest and fastest way to have the biggest impact in reducing the need
 for and load on CGN deployments.
 
 If the only missing piece of the puzzle was the lack of IPv6 support at
 the content providers' side, IPv6+NAT64 would constitute a perfectly
 viable residential/cellular internet service. As far as I know, however,
 not a single provider is seriously considering this strategy going
 forward. That's telling.
 
 It's not the only piece, just the easiest one to solve immediately with the
 biggest payoff.

I agree fully that the continued deployment of IPv6 on the content side
and all other places is a benefit to any ISP that is providing IPv6 to
their subscribers alongside CGN. The payoff is reduced customer
unhappiness due to the effects of CGN, and reducing the amount of
investment in CGN necessary.

But the payoff is not going to be avoiding to have to implement CGN (or
similar IPv4 life-support mechanisms, including MAP) in the first place,
no matter how hard one pushes for IPv6. In order for that that to be the
case, *all* the missing pieces must fall in place, not only the
biggest/easiest ones -  and there's simply too many small and tricky
ones left, and too little time. I cannot see any realistic outcome of
the ordeal we're currently in that does not include CGN or similar stuff
to handle the long tail of IPv4-only stuff. It's simply too late for
IPv6 to prevent CGN.

I'd be absolutely delighted, though, if I'm wrong and you're able to say
to me a few years from now «I told you so»! :-)

Tore

Re: Verizon DSL moving to CGN


On Mon, 8 Apr 2013, Tore Anderson wrote:


* Mikael Abrahamsson


On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote:


MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled
access. MAP makes much more sense in any SP network having its
internet customers do IPv4 address sharing and embrace IPv6.


It's still NAT.


AIUI, the standards-track flavour of MAP, MAP-E, is *not* NAT - it is
tunneling, pure encap/decap plus a clever way to calculate the outer
IPv6 src/dst addresses from the inner IPv4 addresses and ports. The
inner IPv4 packets are not modified by the centralised MAP tunneling
routers, so there is no Network Address Translation being performed.


This is all splitting hairs. Yes, the outside port addresses do not change 
but however the src/dst addresses change (=translated), right? Does anyone 
see MAP-E being implemented on regular linecards or is it going to be 
implemented on processor based dedicated hardware? At least initially, I 
would just assume it's going to be some kind of CGN blade.


The tunnel endpoint will 99.99% of cases be a CPE with a NAPT44 
component though, so there is some NAT involved in the overall solution, 
but it's pretty much the same as what we have in today's CPEs/HGWs. The 
only significant difference is that a MAP CPE must be prepared to not 
being able to use all the 65536 source ports.


Yes, MAP-E needs CPE support, thus hard to deploy short term. Long term, 
yes, really nice. Perfect for long tail IPv4 reachability over IPv6 access 
networks.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Verizon DSL moving to CGN

* Mikael Abrahamsson

 On Mon, 8 Apr 2013, Tore Anderson wrote:
 
 AIUI, the standards-track flavour of MAP, MAP-E, is *not* NAT - it is
 tunneling, pure encap/decap plus a clever way to calculate the outer
 IPv6 src/dst addresses from the inner IPv4 addresses and ports. The
 inner IPv4 packets are not modified by the centralised MAP tunneling
 routers, so there is no Network Address Translation being performed.
 
 This is all splitting hairs. Yes, the outside port addresses do not
 change but however the src/dst addresses change (=translated), right?

There is no outside port addresses. The Next Header field in the outside
IPv6 header is set to 4 (i.e., what follows next is an IPv4 header).
This inner IPv4 header (and the payload following it) is the original
one and completely unmodified and not translated/rewritten in any way by
the ISP's MAP gateway. AIUI, anyway.

So unless you mean that the src/dst address change or are translated
due to the addresses in the outer IPv6 header are not the same as in the
inner IPv4 header, there is simply is no translation happening here.

If this is to be called translation, then any tunneling mechanism that
works by stacking layer-3 headers, including GRE, IPIP, ESP, and
proto-41, must be also called translation.

 Does anyone see MAP-E being implemented on regular linecards or is it
 going to be implemented on processor based dedicated hardware? At least
 initially, I would just assume it's going to be some kind of CGN blade.

No idea, sorry.

Tore

Re: Verizon DSL moving to CGN

* Tore Anderson

 Does anyone see MAP-E being implemented on regular linecards or is it
 going to be implemented on processor based dedicated hardware? At least
 initially, I would just assume it's going to be some kind of CGN blade.
 
 No idea, sorry.

https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24-2012.pdf
slide 15:

«Processed inline with normal IP traffic (at least on Cisco’s ASR9K)»

Tore

Re: Verizon DSL moving to CGN


On Mon, 8 Apr 2013, Tore Anderson wrote:

If this is to be called translation, then any tunneling mechanism that 
works by stacking layer-3 headers, including GRE, IPIP, ESP, and 
proto-41, must be also called translation.


Oki, my bad. I read 
https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24-2012.pdf 
and obviously didn't understand. I thought only the payload was 
encapsulated, not the complete IPv4 packet. It said replace IPv4 header 
with IPv6 header and I missed that this was for MAP-T, not MAP-E).


Thanks for explaining. I understand why MAP-E is not translation now.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Verizon DSL moving to CGN

* Tore Anderson

 The tunnel endpoint will 99.99% of cases be a CPE with a NAPT44
 component though, so there is some NAT involved in the overall solution,
 but it's pretty much the same as what we have in today's CPEs/HGWs. The
 only significant difference is that a MAP CPE must be prepared to not
 being able to use all the 65536 source ports.

BTW. It is AIUI quite possible with MAP to provision a whole IPv4
address or even a prefix to the subscriber, thus also taking away the
need for [srcport-restricted] NAPT44 in the CPE.

I find that the easiest way to visualise MAP is to take the 16 bits of
TCP/UDP port space, and bolt it onto the end of the 32 bits of the IPv4
address space, for a total of 48 routable bits. So while the primary
use case for MAP is to provision less than 32 bits to the individual
customers (say a /34 - 4 subscribers per IPv4 address w/16k ports
each), you can also give out a whole /32 or a /24 or whatever -
perhaps only to the customers that are willing to pay for the privilege.

I haven't tested, but I believe that if you were to hook up a standard
Linux box to a ISP that provides /32 or shorter over MAP, you don't
really need any special MAP support in the IP stack to make it go -
you'd have to calculate the addresses to be used yourself, but once
you've got them, you could just configure everything using standard ip
tunnel/address commands.

It's quite neat, I think. :-)

Tore

Re: Verizon DSL moving to CGN

2013-04-08 Thread Jack Bates


On 4/8/2013 7:20 AM, Tore Anderson wrote:

BTW. It is AIUI quite possible with MAP to provision a whole IPv4
address or even a prefix to the subscriber, thus also taking away the
need for [srcport-restricted] NAPT44 in the CPE.


The problem is NAPT44 in the CPE isn't enough. We are reaching the point 
that 1 IPv4 Address per customer won't accommodate user bases.


The larger issue I think with MAP is CPE support requirements. There are 
ISP layouts that use bridging instead of CPE routers (which was a long 
term design to support IPv6 without CPE replacements years later). CGN 
will handle the IPv4 issues in this setup just fine. Then there are 
those who have already deployed IPv6 capable CPEs with PPP or DHCP in a 
router configuration which does not have MAP support. Given the variety 
of CPE vendors that end up getting deployed over a longer period of 
time, it is easier and more cost effective to deploy CGN than try and 
replace all the CPEs.


Given US$35/CPE, cost for replacements (not including deployment costs) 
for 20k users is US$700k. CGN gear suddenly doesn't seem so costly.


The only way I see it justifiable is if you haven't had IPv6 deployment 
in mind yet and you are having to replace every CPE for IPv6 support 
anyways, you might go with a MAPS/IPv6 aware CPE which the customer pays 
for if they wish IPv6 connectivity(or during whatever slow trickle 
replacement methods you utilize). While waiting for the slow rollout, 
CGN would be an interim cost that would be acceptable. I'm not sure 
there is a reason for MAPS if you've already deployed CGN, though.


I am sure Verizon did a lot of cost analysis.

Jack

Re: Verizon DSL moving to CGN

2013-04-08 Thread Randy Bush

 I understand why MAP-E is not translation now.

so far, the sexiest implementation of statless a+p to date.

randy

Re: Verizon DSL moving to CGN

2013-04-08 Thread Leo Bicknell

In a message written on Mon, Apr 08, 2013 at 01:41:34AM -0700, Owen DeLong 
wrote:
 Respectfully, I disagree. If the major content providers were to deploy
 IPv6 within the next 6 months (pretty achievable even now), then the
 need for CGN would at least be very much reduced, if not virtually
 eliminated.

I'm going to disagree, because the tail here I think is quite long.

Owen is spot on when looking at the percentage of bits moved across
the network.  I suspect if the top 20 CDN's were to IPv6 enable
_everything_ that 50-90% of the bits in most networks would be moved
over native IPv6, depending on the exact mix of traffic in the
network.

However, CDN's are a _very_ small part of the address space.  I'd
be surprised if the top 20 CDN's had 0.01% of all IPv4 space.  That
leaves a lot of hosts that need to be upgraded.  There's a lot of
people who buy a $9.95/month VPS to host their personal blog read
by 20 people who don't know anything about IPv4 or IPv6 but want
to be able to reach their site.  The traffic level may be
non-interesting, but they will be quite unhappy without a CGN
solution.

Moving the CDN's to IPv6 native has the potential to save the access
providers a TON of money on CGN hardware, due to the bandwidth
involved.  However those access providers still have to do CGN,
otherwise their NOC's will be innondated with complaints about the
inability to reach a bunch of small sites for a long period of time.

If I were deploying CGN, I would be exerting any leverage I had on CDN's
to go native IPv6.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgp2htLLgGzH1.pgp
Description: PGP signature

Re: Verizon DSL moving to CGN

2013-04-08 Thread joel jaeggli


On 4/8/13 7:23 AM, Jack Bates wrote:

On 4/8/2013 7:20 AM, Tore Anderson wrote:

BTW. It is AIUI quite possible with MAP to provision a whole IPv4
address or even a prefix to the subscriber, thus also taking away the
need for [srcport-restricted] NAPT44 in the CPE.


The problem is NAPT44 in the CPE isn't enough. We are reaching the 
point that 1 IPv4 Address per customer won't accommodate user bases.


That happened a long time ago. I realize the people like to think of 
wireless providers as different, they really aren't. A big chuck of our 
mobile gaming customers come to us via carrier operated nat translators. 
Some of them now come to us via ipv6, most do not.
The larger issue I think with MAP is CPE support requirements. There 
are ISP layouts that use bridging instead of CPE routers (which was a 
long term design to support IPv6 without CPE replacements years 
later). CGN will handle the IPv4 issues in this setup just fine. Then 
there are those who have already deployed IPv6 capable CPEs with PPP 
or DHCP in a router configuration which does not have MAP support. 
Given the variety of CPE vendors that end up getting deployed over a 
longer period of time, it is easier and more cost effective to deploy 
CGN than try and replace all the CPEs.


Given US$35/CPE, cost for replacements (not including deployment 
costs) for 20k users is US$700k. CGN gear suddenly doesn't seem so 
costly.


The only way I see it justifiable is if you haven't had IPv6 
deployment in mind yet and you are having to replace every CPE for 
IPv6 support anyways, you might go with a MAPS/IPv6 aware CPE which 
the customer pays for if they wish IPv6 connectivity(or during 
whatever slow trickle replacement methods you utilize). While waiting 
for the slow rollout, CGN would be an interim cost that would be 
acceptable. I'm not sure there is a reason for MAPS if you've already 
deployed CGN, though.


I am sure Verizon did a lot of cost analysis.

Jack

Re: Verizon DSL moving to CGN

2013-04-08 Thread Jack Bates


On 4/8/2013 9:58 AM, joel jaeggli wrote:
That happened a long time ago. I realize the people like to think of 
wireless providers as different, they really aren't. A big chuck of 
our mobile gaming customers come to us via carrier operated nat 
translators. Some of them now come to us via ipv6, most do not.


Yeah, forgive me. I have a tendency to forget the mobile carriers, 
probably because some of them started with CGN. One of my customers just 
started a new cell network. He's burning through /20's like they are 
nothing in a short time frame (and it's a small geographic area). 
They're deploying CGN so we don't run out of addresses and can recover 
what we've already burned through. IPv6 for their cellular didn't seem 
high priority either.



Jack

Indeed MAP-E requires CPE replacement/upgrade cost.
But I would like to share JANOG Softwire WG Activity.
http://conference.apnic.net/__data/assets/pdf_file/0005/58856/apnic35-janog-softwire_1361559276.pdf

MAP-E already supported by 6 vendors,7 implementations.
It includes 2 open source(OpenWRT and ASAMAP) and 2 kernel(Linux 2.6.18 and
NetBSD 4.0.1).

Regards,
Shishio

(2013/04/08 23:23), Jack Bates wrote:
On 4/8/2013 7:20 AM, Tore Anderson wrote:
BTW. It is AIUI quite possible with MAP to provision a whole IPv4
address or even a prefix to the subscriber, thus also taking away the
need for [srcport-restricted] NAPT44 in the CPE.

The problem is NAPT44 in the CPE isn't enough. We are reaching the point that
1 IPv4 Address per customer won't accommodate user bases.

The larger issue I think with MAP is CPE support requirements. There are ISP
layouts that use bridging instead of CPE routers (which was a long term
design to support IPv6 without CPE replacements years later). CGN will handle
the IPv4 issues in this setup just fine. Then there are those who have
already deployed IPv6 capable CPEs with PPP or DHCP in a router configuration
which does not have MAP support. Given the variety of CPE vendors that end up
getting deployed over a longer period of time, it is easier and more cost
effective to deploy CGN than try and replace all the CPEs.

Given US$35/CPE, cost for replacements (not including deployment costs) for
20k users is US$700k. CGN gear suddenly doesn't seem so costly.

The only way I see it justifiable is if you haven't had IPv6 deployment in
mind yet and you are having to replace every CPE for IPv6 support anyways,
you might go with a MAPS/IPv6 aware CPE which the customer pays for if they
wish IPv6 connectivity(or during whatever slow trickle replacement methods
you utilize). While waiting for the slow rollout, CGN would be an interim
cost that would be acceptable. I'm not sure there is a reason for MAPS if
you've already deployed CGN, though.

I am sure Verizon did a lot of cost analysis.

Jack

RE: Verizon DSL moving to CGN

2013-04-08 Thread Staudinger, Malcolm

Can anyone from Verizon comment on what IP space that's being used for
this? Or perhaps what the rDNS mask will look like?
From an abuse perspective, knowing that an IP is being used for this can
make the difference between traffic looking like abuse and traffic
looking like multiple legitimate users.

Malcolm Staudinger
Information Security Analyst | EIS
EarthLink

-Original Message-
From: cb.list6 [mailto:cb.li...@gmail.com] 
Sent: Saturday, April 06, 2013 6:24 PM
To: nanog@nanog.org
Subject: Verizon DSL moving to CGN

Interesting.

http://www22.verizon.com/support/residential/internet/highspeedinternet/
networking/troubleshooting/portforwarding/123897.htm

Re: Verizon DSL moving to CGN



 CGN-like box. Yes, it's stateless. Doesn't matter, I still need to flow
 traffic through a dedicated box because MAP won't be implemented in my
 regular routers (if you know otherwise, please speak up).

Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
routers that I know of - ASR9K and ASR1K. Without that, you are right that
MAP wouldn't have been as beneficial as claimed.

 It's still NAT.

Yes, assuming MAP-T.
No, assuming, MAP-E




Cheers,
Rajiv

-Original Message-
From: Mikael Abrahamsson swm...@swm.pp.se
Organization: People's Front Against WWW
Date: Monday, April 8, 2013 6:01 AM
To: Rajiv Asati raj...@cisco.com
Cc: nanog list nanog@nanog.org
Subject: Re: Verizon DSL moving to CGN

On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote:

 Thankfully, MAP is not CGN. Correctly stated, unlike DS-Lite, MAP
 doesn't require any CGN that causes the SP network to put up with the
 NAT state. This means that all the subsequent issues of CGN/DS-Lite no
 longer apply.

For me as an operator, MAP is most likely going to be implemented in a
CGN-like box. Yes, it's stateless. Doesn't matter, I still need to flow
traffic through a dedicated box because MAP won't be implemented in my
regular routers (if you know otherwise, please speak up).

 MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled
 access. MAP makes much more sense in any SP network having its internet
 customers do IPv4 address sharing and embrace IPv6.

It's still NAT.

-- 
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Verizon DSL moving to CGN

On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva) raj...@cisco.comwrote:

 Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
 routers that I know of - ASR9K and ASR1K. Without that, you are right that
 MAP wouldn't have been as beneficial as claimed.


glad it's cross platform... is it also IP encumbered so it'll remain just
as 'cross platform' ?

Re: Verizon DSL moving to CGN


Tore is spot on. With MAP, you can use your regular routers, whether it is
the Encap mode or Translation mode.

One can decide between Encap mode and Translation mode of MAP per his/her
environment/requirements. I do find -T mode preferable since it requires
no changes to the transparent caching infrastructure or LI infrastructure
or QOS policies (if used between CE and Border routers).

One may refer to additional details here -

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/white_pap
er_c11-558744-00.html#wp9000119

http://www.ciscoknowledgenetwork.com/files/300_11-06-2012-NGN-IPv4-Exhaust-
IPv6-Strategy.pdf 

Cheers,
Rajiv


-Original Message-
From: Tore Anderson t...@fud.no
Date: Monday, April 8, 2013 6:29 AM
To: Mikael Abrahamsson swm...@swm.pp.se
Cc: Rajiv Asati raj...@cisco.com, nanog list nanog@nanog.org
Subject: Re: Verizon DSL moving to CGN

* Mikael Abrahamsson

 On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote:
 
 MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled
 access. MAP makes much more sense in any SP network having its
 internet customers do IPv4 address sharing and embrace IPv6.
 
 It's still NAT.

AIUI, the standards-track flavour of MAP, MAP-E, is *not* NAT - it is
tunneling, pure encap/decap plus a clever way to calculate the outer
IPv6 src/dst addresses from the inner IPv4 addresses and ports. The
inner IPv4 packets are not modified by the centralised MAP tunneling
routers, so there is no Network Address Translation being performed.

The tunnel endpoint will 99.99% of cases be a CPE with a NAPT44
component though, so there is some NAT involved in the overall solution,
but it's pretty much the same as what we have in today's CPEs/HGWs. The
only significant difference is that a MAP CPE must be prepared to not
being able to use all the 65536 source ports.

Tore

Re: Verizon DSL moving to CGN

Sam,

 What may make 'much more sense' in one network, doesn't necessarily make
 as much since in another network. As I understand it, MAP requires at
 least a software change on existing CPE, if not wholesale CPE change.
 Some providers may prefer to implement CGN instead if the capital outlay
 is less (and providing new CPE to customers through walkins or truck
rolls
 can be problematic).

I agree with you. Having said that, the way many ISPs are approaching the
MAP deployment is by letting the new customers get the MAP capable CPE
from the get go, while letting the existing customers' get their CPE
routers upgraded when/if they need a truck roll or through regular SH
(much like how Vonage does it).


It is certainly very much possible to get MAP functionality by software
upgrades, though the mileage may vary.


 What devices does Cisco support MAP on? Specifically, does the DPC3827
 support it?

MAP BR function is supported on ASR9K and ASR1K.

I am not aware of MAP CE function support on DPC3827 CPE router.


Cheers,
Rajiv

-Original Message-
From: Sam Hayes Merritt, III s...@themerritts.org
Date: Sunday, April 7, 2013 10:56 PM
To: Rajiv Asati raj...@cisco.com
Cc: nanog list nanog@nanog.org
Subject: Re: Verizon DSL moving to CGN


 MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled
 access. MAP makes much more sense in any SP network having its internet
 customers do IPv4 address sharing and embrace IPv6.

What may make 'much more sense' in one network, doesn't necessarily make
as much since in another network. As I understand it, MAP requires at
least a software change on existing CPE, if not wholesale CPE change.
Some providers may prefer to implement CGN instead if the capital outlay
is less (and providing new CPE to customers through walkins or truck
rolls 
can be problematic).

Our plan for my company at this time is to deploy native IPv4+IPv6 to
all customers. While we are doing that, continue discussions and testing
with CGN providers so that when we are unable to obtain anymore IPv4
addresses, we can then deploy CGN. Our hope is that we never get to the
point of having to go CGN but we have to be ready in case that day comes
and have our implementation and opt-out (if available) processes ready.


What devices does Cisco support MAP on? Specifically, does the DPC3827
support it?


sam

Re: Verizon DSL moving to CGN


Like you, I would like to be optimistic about many v4-only apps and
v4-only devices becoming dual-stack sooner than later.

But knowing that a significant (50%+) of android devices may not support
IPv6 (just like my brand new Samsung Galaxy 7'' tablet (just bought over
the weekend) being v4-only) and may not be upgraded by their users to the
right software, and that Skype etc. apps are out there, my optimism fades
away.

Cheers,
Rajiv

-Original Message-
From: Owen DeLong o...@delong.com
Date: Monday, April 8, 2013 1:38 AM
To: Rajiv Asati raj...@cisco.com
Cc: Fabien Delmotte fdelmot...@mac.com, nanog list nanog@nanog.org
Subject: Re: Verizon DSL moving to CGN


On Apr 7, 2013, at 18:21 , Rajiv Asati (rajiva) raj...@cisco.com wrote:

 Dual-stack in the home networks will stay with us for a long time
(beyond 2020!) until v4-only user devices and v4-only apps get refreshed.

I disagree. I think that v4-only apps and devices will get relegated to
being connected through v4-v6 adapter appliances until they are fixed.

IPv4 is simply going to become far too expensive to maintain to be able
to deliver it for residential pricing.

 Of course, this doesn't mean that the ISP access needs to stay
dual-stack, thanks to MAP, 464XLAT etc.
 

Right... Those are some of the ways that maintaining IPv4 will become so
expensive. ;-)

Owen

Re: Verizon DSL moving to CGN

Jack,

I am assuming that you meant MAP, when you wrote MAPS.

 The larger issue I think with MAP is CPE support requirements. There are
 ISP layouts that use bridging instead of CPE routers (which was a long
 term design to support IPv6 without CPE replacements years later). CGN
 will handle the IPv4 issues in this setup just fine. Then there are

I agree. Good point, btw.

This is the classical ISP deployment model, in which the ISP would usually
provide the layer2 modem, and let the customer get the retail CPE.

 those who have already deployed IPv6 capable CPEs with PPP or DHCP in a
 router configuration which does not have MAP support. Given the variety
 of CPE vendors that end up getting deployed over a longer period of
 time, it is easier and more cost effective to deploy CGN than try and
 replace all the CPEs.

Seemingly so, until we start adding up the cost of

- Logging infrastructure (setup  mtc)
- Static NAT  Port forwarding (gaming, camera, etc.)
- CGN redundancy  load-sharing
- design complexity (to maintain symmetry)
- ..

 Given US$35/CPE, cost for replacements (not including deployment costs)
 for 20k users is US$700k. CGN gear suddenly doesn't seem so costly.

Let's throw some numbers of the above costs and then we can do the
apple-to-apple comparison. Else, you are right that CGN cost could be a
lot less.


Cheers,
Rajiv

-Original Message-
From: Jack Bates jba...@brightok.net
Date: Monday, April 8, 2013 10:23 AM
To: Tore Anderson t...@fud.no
Cc: nanog list nanog@nanog.org
Subject: Re: Verizon DSL moving to CGN

On 4/8/2013 7:20 AM, Tore Anderson wrote:
 BTW. It is AIUI quite possible with MAP to provision a whole IPv4
 address or even a prefix to the subscriber, thus also taking away the
 need for [srcport-restricted] NAPT44 in the CPE.

The problem is NAPT44 in the CPE isn't enough. We are reaching the point
that 1 IPv4 Address per customer won't accommodate user bases.

The larger issue I think with MAP is CPE support requirements. There are
ISP layouts that use bridging instead of CPE routers (which was a long
term design to support IPv6 without CPE replacements years later). CGN
will handle the IPv4 issues in this setup just fine. Then there are
those who have already deployed IPv6 capable CPEs with PPP or DHCP in a
router configuration which does not have MAP support. Given the variety
of CPE vendors that end up getting deployed over a longer period of
time, it is easier and more cost effective to deploy CGN than try and
replace all the CPEs.

Given US$35/CPE, cost for replacements (not including deployment costs)
for 20k users is US$700k. CGN gear suddenly doesn't seem so costly.

The only way I see it justifiable is if you haven't had IPv6 deployment
in mind yet and you are having to replace every CPE for IPv6 support
anyways, you might go with a MAPS/IPv6 aware CPE which the customer pays
for if they wish IPv6 connectivity(or during whatever slow trickle
replacement methods you utilize). While waiting for the slow rollout,
CGN would be an interim cost that would be acceptable. I'm not sure
there is a reason for MAPS if you've already deployed CGN, though.

I am sure Verizon did a lot of cost analysis.

Jack

Re: Verizon DSL moving to CGN

Chris,

UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP
encumbered?

If so, the answer is Yes. v6 addressing doesn't need to change to
accommodate this IPv4 A+P encoding.


Cheers,
Rajiv

-Original Message-
From: Christopher Morrow morrowc.li...@gmail.com
Date: Monday, April 8, 2013 2:28 PM
To: Rajiv Asati raj...@cisco.com
Cc: Mikael Abrahamsson swm...@swm.pp.se, nanog list nanog@nanog.org
Subject: Re: Verizon DSL moving to CGN


On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva)
raj...@cisco.com wrote:

Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
routers that I know of - ASR9K and ASR1K. Without that, you are right that
MAP wouldn't have been as beneficial as claimed.





glad it's cross platform... is it also IP encumbered so it'll remain just
as 'cross platform' ?

Re: Verizon DSL moving to CGN

2013-04-08 Thread Chuck Anderson

I think he means patent encumbered.

On Mon, Apr 08, 2013 at 07:13:11PM +, Rajiv Asati (rajiva) wrote:
 Chris,
 
 UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP
 encumbered?
 
 If so, the answer is Yes. v6 addressing doesn't need to change to
 accommodate this IPv4 A+P encoding.
 
 
 Cheers,
 Rajiv
 
 -Original Message-
 From: Christopher Morrow morrowc.li...@gmail.com
 Date: Monday, April 8, 2013 2:28 PM
 To: Rajiv Asati raj...@cisco.com
 Cc: Mikael Abrahamsson swm...@swm.pp.se, nanog list nanog@nanog.org
 Subject: Re: Verizon DSL moving to CGN
 
 
 On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva)
 raj...@cisco.com wrote:
 
 Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
 routers that I know of - ASR9K and ASR1K. Without that, you are right that
 MAP wouldn't have been as beneficial as claimed.
 
 
 
 
 
 glad it's cross platform... is it also IP encumbered so it'll remain just
 as 'cross platform' ?

Re: Verizon DSL moving to CGN

Oh, it certainly is (per the IETF IPR rules).

Thanks for the clarity, Chuck.

Cheers,
Rajiv

-Original Message-
From: Chuck Anderson c...@wpi.edu
Date: Monday, April 8, 2013 3:18 PM
To: Rajiv Asati raj...@cisco.com
Cc: Christopher Morrow morrowc.li...@gmail.com, nanog list
nanog@nanog.org
Subject: Re: Verizon DSL moving to CGN

I think he means patent encumbered.

On Mon, Apr 08, 2013 at 07:13:11PM +, Rajiv Asati (rajiva) wrote:
 Chris,

 UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP
 encumbered?

 If so, the answer is Yes. v6 addressing doesn't need to change to
 accommodate this IPv4 A+P encoding.

 Cheers,
 Rajiv

 -Original Message-
 From: Christopher Morrow morrowc.li...@gmail.com
 Date: Monday, April 8, 2013 2:28 PM
 To: Rajiv Asati raj...@cisco.com
 Cc: Mikael Abrahamsson swm...@swm.pp.se, nanog list nanog@nanog.org
 Subject: Re: Verizon DSL moving to CGN

 On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva)
 raj...@cisco.com wrote:

 Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
 routers that I know of - ASR9K and ASR1K. Without that, you are right
that
 MAP wouldn't have been as beneficial as claimed.

 glad it's cross platform... is it also IP encumbered so it'll remain
just
 as 'cross platform' ?

Re: Verizon DSL moving to CGN

Tore,

 I haven't tested, but I believe that if you were to hook up a standard
 Linux box to a ISP that provides /32 or shorter over MAP, you don't

Yes, indeed. 

In fact, almost all of the MAP CE implementations (that I am aware of) are
open source/linux based -


http://enog.jp/~masakazu/vyatta/map/
http://mapt.ivi2.org:8039/readme.txt


Cheers,
Rajiv


-Original Message-
From: Tore Anderson t...@fud.no
Date: Monday, April 8, 2013 8:20 AM
To: Mikael Abrahamsson swm...@swm.pp.se, nanog list nanog@nanog.org
Cc: Rajiv Asati raj...@cisco.com
Subject: Re: Verizon DSL moving to CGN

* Tore Anderson

 The tunnel endpoint will 99.99% of cases be a CPE with a NAPT44
 component though, so there is some NAT involved in the overall solution,
 but it's pretty much the same as what we have in today's CPEs/HGWs. The
 only significant difference is that a MAP CPE must be prepared to not
 being able to use all the 65536 source ports.

BTW. It is AIUI quite possible with MAP to provision a whole IPv4
address or even a prefix to the subscriber, thus also taking away the
need for [srcport-restricted] NAPT44 in the CPE.

I find that the easiest way to visualise MAP is to take the 16 bits of
TCP/UDP port space, and bolt it onto the end of the 32 bits of the IPv4
address space, for a total of 48 routable bits. So while the primary
use case for MAP is to provision less than 32 bits to the individual
customers (say a /34 - 4 subscribers per IPv4 address w/16k ports
each), you can also give out a whole /32 or a /24 or whatever -
perhaps only to the customers that are willing to pay for the privilege.

I haven't tested, but I believe that if you were to hook up a standard
Linux box to a ISP that provides /32 or shorter over MAP, you don't
really need any special MAP support in the IP stack to make it go -
you'd have to calculate the addresses to be used yourself, but once
you've got them, you could just configure everything using standard ip
tunnel/address commands.

It's quite neat, I think. :-)

Tore

Re: Verizon DSL moving to CGN

On Mon, Apr 8, 2013 at 3:21 PM, Rajiv Asati (rajiva) raj...@cisco.comwrote:

 Oh, it certainly is (per the IETF IPR rules).


which rfcs? I can find a draft in softwire:
   http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01

and a reference to this in wikipedia:
  http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#MAP

which says: ...(MAP) is a Cisco IPv6 transition proposal...

so.. err, we won't see this in juniper gear since:
  1) not a standard
  2) encumbered by IPR issues

weee!


 Thanks for the clarity, Chuck.

 Cheers,
 Rajiv

 -Original Message-
 From: Chuck Anderson c...@wpi.edu
 Date: Monday, April 8, 2013 3:18 PM
 To: Rajiv Asati raj...@cisco.com
 Cc: Christopher Morrow morrowc.li...@gmail.com, nanog list
 nanog@nanog.org
 Subject: Re: Verizon DSL moving to CGN

 I think he means patent encumbered.
 
 On Mon, Apr 08, 2013 at 07:13:11PM +, Rajiv Asati (rajiva) wrote:
  Chris,
 
  UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP
  encumbered?
 
  If so, the answer is Yes. v6 addressing doesn't need to change to
  accommodate this IPv4 A+P encoding.
 
 
  Cheers,
  Rajiv
 
  -Original Message-
  From: Christopher Morrow morrowc.li...@gmail.com
  Date: Monday, April 8, 2013 2:28 PM
  To: Rajiv Asati raj...@cisco.com
  Cc: Mikael Abrahamsson swm...@swm.pp.se, nanog list nanog@nanog.org
  Subject: Re: Verizon DSL moving to CGN
 
  
  On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva)
  raj...@cisco.com wrote:
  
  Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
  routers that I know of - ASR9K and ASR1K. Without that, you are right
 that
  MAP wouldn't have been as beneficial as claimed.
  
  
  
  
  
  glad it's cross platform... is it also IP encumbered so it'll remain
 just
  as 'cross platform' ?

Re: Verizon DSL moving to CGN

2013-04-08 Thread Chuck Anderson

http://datatracker.ietf.org/ipr/search/?option=document_searchid_document_tag=draft-ietf-softwire-map

http://datatracker.ietf.org/doc/draft-ietf-softwire-map/?include_text=1

On Mon, Apr 08, 2013 at 03:41:54PM -0400, Christopher Morrow wrote:
 On Mon, Apr 8, 2013 at 3:21 PM, Rajiv Asati (rajiva) raj...@cisco.comwrote:
 
  Oh, it certainly is (per the IETF IPR rules).
 
 
 which rfcs? I can find a draft in softwire:
http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01
 
 and a reference to this in wikipedia:
   http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#MAP
 
 which says: ...(MAP) is a Cisco IPv6 transition proposal...
 
 so.. err, we won't see this in juniper gear since:
   1) not a standard
   2) encumbered by IPR issues
 
 weee!
 
 
  Thanks for the clarity, Chuck.
 
  Cheers,
  Rajiv
 
  -Original Message-
  From: Chuck Anderson c...@wpi.edu
  Date: Monday, April 8, 2013 3:18 PM
  To: Rajiv Asati raj...@cisco.com
  Cc: Christopher Morrow morrowc.li...@gmail.com, nanog list
  nanog@nanog.org
  Subject: Re: Verizon DSL moving to CGN
 
  I think he means patent encumbered.
  
  On Mon, Apr 08, 2013 at 07:13:11PM +, Rajiv Asati (rajiva) wrote:
   Chris,
  
   UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP
   encumbered?
  
   If so, the answer is Yes. v6 addressing doesn't need to change to
   accommodate this IPv4 A+P encoding.
  
  
   Cheers,
   Rajiv
  
   -Original Message-
   From: Christopher Morrow morrowc.li...@gmail.com
   Date: Monday, April 8, 2013 2:28 PM
   To: Rajiv Asati raj...@cisco.com
   Cc: Mikael Abrahamsson swm...@swm.pp.se, nanog list nanog@nanog.org
   Subject: Re: Verizon DSL moving to CGN
  
   
   On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva)
   raj...@cisco.com wrote:
   
   Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
   routers that I know of - ASR9K and ASR1K. Without that, you are right
  that
   MAP wouldn't have been as beneficial as claimed.
   
   
   
   
   
   glad it's cross platform... is it also IP encumbered so it'll remain
  just
   as 'cross platform' ?

Re: Verizon DSL moving to CGN

Chris,

That's an incorrect draft pointer. Here is the correct one -

http://tools.ietf.org/html/draft-ietf-softwire-map
tools.ietf.org/html/draft-ietf-softwire-map-t
http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp

And no, Cisco has no IPR on MAP wrt the above drafts.

Cheers,
Rajiv

PS: Please do note that the IPRs mostly get nullified once they are
through the IETF standards process.




-Original Message-
From: Christopher Morrow morrowc.li...@gmail.com
Date: Monday, April 8, 2013 3:41 PM
To: Rajiv Asati raj...@cisco.com
Cc: Chuck Anderson c...@wpi.edu, nanog list nanog@nanog.org
Subject: Re: Verizon DSL moving to CGN




On Mon, Apr 8, 2013 at 3:21 PM, Rajiv Asati (rajiva)
raj...@cisco.com wrote:

Oh, it certainly is (per the IETF IPR rules).





which rfcs? I can find a draft in softwire:
   http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01


and a reference to this in wikipedia:
  http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#MAP


which says: ...(MAP) is a Cisco IPv6 transition proposal...


so.. err, we won't see this in juniper gear since:
  1) not a standard
  2) encumbered by IPR issues


weee!
 

Thanks for the clarity, Chuck.

Cheers,
Rajiv

-Original Message-
From: Chuck Anderson c...@wpi.edu
Date: Monday, April 8, 2013 3:18 PM
To: Rajiv Asati raj...@cisco.com

Cc: Christopher Morrow morrowc.li...@gmail.com, nanog list
nanog@nanog.org
Subject: Re: Verizon DSL moving to CGN

I think he means patent encumbered.

On Mon, Apr 08, 2013 at 07:13:11PM +, Rajiv Asati (rajiva) wrote:
 Chris,

 UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP
 encumbered?

 If so, the answer is Yes. v6 addressing doesn't need to change to
 accommodate this IPv4 A+P encoding.


 Cheers,
 Rajiv

 -Original Message-
 From: Christopher Morrow morrowc.li...@gmail.com
 Date: Monday, April 8, 2013 2:28 PM
 To: Rajiv Asati raj...@cisco.com
 Cc: Mikael Abrahamsson swm...@swm.pp.se, nanog list nanog@nanog.org
 Subject: Re: Verizon DSL moving to CGN

 
 On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva)
 raj...@cisco.com wrote:
 
 Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
 routers that I know of - ASR9K and ASR1K. Without that, you are right
that
 MAP wouldn't have been as beneficial as claimed.
 
 
 
 
 
 glad it's cross platform... is it also IP encumbered so it'll remain
just
 as 'cross platform' ?

Re: Verizon DSL moving to CGN

2013-04-08 Thread Tom Taylor

In what sense do you mean that? The end-user IPv6 prefix certainly ties 
IPv4 and IPv6 together, hence the interest in the Light-Weight IPv4 over 
IPv6 alternative.


Tom

On 08/04/2013 3:13 PM, Rajiv Asati (rajiva) wrote:

Chris,

UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP
encumbered?

If so, the answer is Yes. v6 addressing doesn't need to change to
accommodate this IPv4 A+P encoding.


Cheers,
Rajiv


...

Re: Verizon DSL moving to CGN

On Mon, Apr 8, 2013 at 3:48 PM, Rajiv Asati (rajiva) raj...@cisco.comwrote:

 Chris,

 That's an incorrect draft pointer. Here is the correct one -

 http://tools.ietf.org/html/draft-ietf-softwire-map
 tools.ietf.org/html/draft-ietf-softwire-map-t
 http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp


great, but still a draft, not an official standard.


 And no, Cisco has no IPR on MAP wrt the above drafts.


'yet'... they don't have to officially declare until WGLC... and REALLY not
until the draft is sent up to the IESG, but doing it early is certainly
nice so that the WG has an opportunity to say: yea, IPR here is going to
cause a problem with interop/etc.


 Cheers,
 Rajiv

 PS: Please do note that the IPRs mostly get nullified once they are
 through the IETF standards process.


that's not been my experience.. see flow-spec for a great example. 'mostly
nullified' is .. disingenuous at best.





 -Original Message-
 From: Christopher Morrow morrowc.li...@gmail.com
 Date: Monday, April 8, 2013 3:41 PM
 To: Rajiv Asati raj...@cisco.com
 Cc: Chuck Anderson c...@wpi.edu, nanog list nanog@nanog.org
 Subject: Re: Verizon DSL moving to CGN

 
 
 
 On Mon, Apr 8, 2013 at 3:21 PM, Rajiv Asati (rajiva)
 raj...@cisco.com wrote:
 
 Oh, it certainly is (per the IETF IPR rules).
 
 
 
 
 
 which rfcs? I can find a draft in softwire:
http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01
 
 
 and a reference to this in wikipedia:
   http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#MAP
 
 
 which says: ...(MAP) is a Cisco IPv6 transition proposal...
 
 
 so.. err, we won't see this in juniper gear since:
   1) not a standard
   2) encumbered by IPR issues
 
 
 weee!
 
 
 Thanks for the clarity, Chuck.
 
 Cheers,
 Rajiv
 
 -Original Message-
 From: Chuck Anderson c...@wpi.edu
 Date: Monday, April 8, 2013 3:18 PM
 To: Rajiv Asati raj...@cisco.com
 
 Cc: Christopher Morrow morrowc.li...@gmail.com, nanog list
 nanog@nanog.org
 Subject: Re: Verizon DSL moving to CGN
 
 I think he means patent encumbered.
 
 On Mon, Apr 08, 2013 at 07:13:11PM +, Rajiv Asati (rajiva) wrote:
  Chris,
 
  UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP
  encumbered?
 
  If so, the answer is Yes. v6 addressing doesn't need to change to
  accommodate this IPv4 A+P encoding.
 
 
  Cheers,
  Rajiv
 
  -Original Message-
  From: Christopher Morrow morrowc.li...@gmail.com
  Date: Monday, April 8, 2013 2:28 PM
  To: Rajiv Asati raj...@cisco.com
  Cc: Mikael Abrahamsson swm...@swm.pp.se, nanog list nanog@nanog.org
 
  Subject: Re: Verizon DSL moving to CGN
 
  
  On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva)
  raj...@cisco.com wrote:
  
  Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
  routers that I know of - ASR9K and ASR1K. Without that, you are right
 that
  MAP wouldn't have been as beneficial as claimed.
  
  
  
  
  
  glad it's cross platform... is it also IP encumbered so it'll remain
 just
  as 'cross platform' ?

Re: Verizon DSL moving to CGN

2013-04-08 Thread Chris Adams

Once upon a time, Rajiv Asati (rajiva) raj...@cisco.com said:
 But knowing that a significant (50%+) of android devices may not support
 IPv6 (just like my brand new Samsung Galaxy 7'' tablet (just bought over
 the weekend) being v4-only) and may not be upgraded by their users to the
 right software, and that Skype etc. apps are out there, my optimism fades
 away.

Yeah, Samsung is screwy on Android+IPv6.  My (less than 6 month old)
Samsung phone with Android 4.0 gets an IPv6 address (autoconfigured) but
does not add an IPv6 default route, so it can't reach the IPv6 Internet
over wi-fi.  IIRC when I enabled T-Mobile's IPv6 APN, it did handle IPv6
over the cell network okay.

My generic Chinese import Android 4.0 tablet works just fine with IPv6,
as did my old HTC/T-Mobile G2 (wi-fi only).
-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: Verizon DSL moving to CGN

2013-04-08 Thread Huasong Zhou

We got this modem and router all in one box from Comcast directly. And by the 
way, home use routers don't assign 10.0.0.0 numbers.

Joe

Sent from my iPhone

On Apr 7, 2013, at 9:11 PM, Rajiv Asati (rajiva) raj...@cisco.com wrote:

 Nope. Comcast is not using any CGN, as much as I know.
 
 Is your MacBook directly connected to the modem or a router? I presume the 
 latter.
 
 Cheers,
 Rajiv
 
 Sent from my Phone
 
 On Apr 7, 2013, at 11:47 AM, Huasong Zhou huas...@kalorama.com wrote:
 
 I think Comcast is using CGN too!!! My IP address displayed on my MacBook is 
 in the 10.0.0.0/8 range, and ARIN website can't determine my IP address 
 either.
 
 Joe
 
 Sent from my iPhone
 
 On Apr 6, 2013, at 9:33 PM, Joshua Smith juice...@gmail.com wrote:
 
 Very interesting indeed. Way to do the right thing here Verizon. This may 
 be the first time I've been happy to be a Comcast customer. 
 
 -- 
 Josh Smith
 kD8HRX
 
 email/jabber: juice...@gmail.com
 Phone: 304.237.9369(c)
 
 Sent from my iPad
 
 
 On Apr 6, 2013, at 9:24 PM, cb.list6 cb.li...@gmail.com wrote:
 
 Interesting.
 
 http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm

Re: Verizon DSL moving to CGN

Chris,

Your points are well taken.


Cheers,
Rajiv

-Original Message-
From: Christopher Morrow morrowc.li...@gmail.com
Date: Monday, April 8, 2013 3:57 PM
To: Rajiv Asati raj...@cisco.com
Cc: Chuck Anderson c...@wpi.edu, nanog list nanog@nanog.org
Subject: Re: Verizon DSL moving to CGN




On Mon, Apr 8, 2013 at 3:48 PM, Rajiv Asati (rajiva)
raj...@cisco.com wrote:

Chris,

That's an incorrect draft pointer. Here is the correct one -

http://tools.ietf.org/html/draft-ietf-softwire-map
tools.ietf.org/html/draft-ietf-softwire-map-t
http://tools.ietf.org/html/draft-ietf-softwire-map-t
http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp





great, but still a draft, not an official standard.
 

And no, Cisco has no IPR on MAP wrt the above drafts.





'yet'... they don't have to officially declare until WGLC... and REALLY
not until the draft is sent up to the IESG, but doing it early is
certainly nice so that the WG has an opportunity to say: yea, IPR here
is going to cause a problem with
 interop/etc.
 

Cheers,
Rajiv

PS: Please do note that the IPRs mostly get nullified once they are
through the IETF standards process.






that's not been my experience.. see flow-spec for a great example.
'mostly nullified' is .. disingenuous at best.
 




-Original Message-
From: Christopher Morrow morrowc.li...@gmail.com

Date: Monday, April 8, 2013 3:41 PM
To: Rajiv Asati raj...@cisco.com

Cc: Chuck Anderson c...@wpi.edu, nanog list nanog@nanog.org
Subject: Re: Verizon DSL moving to CGN




On Mon, Apr 8, 2013 at 3:21 PM, Rajiv Asati (rajiva)
raj...@cisco.com wrote:

Oh, it certainly is (per the IETF IPR rules).





which rfcs? I can find a draft in softwire:
   
http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01
http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01


and a reference to this in wikipedia:
  http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#MAP


which says: ...(MAP) is a Cisco IPv6 transition proposal...


so.. err, we won't see this in juniper gear since:
  1) not a standard
  2) encumbered by IPR issues


weee!


Thanks for the clarity, Chuck.

Cheers,
Rajiv

-Original Message-
From: Chuck Anderson c...@wpi.edu
Date: Monday, April 8, 2013 3:18 PM
To: Rajiv Asati raj...@cisco.com

Cc: Christopher Morrow morrowc.li...@gmail.com, nanog list
nanog@nanog.org
Subject: Re: Verizon DSL moving to CGN

I think he means patent encumbered.

On Mon, Apr 08, 2013 at 07:13:11PM +, Rajiv Asati (rajiva) wrote:
 Chris,

 UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP
 encumbered?

 If so, the answer is Yes. v6 addressing doesn't need to change to
 accommodate this IPv4 A+P encoding.


 Cheers,
 Rajiv

 -Original Message-
 From: Christopher Morrow morrowc.li...@gmail.com
 Date: Monday, April 8, 2013 2:28 PM
 To: Rajiv Asati raj...@cisco.com
 Cc: Mikael Abrahamsson swm...@swm.pp.se, nanog list
nanog@nanog.org
 Subject: Re: Verizon DSL moving to CGN

 
 On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva)
 raj...@cisco.com wrote:
 
 Yes, MAP (T-Translation or E-Encap mode) is implemented on two
regular
 routers that I know of - ASR9K and ASR1K. Without that, you are right
that
 MAP wouldn't have been as beneficial as claimed.
 
 
 
 
 
 glad it's cross platform... is it also IP encumbered so it'll remain
just
 as 'cross platform' ?

Re: Verizon DSL moving to CGN

2013-04-08 Thread Jay Ashworth

- Original Message -
 From: Huasong Zhou huas...@kalorama.com

 We got this modem and router all in one box from Comcast directly. And
 by the way, home use routers don't assign 10.0.0.0 numbers.

I have seen consumer NAT routers assign addresses in all three RFC1918
blocks, though I couldn't cite particular models for you.  10./ is less
common than 172./, but not impossible.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth  Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: Verizon DSL moving to CGN


On Apr 8, 2013, at 07:58 , joel jaeggli joe...@bogus.com wrote:

 On 4/8/13 7:23 AM, Jack Bates wrote:
 On 4/8/2013 7:20 AM, Tore Anderson wrote:
 BTW. It is AIUI quite possible with MAP to provision a whole IPv4
 address or even a prefix to the subscriber, thus also taking away the
 need for [srcport-restricted] NAPT44 in the CPE.
 
 The problem is NAPT44 in the CPE isn't enough. We are reaching the point 
 that 1 IPv4 Address per customer won't accommodate user bases.
 
 That happened a long time ago. I realize the people like to think of wireless 
 providers as different, they really aren't. A big chuck of our mobile gaming 
 customers come to us via carrier operated nat translators. Some of them now 
 come to us via ipv6, most do not.
 The larger issue I think with MAP is CPE support requirements. There are ISP 
 layouts that use bridging instead of CPE routers (which was a long term 
 design to support IPv6 without CPE replacements years later). CGN will 
 handle the IPv4 issues in this setup just fine. Then there are those who 
 have already deployed IPv6 capable CPEs with PPP or DHCP in a router 
 configuration which does not have MAP support. Given the variety of CPE 
 vendors that end up getting deployed over a longer period of time, it is 
 easier and more cost effective to deploy CGN than try and replace all the 
 CPEs.
 
 Given US$35/CPE, cost for replacements (not including deployment costs) for 
 20k users is US$700k. CGN gear suddenly doesn't seem so costly.
 
 The only way I see it justifiable is if you haven't had IPv6 deployment in 
 mind yet and you are having to replace every CPE for IPv6 support anyways, 
 you might go with a MAPS/IPv6 aware CPE which the customer pays for if they 
 wish IPv6 connectivity(or during whatever slow trickle replacement methods 
 you utilize). While waiting for the slow rollout, CGN would be an interim 
 cost that would be acceptable. I'm not sure there is a reason for MAPS if 
 you've already deployed CGN, though.
 
 I am sure Verizon did a lot of cost analysis.
 
 Jack
 
 

There is actually a key difference. In the US, at least, everyone is used to 
the cellular networks mostly sucking.

They are willing to put up with far more degraded service over wireless than 
they will tolerate on a wired connection.

You and I and everyone else on this list realize that this is complete BS, but 
the majority of the general public tolerates it, so it persists.

Owen

Re: Verizon DSL moving to CGN

2013-04-08 Thread Tom Taylor

I think what that screenshot is saying is that after you deploy MAP, 
then if you stop using it the IPv6 addresses don't need to change. I 
would assume you're not saying that you can take your IPv6 addresses as 
you find them and interpret them as MAP End-user prefixes.


Tom

On 08/04/2013 5:38 PM, Rajiv Asati (rajiva) wrote:

Hi Tom,

Good question.

The End-user IPv6 prefix can be constructed using whatever techniques
independent of MAP etc. in any deployment requiring IPv4 address sharing.

What is interesting is that the MAP enabled CPE could parse certain bits
of that IPv6 prefix to mean something for MAP. That's it. Attached is a
screenshot to illustrate this very point.

Cheers,
Rajiv

-Original Message-
From: Tom Taylor tom.taylor.s...@gmail.com
Date: Monday, April 8, 2013 3:48 PM
To: nanog@nanog.org nanog@nanog.org
Subject: Re: Verizon DSL moving to CGN


In what sense do you mean that? The end-user IPv6 prefix certainly ties
IPv4 and IPv6 together, hence the interest in the Light-Weight IPv4 over
IPv6 alternative.

Tom

On 08/04/2013 3:13 PM, Rajiv Asati (rajiva) wrote:

Chris,

UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP
encumbered?

If so, the answer is Yes. v6 addressing doesn't need to change to
accommodate this IPv4 A+P encoding.


Cheers,
Rajiv


...

Re: Verizon DSL moving to CGN


On Apr 8, 2013, at 11:54 , Rajiv Asati (rajiva) raj...@cisco.com wrote:

 
 Like you, I would like to be optimistic about many v4-only apps and
 v4-only devices becoming dual-stack sooner than later.
 
 But knowing that a significant (50%+) of android devices may not support
 IPv6 (just like my brand new Samsung Galaxy 7'' tablet (just bought over
 the weekend) being v4-only) and may not be upgraded by their users to the
 right software, and that Skype etc. apps are out there, my optimism fades
 away.

The upgrade problem isn't that hard to solve. As soon as users want to use
something that doesn't work without the upgrade, the upgrades get installed.

Apple does a great job of this...

Every time they release an iOS upgrade I really don't want, they manage to
also release an update to software that I do care about. That software update
inherently requires me to accept the iOS upgrade.

Owen

Re: Verizon DSL moving to CGN


On Apr 7, 2013, at 18:45 , Huasong Zhou huas...@kalorama.com wrote:

 We got this modem and router all in one box from Comcast directly. And by the 
 way, home use routers don't assign 10.0.0.0 numbers.
 

Some do.

Owen

 Joe
 
 Sent from my iPhone
 
 On Apr 7, 2013, at 9:11 PM, Rajiv Asati (rajiva) raj...@cisco.com wrote:
 
 Nope. Comcast is not using any CGN, as much as I know.
 
 Is your MacBook directly connected to the modem or a router? I presume the 
 latter.
 
 Cheers,
 Rajiv
 
 Sent from my Phone
 
 On Apr 7, 2013, at 11:47 AM, Huasong Zhou huas...@kalorama.com wrote:
 
 I think Comcast is using CGN too!!! My IP address displayed on my MacBook 
 is in the 10.0.0.0/8 range, and ARIN website can't determine my IP address 
 either.
 
 Joe
 
 Sent from my iPhone
 
 On Apr 6, 2013, at 9:33 PM, Joshua Smith juice...@gmail.com wrote:
 
 Very interesting indeed. Way to do the right thing here Verizon. This may 
 be the first time I've been happy to be a Comcast customer. 
 
 -- 
 Josh Smith
 kD8HRX
 
 email/jabber: juice...@gmail.com
 Phone: 304.237.9369(c)
 
 Sent from my iPad
 
 
 On Apr 6, 2013, at 9:24 PM, cb.list6 cb.li...@gmail.com wrote:
 
 Interesting.
 
 http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm

Re: Verizon DSL moving to CGN

2013-04-08 Thread Seth Mattinen

On 4/8/13 5:55 PM, Owen DeLong wrote:
 
 On Apr 7, 2013, at 18:45 , Huasong Zhou huas...@kalorama.com wrote:
 
 We got this modem and router all in one box from Comcast directly. And by 
 the way, home use routers don't assign 10.0.0.0 numbers.

 
 Some do.
 

ATT U-verse used to have 10.0.0.0/8 as an option until a firmware
update removed that capability. My bet is on CGN prep work.

~Seth

Re: Verizon DSL moving to CGN

Hi Tom,

The key take-away is that MAP doesn't _necessarily_ require IPv6 prefix to
be constructed in a special way (so as to encode the IPv4 address inside
it).
 

Please see more inline,

 I think what that screenshot is saying is that after you deploy MAP,
 then if you stop using it the IPv6 addresses don't need to change.

Yes. 

 I would assume you're not saying that you can take your IPv6 addresses as
 you find them and interpret them as MAP End-user prefixes.

It can work even in that realm as well (IPv6 PD assumed). There are pros 
cons of doing this, suffice to say.

Cheers,

Rajiv


-Original Message-
From: Tom Taylor tom.taylor.s...@gmail.com
Date: Monday, April 8, 2013 8:51 PM
To: Rajiv Asati raj...@cisco.com
Cc: nanog@nanog.org nanog@nanog.org
Subject: Re: Verizon DSL moving to CGN

I think what that screenshot is saying is that after you deploy MAP,
then if you stop using it the IPv6 addresses don't need to change. I
would assume you're not saying that you can take your IPv6 addresses as
you find them and interpret them as MAP End-user prefixes.

Tom

On 08/04/2013 5:38 PM, Rajiv Asati (rajiva) wrote:
 Hi Tom,

 Good question.

 The End-user IPv6 prefix can be constructed using whatever techniques
 independent of MAP etc. in any deployment requiring IPv4 address
sharing.

 What is interesting is that the MAP enabled CPE could parse certain bits
 of that IPv6 prefix to mean something for MAP. That's it. Attached is a
 screenshot to illustrate this very point.

 Cheers,
 Rajiv

 -Original Message-
 From: Tom Taylor tom.taylor.s...@gmail.com
 Date: Monday, April 8, 2013 3:48 PM
 To: nanog@nanog.org nanog@nanog.org
 Subject: Re: Verizon DSL moving to CGN

 In what sense do you mean that? The end-user IPv6 prefix certainly ties
 IPv4 and IPv6 together, hence the interest in the Light-Weight IPv4
over
 IPv6 alternative.

 Tom

 On 08/04/2013 3:13 PM, Rajiv Asati (rajiva) wrote:
 Chris,

 UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP
 encumbered?

 If so, the answer is Yes. v6 addressing doesn't need to change to
 accommodate this IPv4 A+P encoding.


 Cheers,
 Rajiv

 ...

Re: Verizon DSL moving to CGN

I agree. Apple does it really well, no doubt about it. This is because
they control both the software and hardware.

Google/Android çan not do it well enough, since the Android OS version
compatibility with the hardware is somewhat dictated by the hardware
manufacturer. This isn't always helpful. :-(

For ex, there are numerous android apps that are not supported
on many android devices. :=(

Anyway, this is why I think that dual-stack home networks (and UEs) will
be with us for a long time.

Cheers,
Rajiv



-Original Message-
From: Owen DeLong o...@delong.com
Date: Monday, April 8, 2013 8:52 PM
To: Rajiv Asati raj...@cisco.com
Cc: Fabien Delmotte fdelmot...@mac.com, nanog list nanog@nanog.org
Subject: Re: Verizon DSL moving to CGN


On Apr 8, 2013, at 11:54 , Rajiv Asati (rajiva) raj...@cisco.com wrote:

 
 Like you, I would like to be optimistic about many v4-only apps and
 v4-only devices becoming dual-stack sooner than later.
 
 But knowing that a significant (50%+) of android devices may not support
 IPv6 (just like my brand new Samsung Galaxy 7'' tablet (just bought over
 the weekend) being v4-only) and may not be upgraded by their users to
the
 right software, and that Skype etc. apps are out there, my optimism
fades
 away.

The upgrade problem isn't that hard to solve. As soon as users want to use
something that doesn't work without the upgrade, the upgrades get
installed.

Apple does a great job of this...

Every time they release an iOS upgrade I really don't want, they manage to
also release an update to software that I do care about. That software
update
inherently requires me to accept the iOS upgrade.

Owen

Re: Verizon DSL moving to CGN

On Mon, Apr 8, 2013 at 11:23 PM, Rajiv Asati (rajiva) raj...@cisco.comwrote:

 For ex, there are numerous android apps that are not supported
 on many android devices. :=(


I think this is actually up to the developer of the APP not the hardware
nor OS manufacturer.

Re: Verizon DSL moving to CGN

2013-04-07 Thread Valdis . Kletnieks

On Sun, 07 Apr 2013 01:40:09 -0400, Christopher Morrow said:

 I wonder how much more painful just upgrading the dsl plant to support v6
 would be vs deploying the cgn equipment and funneling users through that :(

The answer depends on whether the person making the decision thinks they'll
have left the company before the IPv6 birds come home to roost. ;)


pgpaKqY0d0nVi.pgp
Description: PGP signature

Re: Verizon DSL moving to CGN

2013-04-07 Thread Mikael Abrahamsson


On Sun, 7 Apr 2013, Christopher Morrow wrote:

I wonder how much more painful just upgrading the dsl plant to support 
v6 would be vs deploying the cgn equipment and funneling users through 
that :(


IPv6 deployment is not a short term solution to IPv4 address depletion. 
Would you be less upset if there was IPv6 access and CPE based DS Lite (ie 
your IPv4 is still CGN:ed, just in a different way)?


CGN is here to stay for IPv4. The solution for long term Internet growth 
is IPv6.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Verizon DSL moving to CGN

2013-04-07 Thread Fabien Delmotte

CGN is just a solution to save time, it is not a transition mechanism through 
IPv6
At the end (IPv6 at home) you will need at list :
Dual stack or NAT64/ DNS64

My 2 cents

On Apr 7, 2013, at 8:42 AM, Mikael Abrahamsson swm...@swm.pp.se wrote:

 On Sun, 7 Apr 2013, Christopher Morrow wrote:
 
 I wonder how much more painful just upgrading the dsl plant to support v6 
 would be vs deploying the cgn equipment and funneling users through that :(
 
 IPv6 deployment is not a short term solution to IPv4 address depletion. Would 
 you be less upset if there was IPv6 access and CPE based DS Lite (ie your 
 IPv4 is still CGN:ed, just in a different way)?
 
 CGN is here to stay for IPv4. The solution for long term Internet growth is 
 IPv6.
 
 -- 
 Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Verizon DSL moving to CGN

2013-04-07 Thread Mikael Abrahamsson


On Sun, 7 Apr 2013, Fabien Delmotte wrote:


CGN is just a solution to save time, it is not a transition mechanism through 
IPv6
At the end (IPv6 at home) you will need at list :
Dual stack or NAT64/ DNS64


CGN doesn't stop anyone deploying dual stack. NAT64/DNS64 is dead in the 
water without other mechanisms (464XLAT or alike).


My point is that people seem to scoff at CGN. There is nothing stopping 
anyone putting in CGN for IPv4 (that has to be done to handle IPv4 address 
exhaustion), then giving dual stack for end users can be done at any time.


Face it, we're running out of IPv4 addresses. For basic Internet 
subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a 
completely different problem that has little bearing on CGN or not for 
IPv4. DS-Lite is also CGN, it just happens to be done over IPv6 access. 
MAP is also CGN.


I'm ok with people complaining about lack of IPv6 deployment, but I don't 
understand people complaining about CGN. What's the alternative?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Verizon DSL moving to CGN

2013-04-07 Thread Alex

Well if the RFCs would just be set in stone already like Moses's 10 
commandments

and if the programmers would actually start writing code for v6
and if the web site hosting servers would at least have dual stack 
enabled on them

it would be great.

But till then we just change a RFC here, band-aid IPv4 there and wait 
till everything reaches critical mass and comes crashing on our heads.


On 4/7/2013 5:38 AM, Jay Ashworth wrote:

- Original Message -

From: cb.list6 cb.li...@gmail.com
Interesting.


http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm

What I find amusing is how they call it Carrier Grade NAT one time, and
then switch to calling it Carrier Grade Network, thereby making it sound
all cool and better and stuff...

Cheers,
-- jra

Re: Verizon DSL moving to CGN

2013-04-07 Thread Rob Seastrom


Jimmy Hess mysi...@gmail.com writes:

 On 4/6/13, Matthew Kaufman matt...@matthew.at wrote:
 On 4/6/2013 6:24 PM, cb.list6 wrote:

 I'd love to see a CGN box that is cheaper than IPv4 addresses currently
 are on the transfer market.

 You mean like a few linux servers running iptables  nat-masquerade?

 You think the Carrier Grade  in Carrier Grade NAT  isn't just a
 rhetorically constructed distraction,  from the fact that  simple NAT
 may  be implemented,  and yeah, end users are certain to experience
 annoyances, either way...

Forget about the annoying users part; the carrier-grade part of
CGN is all about not annoying the service provider.  As far as I'm
aware, iptables does not include deterministic port translation based
on source address, nor easy-to-configure hooks for CALEA [*].  It may
well turn out that once one factors in support your costs are higher
with large scale NAT-on-Linux than if you'd sucked it up and coughed
up a quarter mil for an appliance.

-r

[*] I'd love to hear that I'm wrong on this count, but a how-to
document that explains how one can lovingly handcraft such a thing as
opposed to a special refactored distro that's ready to plug-and-chug
appliance style will only serve to reinforce my assertion.

Re: Verizon DSL moving to CGN

2013-04-07 Thread Valdis . Kletnieks

On Sun, 07 Apr 2013 13:54:04 +0300, Alex said:
 Well if the RFCs would just be set in stone already like Moses's 10 
 commandments
 and if the programmers would actually start writing code for v6
 and if the web site hosting servers would at least have dual stack
 enabled on them
 it would be great.

 But till then we just change a RFC here, band-aid IPv4 there and wait
 till everything reaches critical mass and comes crashing on our heads.

I find it interesting that you complain about a 15 year old protocol
not being set in stone, and cite that as a reason for no code getting
done.

But the solution is to take advantage of the fact that the 30 year old
predecessor isn't set in stone either...

(And there's no reason that programmers can't be writing code - RFC3542
came out in May 2003)


pgp27wjvg38nA.pgp
Description: PGP signature

Re: Verizon DSL moving to CGN

2013-04-07 Thread Tore Anderson

* Mikael Abrahamsson

 My point is that people seem to scoff at CGN. There is nothing stopping
 anyone putting in CGN for IPv4 (that has to be done to handle IPv4
 address exhaustion), then giving dual stack for end users can be done at
 any time.
 
 Face it, we're running out of IPv4 addresses. For basic Internet
 subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a
 completely different problem that has little bearing on CGN or not for
 IPv4. DS-Lite is also CGN, it just happens to be done over IPv6 access.
 MAP is also CGN.
 
 I'm ok with people complaining about lack of IPv6 deployment, but I
 don't understand people complaining about CGN. What's the alternative?

Technically I agree with all of the above. However, going for the NAT444
flavour of CGN might well delay or lower the perceived importance of
IPv6 deployment within an ISP. The immediate problem is IPv4 service
continuity, and if that is to be accomplished without IPv6 being part of
it, it's easy to postpone doing anything about IPv6.

I went to an interesting presentation from Kabel Deutschland last month,
who have deployed DS-Lite to their residential subscribers. One of the
messages was that once the decision was made to implement DS-Lite to
deal with IPv4 exhaustion, there was no problem getting the necessary
support to deploy IPv6 - it was no longer a separate and
non-revenue-generating problem, but an essential building block needed
for their IPv4 service continuity. (MAP and 464XLAT would yield the same
effect, of course.)

To answer your earlier question - yes, I'd very much prefer to have
DS-Lite over NAT444, because only the former will ensure that I get
native IPv6 once my native IPv4 gets taken away. With NAT444, I'm no
closer to having IPv6 than I was before NAT444.

That said, there are of course some things that may make anything except
NAT444 undeployable. Verizon might have old DSLAMs that cannot deal with
IPv6, or customer-controlled/owned (layer-3) HGWs. If so, their hands
are tied.

-- 
Tore Anderson

Re: Verizon DSL moving to CGN

2013-04-07 Thread Huasong Zhou

I think Comcast is using CGN too!!! My IP address displayed on my MacBook is in 
the 10.0.0.0/8 range, and ARIN website can't determine my IP address either.

Joe

Sent from my iPhone

On Apr 6, 2013, at 9:33 PM, Joshua Smith juice...@gmail.com wrote:

 Very interesting indeed. Way to do the right thing here Verizon. This may be 
 the first time I've been happy to be a Comcast customer. 
 
 -- 
 Josh Smith
 kD8HRX
 
 email/jabber: juice...@gmail.com
 Phone: 304.237.9369(c)
 
 Sent from my iPad
 
 
 On Apr 6, 2013, at 9:24 PM, cb.list6 cb.li...@gmail.com wrote:
 
 Interesting.
 
 http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm

Re: Verizon DSL moving to CGN

2013-04-07 Thread Tore Anderson

* Mikael Abrahamsson

 Otoh, ARIN isn't exhausted yet so getting IPv4 addresses there should
 still be a lot cheaper than doing CGN?

From what I hear several ISPs in the ARIN region prefer to obtain
second-hand IPv4 addresses (or deploy CGN boxes) over requesting
addresses directly from ARIN, and the reason is that ARIN, per policy,
will only give its members addresses to cover three months' worth of
consumption, and that this period is simply too short for the allocation
to be operationally useful, especially for large organisations.

I have an anecdote to share here: A while back, a techie from a large
organisation in the RIPE region told me that from their point of view,
the RIPE NCC was effectively depleted once they implemented the
three-month period for allocations on the 1st of July 2011, because they
needed more than three months to actually put a new allocation in
production - hence they couldn't justify anything any longer.

When transferring, on the other hand, ARIN's policies allows for
obtaining up to 24 months' worth of space. This gives longer-term
operational predictability, which may easily justify the cost of the
addresses themselves. Same thing goes for deploying CGNs instead - the
organisation is then free to plan as far ahead as it feels like, without
being constrained by ARIN policies. That has a value, possibly more than
the cost of the CGN boxes themselves.

Tore

Re: Verizon DSL moving to CGN

2013-04-07 Thread Justin M. Streiner


On Sat, 6 Apr 2013, Derek Ivey wrote:

It would be nice to get an update from them regarding their IPv6 plans. Their 
IPv6 support page still says they will start deploying 3Q12 :(.


I've been trying to get some information from internal contacts, but so 
far, no go.


jms

Re: Verizon DSL moving to CGN

2013-04-07 Thread Randy Bush

 Would you be less upset if there was IPv6 access and CPE based DS Lite

ds lite, nat in the core and cpe forklift.  one of the worst mechanisms.

randy

Re: Verizon DSL moving to CGN

2013-04-07 Thread Owen DeLong


On Apr 7, 2013, at 00:31 , Mikael Abrahamsson swm...@swm.pp.se wrote:

 On Sun, 7 Apr 2013, Fabien Delmotte wrote:
 
 CGN is just a solution to save time, it is not a transition mechanism 
 through IPv6
 At the end (IPv6 at home) you will need at list :
 Dual stack or NAT64/ DNS64
 
 CGN doesn't stop anyone deploying dual stack. NAT64/DNS64 is dead in the 
 water without other mechanisms (464XLAT or alike).
 

True... But... Resources deploying/maintaining all of these keep IPv4-limping 
along technologies are resources taken away from IPv6 deployment.

 My point is that people seem to scoff at CGN. There is nothing stopping 
 anyone putting in CGN for IPv4 (that has to be done to handle IPv4 address 
 exhaustion), then giving dual stack for end users can be done at any time.
 

Not really...

 Face it, we're running out of IPv4 addresses. For basic Internet 
 subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a 
 completely different problem that has little bearing on CGN or not for IPv4. 
 DS-Lite is also CGN, it just happens to be done over IPv6 access. MAP is also 
 CGN.
 

No, it really isn't. Sufficient IPv6 deployment at the content side would 
actually allow the subscriber side to be IPv4 or dual-stack for existing 
customers with new customers receiving IPv6-only. The missing piece there is 
actually the set-top coversion unit for IPv4-only devices. (Ideally, a dongle 
which can be plugged into the back of an IPv4-only device with an IPv6-only 
jack on the other side. Power could be done a number of ways, including POE 
(with optional injector), USB, or other.

 I'm ok with people complaining about lack of IPv6 deployment, but I don't 
 understand people complaining about CGN. What's the alternative?

IPv6 deployment _IS_ the alternative. They are not orthogonal.

Owen

Re: Verizon DSL moving to CGN

2013-04-07 Thread Oliver Garraux

If I'm an ISP deploying a network for users today, I effectively have to
provide some mechanism to allow those users to get to IPv4 only content.
 There is way too much stuff out there that is IPv4 only today.

Yes, content providers should provide IPv6 accessbut if I'm an ISP, I
can't really control that aspect.  If I provide users with a service that
isn't able to connect to 80% of websites (to say nothing of VPN's,
corporate email services, etc, that people may need), I'm not going to have
a whole lot of business.

Now - I completely agree that ISP's must start deploying IPv6 natively.
 Legacy equipment that doesn't support IPv6 is not an acceptable
excuseits just evidence of poor decision making and short-sighed
purchasing decisions.  CGN clearly isn't ideal and doesn't mitigate the
need for native IPv6 connectivity.  But right now, native IPv6 connectivity
is still not a substitute for some level of IPv4 connectivity, even if its
CGN'ed.

Oliver

-

Oliver Garraux
Check out my blog:  blog.garraux.net
Follow me on Twitter:  twitter.com/olivergarraux


On Sun, Apr 7, 2013 at 4:06 PM, Owen DeLong o...@delong.com wrote:


 On Apr 7, 2013, at 00:31 , Mikael Abrahamsson swm...@swm.pp.se wrote:

  On Sun, 7 Apr 2013, Fabien Delmotte wrote:
 
  CGN is just a solution to save time, it is not a transition mechanism
 through IPv6
  At the end (IPv6 at home) you will need at list :
  Dual stack or NAT64/ DNS64
 
  CGN doesn't stop anyone deploying dual stack. NAT64/DNS64 is dead in the
 water without other mechanisms (464XLAT or alike).
 

 True... But... Resources deploying/maintaining all of these keep
 IPv4-limping along technologies are resources taken away from IPv6
 deployment.

  My point is that people seem to scoff at CGN. There is nothing stopping
 anyone putting in CGN for IPv4 (that has to be done to handle IPv4 address
 exhaustion), then giving dual stack for end users can be done at any time.
 

 Not really...

  Face it, we're running out of IPv4 addresses. For basic Internet
 subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a
 completely different problem that has little bearing on CGN or not for
 IPv4. DS-Lite is also CGN, it just happens to be done over IPv6 access. MAP
 is also CGN.
 

 No, it really isn't. Sufficient IPv6 deployment at the content side would
 actually allow the subscriber side to be IPv4 or dual-stack for existing
 customers with new customers receiving IPv6-only. The missing piece there
 is actually the set-top coversion unit for IPv4-only devices. (Ideally, a
 dongle which can be plugged into the back of an IPv4-only device with an
 IPv6-only jack on the other side. Power could be done a number of ways,
 including POE (with optional injector), USB, or other.

  I'm ok with people complaining about lack of IPv6 deployment, but I
 don't understand people complaining about CGN. What's the alternative?

 IPv6 deployment _IS_ the alternative. They are not orthogonal.

 Owen

Re: Verizon DSL moving to CGN

2013-04-07 Thread William Warren


On 4/6/2013 11:33 PM, Huasong Zhou wrote:

I think Comcast is using CGN too!!! My IP address displayed on my MacBook is in 
the 10.0.0.0/8 range, and ARIN website can't determine my IP address either.

Joe

Sent from my iPhone

On Apr 6, 2013, at 9:33 PM, Joshua Smith juice...@gmail.com wrote:


Very interesting indeed. Way to do the right thing here Verizon. This may be 
the first time I've been happy to be a Comcast customer.

--
Josh Smith
kD8HRX

email/jabber: juice...@gmail.com
Phone: 304.237.9369(c)

Sent from my iPad


On Apr 6, 2013, at 9:24 PM, cb.list6 cb.li...@gmail.com wrote:


Interesting.

http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm
if you are a business customer your modem is actually a business grade 
NAT router.  If they are using CGN(which doesn't make sense as i can 
pull an ipv6 addy here on dhcp) it's either a misconfiguration or 
something else going on.

Re: Verizon DSL moving to CGN

Nope. Comcast is not using any CGN, as much as I know.

Is your MacBook directly connected to the modem or a router? I presume the 
latter.

Cheers,
Rajiv

Sent from my Phone

On Apr 7, 2013, at 11:47 AM, Huasong Zhou huas...@kalorama.com wrote:

 I think Comcast is using CGN too!!! My IP address displayed on my MacBook is 
 in the 10.0.0.0/8 range, and ARIN website can't determine my IP address 
 either.
 
 Joe
 
 Sent from my iPhone
 
 On Apr 6, 2013, at 9:33 PM, Joshua Smith juice...@gmail.com wrote:
 
 Very interesting indeed. Way to do the right thing here Verizon. This may be 
 the first time I've been happy to be a Comcast customer. 
 
 -- 
 Josh Smith
 kD8HRX
 
 email/jabber: juice...@gmail.com
 Phone: 304.237.9369(c)
 
 Sent from my iPad
 
 
 On Apr 6, 2013, at 9:24 PM, cb.list6 cb.li...@gmail.com wrote:
 
 Interesting.
 
 http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm

Re: Verizon DSL moving to CGN

 DS-Lite is also CGN, it just happens to be done over IPv6 access. MAP is also 
 CGN.

Thankfully, MAP is not CGN. Correctly stated, unlike DS-Lite, MAP doesn't 
require any CGN that causes the SP network to put up with the NAT state. This 
means that all the subsequent issues of CGN/DS-Lite no longer apply. 

MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled access. 
MAP makes much more sense in any SP network having its internet customers do 
IPv4 address sharing and embrace IPv6.

Cheers,
Rajiv

Sent from my Phone

On Apr 7, 2013, at 3:33 AM, Mikael Abrahamsson swm...@swm.pp.se wrote:

 On Sun, 7 Apr 2013, Fabien Delmotte wrote:
 
 CGN is just a solution to save time, it is not a transition mechanism 
 through IPv6
 At the end (IPv6 at home) you will need at list :
 Dual stack or NAT64/ DNS64
 
 CGN doesn't stop anyone deploying dual stack. NAT64/DNS64 is dead in the 
 water without other mechanisms (464XLAT or alike).
 
 My point is that people seem to scoff at CGN. There is nothing stopping 
 anyone putting in CGN for IPv4 (that has to be done to handle IPv4 address 
 exhaustion), then giving dual stack for end users can be done at any time.
 
 Face it, we're running out of IPv4 addresses. For basic Internet 
 subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a 
 completely different problem that has little bearing on CGN or not for IPv4. 
 DS-Lite is also CGN, it just happens to be done over IPv6 access. MAP is also 
 CGN.
 
 I'm ok with people complaining about lack of IPv6 deployment, but I don't 
 understand people complaining about CGN. What's the alternative?
 
 -- 
 Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Verizon DSL moving to CGN

Dual-stack in the home networks will stay with us for a long time (beyond 
2020!) until v4-only user devices and v4-only apps get refreshed.

Of course, this doesn't mean that the ISP access needs to stay dual-stack, 
thanks to MAP, 464XLAT etc.

Cheers,
Rajiv

Sent from my Phone

On Apr 7, 2013, at 3:15 AM, Fabien Delmotte fdelmot...@mac.com wrote:

 CGN is just a solution to save time, it is not a transition mechanism through 
 IPv6
 At the end (IPv6 at home) you will need at list :
 Dual stack or NAT64/ DNS64
 
 My 2 cents
 
 On Apr 7, 2013, at 8:42 AM, Mikael Abrahamsson swm...@swm.pp.se wrote:
 
 On Sun, 7 Apr 2013, Christopher Morrow wrote:
 
 I wonder how much more painful just upgrading the dsl plant to support v6 
 would be vs deploying the cgn equipment and funneling users through that :(
 
 IPv6 deployment is not a short term solution to IPv4 address depletion. 
 Would you be less upset if there was IPv6 access and CPE based DS Lite (ie 
 your IPv4 is still CGN:ed, just in a different way)?
 
 CGN is here to stay for IPv4. The solution for long term Internet growth is 
 IPv6.
 
 -- 
 Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Verizon DSL moving to CGN