Subject: [v4v6interim] Comparison document

From: "Dan Wing" <[email-masked]>
Date: Tue, 16 Sep 2008 08:45:06 -0700

We just submitted "A Comparison of Proposals to Replace NAT-PT", which
attempts to summarize and compare APB-Revised, Dual-Stack Lite, NAT444, IVI,
NAT6, NAT64, NAT-PT, and sNAT-PT.

http://www.ietf.org/internet-drafts/draft-wing-nat-pt-replacement-comparison-0
0.txt

-d

_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Rémi Després <[email-masked]>
Date: Tue, 16 Sep 2008 18:58:39 +0200

Dan,
I find the the document as it is very helpful.

But sorry I didn't see earlier that figure 2 is confusing (it shows a 
NAT traversal where there is none).

This would be IMO a better figure:
<<<

                       +---+                             +-------------+
         IPv6 host-----+   |            +----------------+IPv6 Internet|
                       |   +--IPv6------+                +-------------+
      APBPR DS host----+DS |
      ^^^^^^^^^^^^     |CPE|                 +--------+  +-------------+
          IPv4 host----+   +===IPv6 tunnel===+  APBPR +--+IPv4 Internet|
                       +---+                 | tunnel |  +-------------+
                                             |concent.|
                                             +--------+

         |<--------------public v4 (partially in tunnel) ------------> 
                 	|<--local v6-->|<--service provider v6--->|<----public 
v4--->

      Figure 2: APBR-host - tunnel between CPE and APBR tunnel endpoint

Also, but less important, in the text for figures 2 and 3, and in figure 
3 itself, replacing "Softwire" by "APBPR" could be preferable. (APBPR 
tunnel endpoints have specific functions)

RD

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 16 Sep 2008 10:26:39 -0700

I integrated those suggested changes into my in-progress -01 revision of the
document.  Thank you.

-d

> -----Original Message-----
> From: Rémi Després [mailto:[email-masked]] 
> Sent: Tuesday, September 16, 2008 9:59 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [v4v6interim] Comparison document
> 
> Dan,
>                        +---+                             
> +-------------+

---

From: "Mikael Lind" <[email-masked]>
Date: Fri, 19 Sep 2008 17:30:25 -0400

3.1.2 describes the two proposals Dual-stack lite and SNAT as more or less
the same. Even if there is discussion about merging them I still think it
would be worth pointing out in the document that there is a big difference
between the two proposals. 
DS-lite doesn't require a tunnel to be set up in order to function as it
keeps the IPv6 source address as part of the NAT state, much like a NAT-PT.
In the case of SNAT there has to exist a tunnel per user before traffic is
sent as tunnelling and NAT are more or less separate. 

-Mikael

> From: [email-masked] [mailto:v4v6interim-
> [email-masked]] On Behalf Of Dan Wing
> Sent: September 16, 2008 11:45
> To: [email-masked]
> Subject: [v4v6interim] Comparison document
>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 19 Sep 2008 14:56:49 -0700

> From: Mikael Lind [mailto:[email-masked]] 
> Sent: Friday, September 19, 2008 2:30 PM
> To: 'Dan Wing'; [email-masked]
> Subject: RE: [v4v6interim] Comparison document
> 

The 3 authors of SNAT and DS-Lite all told me to collapse the
text of their proposals because they are consolidating the two
proposals.

SNAT uses the tunnel identifier to distinguish each subscriber;
DS-Lite uses the IPv6 address to distinguish each subscriber.  
This is a pretty minor distinction in the overall scheme of
things.   In both cases, the concentration endpoint must be
configured (or otherwise learned, e.g., via a DHCP option)
and in both cases the NAT44 function needs to differentiate
each subscriber (such as VLANs, tunnel ID, or IPv6 
interface) so that subscribers can be given overlapping
IPv4 addresses.

-d

> > attempts to summarize and compare APB-Revised, Dual-Stack 
> Lite, NAT444,
> > IVI,

---

From: Jari Arkko <[email-masked]>
Date: Sat, 20 Sep 2008 09:42:19 +0300

Comments and thoughts on this would be appreciated:

http://tools.ietf.org/html/draft-arkko-townsley-coexistence

"IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios
 
   When IPv6 was designed, it was expected that the transition from IPv4
   to IPv6 would occur more smoothly and expeditiously than experience
   has revealed.  The growth of the IPv4 Internet and predicted
   depletion of the free pool of IPv4 address blocks on a foreseeable
   horizon has highlighted an urgent need to revisit IPv6 deployment
   models.  This document provides an overview of deployment scenarios
   with the goal of helping to understand what types of additional tools
   the industry needs to assist in IPv4 and IPv6 co-existence and
   transition."

Jari and Mark

---

From: "Mikael Lind" <[email-masked]>
Date: Sun, 21 Sep 2008 11:47:27 -0400

The client side might be more or less identical, at least for ip in ip 
tunnels, but the concentrator will be quite different. The DS-lite 
concentrator doesn't need any establishment or preexisting states in order 
to receive and translate packets, as it is all done per session, while the 
SNAT has to to establish and maintain tunnels for all clients at all time.

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 21 Sep 2008 09:24:03 -0700

> Sent: Sunday, September 21, 2008 8:47 AM
> To: Dan Wing; [email-masked]

I am not an expert in tunnels, but it is my understanding that
tunnel establishment is trivial; RFC2003 doesn't require messages
to be exchanged to establish a tunnel.

As for tunnel maintenance, the problem described in Section 5 of 
RFC2003 is due to routers along the tunnel path returning short
ICMP errors.  Since RFC2003 was written, it is my understanding
that most routers return longer ICMP errors.

If I am wrong, I know someone will correct me.  Any such drawbacks
should be described in draft-touch-intarea-tunnels-00.txt and we
will certainly discuss such drawbacks at the interim meeting and
I expect the revised SNAT+DS-Lite draft will discuss the positive
and negative aspects of using IPv4-over-IPv6 versus IPv4-over-tunnel.

-d

---

From: <[email-masked]>
Date: Mon, 22 Sep 2008 18:17:08 +0300

Hi Jari,

After initial reading the document looked good for me.

We are in planning to submit a protocol contribution related to
2.1.2/2.2 and fractional IP addresses mid this week.

Best regards,

	Teemu

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Jari Arkko
>Sent: 20 September, 2008 09:42
>To: [email-masked]
>Subject: [v4v6interim] scenarios
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 22 Sep 2008 16:10:39 +0200

> that most routers return longer ICMP errors.

For IPv6 ICMP messages return as much as they can within 1280 bytes  
worth of IP+ICMPv6+original message, which should be more than  
sufficient for whatever needs to get done.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim