Subject: Re: [Int-area] I-D ACTION:draft-bajko-pripaddrassign-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Feb 2009 14:44:16 +1300

Hi,

I am increasingly puzzled by the basic logic behind the whole family of
port-restricted address sharing proposals. Consider this:

"  It is expected that communication using IPv6 addresses will increase
   during the next few years to come at the expense of communication
   using IPv4 addresses. The Internet should reach a safety point in
   the future, where the number of IPv4 public addresses in use at a
   given time begins decreasing. It is very likely that the IPv4 public
   address pool currently available at IANA will be exhausted before
   the internet reaches this safety point. This creates a need to
   prolong the lifetime of the available IPv4 addresses. "

This reads as though the ISPs have no choice, and there is some
external force over which ISPs have no control, causing IPv6
usage to grow too slowly, and IPv4 usage to grow too quickly.
This is wrong; the choice between growth in IPv4 and growth
in IPv6 is now in the ISPs' own hands. Read on...

The rate at which IPv6 usage increases, given that it is
now technically possible for any ISP to deploy IPv6 as soon as
they want, is mainly limited by

a) the ISP's willingness to deploy IPv6
b) the customers' willingness to update their operating systems
   (for directly connected hosts)
c) the customers' willingness (or the ISP's ability) to update the CPE

(The other big issue, the ability of applications to support IPv6,
seems to be rapidly vanishing, for typical subscriber applications.
And it isn't required in scenarios in which the updated
CPE supports IPv4-over-IPv6 operations for legacy hosts.)

Now, the port-restricted solutions all require

a) the ISP's willingness to deploy port-restricted IPv4
b) the customers' willingness to update their operating systems
   (for directly connected hosts)
c) the customers' willingness (or the ISP's ability) to update the CPE

I don't understand why an ISP would see it as better to deal
with a) and b) or c) in order to prolong the life of IPv4
somewhat, when the stated goal is to wait at most "as long
as it takes for IPv6 to take over the demand for IPv4", which
will require the ISP to deal with a) and b) or c) again. In
fact, if port-restriction works, it will simply make the
wait longer. That's pointless.

Also, it seems like introducing a short-term hack on top of the
existing NAPT hack, knowing that the real solution is inevitable
anyway, is going to duplicate the CAPEX and OPEX costs of
change. Actually, it may be worse, because in addition to
the hidden OPEX costs of NAT, ISPs will pay additional hidden
OPEX costs of port-restriction.

So, what is the technical or economic argument for an ISP to pay
these extra costs, rather than pushing on with IPv6 as fast as
possible?

    Brian

---

From: David Conrad <[email-masked]>
Date: Tue, 17 Feb 2009 19:02:36 -1000

> these extra costs, rather than pushing on with IPv6 as fast as

For one reason, because there is essentially no IPv6 content the ISP's  
customers want to connect to?

For another, because the ISP's customers don't want to/can't change?   
I may be confused: my impression was that the port restriction applied  
on the outside of the CPE NAT box, thus nothing on the inside of the  
CPE NAT would need to change.  If this isn't the case, apologies for  
my confusion.

Regards,
-drc

---

From: Terry Manderson <[email-masked]>
Date: Wed, 18 Feb 2009 16:40:04 +1000

Hi Brian,

> in IPv6 is now in the ISPs' own hands. Read on...

Well, partly. I think the adoption of v6 is in the ISP's customers  
hands. While many forward moving ISPs have deployed v6 to the  
customer, many do not as their current business justification is  
centred on the highest level of customer experience with the lowest  
possible margin. I recall one v6 summit I attended where I spoke to an  
ISP owner who essentially said that one 20 min customer-service call  
(approx value of $40) eroded the profit gained from that customer for  
1 month in the understanding that a customer in general buys a  
'service' and not a v4 or v6 net connection specifically.

Now think of the uncertainty that creates. How many customer service  
calls will be created when all of the affects that we see in the "ipv6  
hour" events hit the customer base? who knows?

Further, while there are many smart engineers out there (and here) who  
do know ipv6 like it is their own, the graduates who are exiting  
universities now (for the most part) have very little v6 education  
from their curriculum. These graduates are what ISPs hire, as people  
like you and I are hideously expensive by comparison. So for many of  
these companies when the answer coming back from their (young?)  
engineering team is "yeah, maybe" and not a "easy with no issues", I  
can see how their willingness to deploy is diluted.

> wait longer. That's pointless.

If ISPs main goal was to deploy v6, then yeah I could be argued that  
way. However ISPs main focus right now is on their shareholders and  
customers and keeping them happy while keeping their creditors at bay  
and still trying to grow the customer base by squeezing as much ROI  
out of their infrastructure as possible without re-tooling, re- 
educating, or any other RnD work that impacts them or their bottom  
line. I can see how many of the simpler path ipv4 based solutions for  
extending the v4 life have appeal. I don't necessarily agree, but hold  
a level of empathy as it immediately provides for more customer  
capacity. And at best right now v6 needs to be dual stacked for any  
decent customer service offering which means it is still limited to  
the existing v4 fabric paradigms.

Cheers
Terry

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Feb 2009 10:23:06 +1300

> customers want to connect to?

But that can only change when the ISPs offer dual stack service
as standard. And it's clear that this is in their long-term interests.
So I want to throw the responsibility right back to them.

> 
> For another, because the ISP's customers don't want to/can't change?  I
> may be confused: my impression was that the port restriction applied on
> the outside of the CPE NAT box, thus nothing on the inside of the CPE
> NAT would need to change.  If this isn't the case, apologies for my
> confusion.

I don't believe that the port restricted solutions can physically work
without the CPE NAT understanding them, unless of course you'd like
to insert another layer of port-restricted NAT outside the CPE NAT.
And we know that double NAT breaks lotsa stuff and will cause lotsa
$40 help-desk calls.

On 2009-02-18 19:40, Terry Manderson wrote:

> Well, partly. I think the adoption of v6 is in the ISP's customers hands.

IMHO, that is becoming less true by the day. Of course, a content provider
has to make a conscious decision to enable IPv6, but as Google is showing
us, the main barrier to doing so is now actually connectivity across the
Internet, and therefore under control of the ISPs. And the same is
true on the client side - the problems (and the source of potential
$40 help desk calls) are caused by gaps in IPv6 routing, not by IPv6
support on the client side. I think has changed significantly in the last
year or so.

...
> And at best right now v6 needs to be dual stacked for any decent customer service offering which means it is still limited to the existing v4 fabric paradigms. 

That's absolutely true, except for the fortunate few doing a
greenfield rollout.

Going backwards slightly in your argument:

> However ISPs main focus right now is on their shareholders and customers and keeping them happy while keeping their creditors at bay and still trying to grow the customer base by squeezing as much ROI out of their infrastructure as possible without re-tooling, re-educating, or any other RnD work that impacts them or their bottom line.

The accountants will always be with us, but my point is that
the specific CAPEX/OPEX for port-restricted solutions is a dead loss,
because it is additional to the costs of the inevitable dual-stack
rollout and is wasted in the long term.

    Brian

---

From: Terry Manderson <[email-masked]>
Date: Thu, 19 Feb 2009 10:56:57 +1000

> So I want to throw the responsibility right back to them.

Here is an alternative view point. The internet as we know it was  
first established internationally in majority by education and  
research institutions. It wasn't until much later in the cycle of the  
interweb that business saw a way to make money for service. With that  
in mind those research institutions have influence. I just took 5  
minutes to do a dig of the NS records of a number of universities to  
see if their domain NS RR set had v6. Surprisingly very few did. Now  
while they (some) may have v6 prefixes routed to them, not having your  
domain delegation implies very little serious uptake. I wonder why  
universities aren't playing hard in this area?

>> hands.

Yes, I would agree that there are gaps in routing. The comparison is  
that, from my count, there are 25290 ASs announcing "stuff" in the v4  
table. There are 738 ASs announcing in v6.

Of those about 170 in v6 land could be loosely called transit  
providers versus about 7500 in v4. Rather telling yes?

> rollout and is wasted in the long term.

I don't see it as a dead loss, remember that dual-stack suffers the  
limitation of the lowest common denominator ie the saturation of  
customers is dual stack is equal to the saturation level in ipv4. So  
ideally the concept might be to grow the saturation metrics of v4 to  
match that of v6 such when dual stack is implemented there exists less  
of a limitation in scale and the v6 paradigm that presents an  
unmolested end-to-end communication flow is the natural preference.

Terry

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Feb 2009 14:35:46 +1300

Agreeing to differ on the main argument, let me respond to this:

> I wonder why universities aren't playing hard in this area? 

Some are. But we have exactly the same problem as Google.
If you resolve www.cs.auckland.ac.nz, you may see an AAAA
record for 2001:df0:0:2001::106 . Or you can just point your
browser at http://[2001:df0:0:2001::106] . It should work if you're
connected to Internet2 or another IPv6-enabled education/research
network. It probably won't work if you're connected to a commercial
IPv6 SP. So, like every other content provider, we risk vanishing
into a black hole by pushing an AAAA record, until the ISPs start
fixing the gaps in v6 routing, and providing v6 transit as a
matter of course.

It's exactly the situation we faced in the 1980s when IPv4 routing
was growing up.

    Brian

---

From: David Conrad <[email-masked]>
Date: Wed, 18 Feb 2009 16:07:45 -1000

Brian,

> as standard. And it's clear that this is in their long-term interests.

Is it?  I suspect part of the issue here is that it is _not_ clear  
that IPv6 is in their long-term interests.  But that's more of a  
philosophical discussion probably not directly relevant here.

> without the CPE NAT understanding them,

Well, yeah.  Perhaps I'm reading the draft wrong (it doesn't really  
speak to operational deployment scenarios and I haven't been following  
closely, so apologies if so), but I had assumed the general case would  
be a CPE NAT doing the DHCP request for a public IP address with the  
port restriction goop in it.  Upstream of the CPE NAT would be routers  
("port range routers" is the term used in the draft) that would have  
policy filters that would forward traffic to the appropriate CPE NAT  
based on the port (with the implication that the DHCP server has some  
way of informing the router as to which interface is associated with  
which port range).

