Subject: [Int-area] mic comments on draft-matsushima-v6ops-transition-experience

From: "Dan Wing" <[email-masked]>
Date: Tue, 29 Mar 2011 15:00:21 +0200

To expand on my comments at the microphone regarding
draft-matsushima-v6ops-transition-experience:

Logging
-------
It is simplistic to say "stateless needs no logging; stateful needs
logging".  It is a continuum from completely random ports to completely
fixed ports.  I described this in February on the BEHAVE list in
http://www.ietf.org/mail-archive/web/behave/current/msg09182.html, where I
wrote:

There is a range of things a CGN can do:

   1. for every outgoing connection, create one mapping.  This is what 
      most people mean by "stateful NAT".
   2. for an outgoing connection, create a "bin" of several mappings
      using random public ports.  Subsequent outgoing connections will
      use ports from the "bin".  When the "bin" is full, a new
      connection causes a new bin to be created.  A bin is smaller or
      equal to the user's maximum port limit.  This is what all
      stateless mechanisms do.
   3. Same as (2), but the ports allocated to a "bin" are consecutive
      public ports.  

The problem is that a CGN can be implemented, or configured, to do (1) or
(2).  Thus, a CGN can have the exact same logging characteristics that are
being attributed to stateless solutions.

Routing Optimization
--------------------
The routing optimization only works if is no IPv4 address overlap.  But of
course there will be IPv4 address overlap.  Here is how the routing
optimization outright fails -- Alice wants to communicate with Bob.  But she
will instead be route-optimized to Carol:

                          Internet 
                     /               \
                   /                   \
                 /                       \
        Stateless address            Stateless address
          sharing device              sharing device
            /       \                       |
           /         \                      |
          /           \                     |
        CPE           CPE                  CPE
         |             |                    |
      Alice          Carol                 Bob
     192.0.2.1      192.0.2.2             192.0.2.2
     
This occurs because Alice, being an IPv4-only device, only has Bob's IPv4
address.  Alice does not know Bob's unique IPv6 address.

-d

---

From: Alain Durand <[email-masked]>
Date: Tue, 29 Mar 2011 06:31:44 -0700

> Routing Optimization

Expending on this and my comment on the mic. Routing un-optimization in a stateful solution is really a function of where the NAT is located in the network.
For example, if the NAT is implemented on the layer 3 access concentrator, you have route optimization.

Alain.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 29 Mar 2011 15:42:06 +0200

> -----Original Message-----
> From: Alain Durand [mailto:[email-masked]]
> Sent: Tuesday, March 29, 2011 3:32 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [Int-area] mic comments on draft-matsushima-v6ops-
> transition-experience
> 
> 

I think I'm wrong; they would have different IP address + port ranges, so
the route optimization _does_ work.  Sorry.

> Expending on this and my comment on the mic. Routing un-optimization in
> a stateful solution is really a function of where the NAT is located in
> the network.
> For example, if the NAT is implemented on the layer 3 access
> concentrator, you have route optimization.

Yes - deploy more (smaller) NATs instead of one (large) NAT.

-d

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 29 Mar 2011 06:43:47 -0700

Today at the meeting, there was no time for my presentation.
There was however an earlier presentation that showed an
incomplete analysis of stateful vs stateless approaches.
For completeness, this analysis should examine IRON and
its associated technologies RANGER, VET, SEAL and ISATAP.

In addition to ISP deployments, IRON and its kin uniquely
address an endless variety of use case scenarios which are
not well covered by other technologies. RANGERS presents
use case analysis that clearly shows IRON and its kin to
be widely applicable. 

Thanks - Fred
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Mar 2011 14:55:44 +0000

>> will instead be route-optimized to Carol:

This is a transition mechanism, not a full solution.  If Alice wants to talk to Bob, she should consider using IPv6.  Indeed, her inability to communicate with Bob over IPv4 could easily be described as a feature.

Furthermore, if Alice and Bob were both behind NATs, communication between them would be similarly problematic.  A fairly thoroughly-realized kludge does exist which works in some cases, but it definitely breaks under at least one CGN deployment with which I have painful experience.

The bottom line is that transition mechanisms are not, and should not be, held to the same standards as native internet protocols; if it were, we would have to make the transition to IPv6 through a flag day.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 29 Mar 2011 08:02:23 -0700

Hi Ted, 

> The bottom line is that transition mechanisms are not, and 
> should not be, held to the same standards as native internet 
> protocols; if it were, we would have to make the transition 
> to IPv6 through a flag day.

I don't think it is right to equate "incremental deploymnet"
with "transition mechanism". IRON is both incrementally
deployable and a widely applicable long-term solution.

Thanks - Fred

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Mar 2011 15:23:20 +0000

> deployable and a widely applicable long-term solution.

I didn't mention IRON—I was referring specifically to the draft mentioned in the subject line.

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 29 Mar 2011 17:47:15 +0200

> Yes - deploy more (smaller) NATs instead of one (large) NAT.

When the NAT function is implemented in that device, routing would be still un-optimized 
unless outer header is directly destined to the CPE.

--satoru

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 29 Mar 2011 08:59:11 -0700

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Satoru Matsushima
> Sent: Tuesday, March 29, 2011 8:47 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [Int-area] mic comments 
> ondraft-matsushima-v6ops-transition-experience
> 

IRON borrows on a concept known as Correspondent Access
Router (CAR) that was proposed within the mobility domain
many years ago. If all CPEs are within the same IPv4
addressing region, then each CPE can be a CAR unto itself
and route optimization is directly CPE-to-CPE.

If there are NATs between the CPEs, however, then each CPE
would associate with a close-by CAR on the public side of
the NAT, which is really just an ordinary Server. Then, route
optimization would be from the near CPE to the Server of the
far CPE. The route optimization is asymmetric, so in the reverse
direction it would be from the far CPE to the Server of the
near CPE. So, we have both nearly-optimal routes and NAT
traversal supported when there are NATs in the ISP network.

Fred

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 30 Mar 2011 10:38:10 +0200

> From: Satoru Matsushima [mailto:[email-masked]]
> Sent: Tuesday, March 29, 2011 5:47 PM
> To: Dan Wing
> Cc: Satoru Matsushima; 'Alain Durand'; [email-masked]
> When the NAT function is implemented in that device, routing would be
> still un-optimized unless outer header is directly destined to the CPE.

I don't understand what that means.  If you are saying that traffic
between two subscribers, behind the same NAT, has to go up to that
NAT -- yes, I agree that's true in many cases (but not true with
Skype's NAT traversal, nor with ICE's NAT traversal).

-d

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 30 Mar 2011 10:51:43 +0200

> Skype's NAT traversal, nor with ICE's NAT traversal).

The inner destination address of course should be the target CPE.
My point is that how about outer destination address in that case.
I think that it would be pointed gateway's address.

--satoru

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 30 Mar 2011 11:03:31 +0200

> Sent: Wednesday, March 30, 2011 10:52 AM
> To: Dan Wing
> >>>> Expending on this and my comment on the mic. Routing un-
> optimization
> >> in
> >>>> a stateful solution is really a function of where the NAT is
> located
> >> in
> >>>> the network.

Sorry, I still don't follow.  Here is some ASCII art.  Please edit 
it as necessary and describe which party is talking to which other 
party:

                   Internet
                   /      \
                 /          \
        carrier NAT        carrier NAT
       /          \         /        \
      CPE         CPE     CPE        CPE
       |           |       |         /  \
     Alice        Bob     Carol    Ted  Jim

-d

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 30 Mar 2011 02:21:38 -0700

Hi Dan,

> it as necessary and describe which party is talking to which other 

The IRON solution does the following:

                   Internet
                   /      \
           S1     /        \   S2
        carrier NAT        carrier NAT
       /          \         /        \
      CPE         CPE     CPE        CPE
       |           |       |         /  \
     Alice        Bob     Carol    Ted  Jim

So, when Alice wants to talk to Ted, Alice's CPE forwards
the packets directly to S2 without involving S1. S2 then
forwards them to Ted's CPE while traversing Ted's CGN.

In the reverse direction, when Ted sends return packets back
to Alice, Ted's CPE forwards them directly to S1 without
involving S2. S1 then forwards them to Alice's CPE while
traversing Alice's CGN.

In both cases, S1 and S2 can be optimally placed if they
share the same platform and perhaps even the same code
base as the CGNs.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 30 Mar 2011 04:15:49 -0700

Hi Dan,

Let me try again:

                        GW1
                     Internet
                     /      \
                    /        \
          -- CGN1--           -- CGN2 --
         /          \         /        \
        CPE         CPE     CPE        CPE
         |           |       |         /  \
       Alice        Bob     Carol    Ted  Jim

Looking at this again, let's say that the CGNs act as an ISATAP
advertising router on their CPE-facing interfaces and act as an
ISATAP non-advertising router on their Internet facing interfaces.
So, when Alice wants to talk to Bob, Alice's CPE acts as an ISATAP
client and bounces its initial packets off CGN1 to reach Bob's CPE.
That leaves a triangular route Alice_CPE->CGN1->Bob_CPE, so CGN1
initiates an AERO route optimization so that Alice_CPE can talk
directly to Bob_CPE.

Now, when Bob wants to talk to Ted, Bob_CPE ISATAPs its way
over to CGN1, which then ISATAPs its way over to GW1 which is
a gateway out on the Internet. GW1 knows that Ted is located
behind CGN2, so it ISATAPs the packets to CGN2 which in turn
ISATAPs them over to Ted. But, that again leaves the triangular
route CGN1->GW1->CGN2, so GW1 initiates an AERO route
optimization so that CGN1 can talk directly to CGN2

All that is required is that the CGNs and GWs become ISATAP
routers. The CPEs would do well to become ISATAP routers
also, but a device inside the EUN could use a NAT-busting
tool like VET/SEAL if the CPE can't be upgraded.

Thanks - Fred