However, to answer your more general question (as to what's the point  
of these shared address solutions), my impression is that they are  
generally one-sided solutions that allow for an ISP or an end user  
site to deploy without requiring the other side (e.g., the 498 of the  
top 500 Alexa sites that haven't deployed IPv6) to do anything.

Regards,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Feb 2009 15:37:46 +1300

On 2009-02-19 15:07, David Conrad wrote:
...
> However, to answer your more general question (as to what's the point of
> these shared address solutions), my impression is that they are
> generally one-sided solutions that allow for an ISP or an end user site
> to deploy without requiring the other side (e.g., the 498 of the top 500
> Alexa sites that haven't deployed IPv6) to do anything.

There's no doubt that problem needs to be solved. The question is
whether this is the best way to solve it. I think we need a solution
that makes it as easy as possible for the sites in question to phase in
v6 piecemeal, and this approach does nothing for that.

    Brian

---

From: David Conrad <[email-masked]>
Date: Wed, 18 Feb 2009 16:44:10 -1000

On Feb 18, 2009, at 4:37 PM, Brian E Carpenter wrote:
>> site

How is this class of proposal different than dual stack?  Or is that  
your point?

Regards,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Feb 2009 16:17:10 +1300

> How is this class of proposal different than dual stack?  Or is that

Yes, something like DS-lite seems more open to the future to me.

   Brian

---

From: <[email-masked]>
Date: Thu, 19 Feb 2009 13:31:30 +0100

Inline,

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of ext David Conrad
>Sent: 18 February, 2009 07:03
>To: Brian E Carpenter
>Cc: [email-masked]
>Subject: Re: [Int-area] I-D ACTION:draft-bajko-pripaddrassign-00.txt
>
>I may be confused: my impression was that the port restriction
>applied on the outside of the CPE NAT box, thus nothing on the
>inside of the CPE NAT would need to change.  If this isn't the
>case, apologies for my confusion.

The port restricted address, as proposed, is handled between supporting DHCP client and DHCP server, which are connected to each other with point-to-point link (physical, or tunneled) to avoid problems with ARP.

If the DHCP server is not capable of delegating port restricted addresses, they are not used (DHCP server ignores option in DHCPDISCOVER that indicates support for port restricted addresses).

If the box running the DHCP client gets a port restricted address from the DHCP server, it may, or may not, implement NAT for devices behind the box (i.e. "CPE" case) or for other protocols & applications running in the box (i.e. "host" case).

Whether this box is called CPE, PC, Phone, or whatever, or whether the box actually plays multiple roles simultaneously, depends on a deployment at hand.

Best regards,

        Teemu

---

From: <[email-masked]>
Date: Thu, 19 Feb 2009 13:33:57 +0100

Hi everybody,

Thank you for your interest in this work.

The Shara BOF contains set of documents. In addition draft-bajko-pripaddrassign please look especially the http://tools.ietf.org/html/draft-boucadair-port-range that describes e.g. use-cases for the option defined in draft-bajko, but also look at http://tools.ietf.org/internet-drafts/draft-levis-behave-ipv4-shortage-framework and http://tools.ietf.org/html/draft-ymbk-aplusp and why not the rest of the shara docs as well: http://trac.tools.ietf.org/bof/trac/wiki

Best regards,

        Teemu

>[mailto:[email-masked]] On Behalf Of ext Brian E Carpenter
>Sent: 18 February, 2009 03:44
>To: [email-masked]
>I am increasingly puzzled by the basic logic behind the whole
>family of port-restricted address sharing proposals. Consider this:
>
>This reads as though the ISPs have no choice, and there is
>some external force over which ISPs have no control, causing
>IPv6 usage to grow too slowly, and IPv4 usage to grow too quickly.
>This is wrong; the choice between growth in IPv4 and growth in
>IPv6 is now in the ISPs' own hands. Read on...
>
>The rate at which IPv6 usage increases, given that it is now
>technically possible for any ISP to deploy IPv6 as soon as
>(The other big issue, the ability of applications to support
>IPv6, seems to be rapidly vanishing, for typical subscriber
>applications.
>And it isn't required in scenarios in which the updated CPE
>supports IPv4-over-IPv6 operations for legacy hosts.)
>
>somewhat, when the stated goal is to wait at most "as long as
>it takes for IPv6 to take over the demand for IPv4", which
>fact, if port-restriction works, it will simply make the wait
>longer. That's pointless.
>
>Also, it seems like introducing a short-term hack on top of
>the existing NAPT hack, knowing that the real solution is
>inevitable anyway, is going to duplicate the CAPEX and OPEX
>costs of change. Actually, it may be worse, because in
>addition to the hidden OPEX costs of NAT, ISPs will pay
>additional hidden OPEX costs of port-restriction.
>
>So, what is the technical or economic argument for an ISP to
>pay these extra costs, rather than pushing on with IPv6 as
>fast as possible?
>
>    Brian
>_______________________________________________
>Int-area mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/int-area
>

---

From: <[email-masked]>
Date: Thu, 19 Feb 2009 13:58:16 +0100

Inline,

>Sent: 19 February, 2009 05:17
>To: David Conrad
>Cc: [email-masked]

In my view the port-restricted addresses are complementing both DS-Lite approach and IPv6:
1) in DS-Lite environment (IPv4-over-IPv6 with CGN), the Carrier Grade NAT entity could also play the role of port-range router for those devices that support it. I.e. there could be those CPEs that tunnel RFC1918 addressed IPv4 packets over IPv6 to CGN for NATting, and there could be hosts (or CPEs) that ask for port-range from the same CGN entity by tunneling DHCPv4 over IPv6 to CGN, and after receiving port-restricted IPv4 address, tunnel IPv4 packets with the public address over IPv6 to CGN for multiplexing (but not for NATting)
2) in native dual-stack environments, port-restricted addresses could be used side-by-side with public IPv6 address. E.g. a following options could be possible for deployments:
-> Public IPv4 address constantly + Public IPv6 address
-> Private IPv4 address constantly + Public IPv6 address
-> Public IPv4 address on-demand + Public IPv6 address (i.e. host to reserve/release IPv4 address only when needed to decrease consumption rates)
-> Public port restricted IPv4 addrress contanstly + Public IPv6 address

As public IPv4 addresses are the ones we are running out of, that is not very suitable approach for everybody in long term.

Private IPv4 addresses have problems as well - some of which are the reasons why DS-Lite is being developed.

IPv4 address on-demand is problematic as well due complexity of hazzling with reservations, and especially if always-on IPv4 apps are common and do require constant address allocation.

Public port restricted IPv4 addresses would save on consumption of full IPv4 addresses, would distribute NAT to edges for better customer control, and I believe it would also enable more efficient NAT traversal solutions (decreased need for sending NAT keep-alives, simpler STUN/TURN/ICE behaviour perhaps).

Best regards,

        Teemu