Subject: [BEHAVE] [Fwd: I-D Action:draft-bagnulo-behave-nat64-00.txt]

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 10 Jun 2008 17:05:18 +0200

Hi,

We have submitted the following draft describing NATs for v6 to v4 
translation.

We would very much appreciate comments you may have

Thanks, marcelo

-------- Mensaje original --------
Asunto: 	I-D Action:draft-bagnulo-behave-nat64-00.txt
Fecha: 	Tue, 10 Jun 2008 08:00:02 -0700 (PDT)
De: 	[email-masked]
Responder a: 	[email-masked]
Para: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : NAT64/DNS64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
	Author(s)       : M. Bagnulo, et al.
	Filename        : draft-bagnulo-behave-nat64-00.txt
	Pages           : 27
	Date            : 2008-06-10

NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and
vice-versa.  DNS64 is a mechanism for synthesizing AAAA records from
A records.  These two mechanisms together enable client-server
communication between an IPv6-only client and an IPv4-only server,
without requiring any changes to either the IPv6 or the IPv4 node,
for the class of applications that work through NATs.  They also
enable peer-to-peer communication between an IPv4 and an IPv6 node,
where the communication can be initiated by either end using
existing, NAT-traversing, peer-to-peer communication techniques.
This document specifies NAT64 and DNS64, and gives suggestions on how
they should be deployed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bagnulo-behave-nat64-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 13 Jun 2008 12:30:47 -0700

(as an individual)

I have a few comments about the draft:

* The draft currently only talks of UDP/TCP/ICMP.  It needs to also
  discuss, or at least have placeholeders for,
    - IPSec ESP tunnel mode
    - DCCP
    - SCTP

* Can ASM or SSM multicast be supported with NAT64?

* Should discuss preserving or remarking of DSCP bits across the
  v6/v4 boundary.

* I know NAT-PT discussed an FTP-ALG and I see NAT64 does, too.
  However, in 2008 can we just rely on passive (PASV) support in the
  v6 FTP client and in the v4 FTP server so that NAT64 does not need
  to include an FTP ALG?  I ask because a seemingly significant aspect
  of NAT64 is that there are no v4-initiated connections to v6 hosts;
  non-passive FTP data connections would break that aspect.

I will send my nits separately to the authors.

-d

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
> Sent: Tuesday, June 10, 2008 8:05 AM
> To: Behave WG
> Subject: [BEHAVE] [Fwd: I-D Action:draft-bagnulo-behave-nat64-00.txt]
> 
> Hi,
> 
> 	Title           : NAT64/DNS64: Network Address and 
> Protocol Translation from IPv6 Clients to IPv4 Servers

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 14 Jun 2008 11:02:12 +0200

Hi Dan,

thanks for the comments

see replies in-line

>   discuss, or at least have placeholeders for,
right
actually, the requirements defined in v6ops for v4-v6 translation make 
the last two optional (i.e. SHOULD be supported) and the first one 
(IPSec) must be supported but changes in the hosts are acceptable
So, when doing this document we focused in the critical features, 
TCP/UDP/ICMP support and we left out the SHOULDs. I mean, at thsi stage 
we were exploring if we could make the basic features work, along with 
dnssec and avoiding translated connectivity when native connectivity is 
available, which are the reuqired features.

We could add the support for DCCP and SCTP if people feel it is needed 
in this document or we could make the analysis to make sure the nat64 
allows its support and define it somewhere else, i am ok either way

W.r.t. IPSec, it will require to change the end hosts (at least one), so 
i was thinking to define the changed required to the hosts in a 
different spec (while making sure that the nat64 as defined is 
compatible with that). This is the approach used in v4 nats, but again i 
don't have a strong opinion on this neither
> * Can ASM or SSM multicast be supported with NAT64?

similarly to the dccp and sctp, the requirement document says that this 
should be supported and the previous comments apply

there are also other protocols, like MIP that are in the same situation
> * Should discuss preserving or remarking of DSCP bits across the
good point
haven't heard any discussion about this before, so i guess the issue is 
open.
I think it would make sense to preserve them

>   non-passive FTP data connections would break that aspect.
we had this discussion among the authors, and Phil mentioned that

draft-ietf-behave-tcp says:
  REQ-6:  If a NAT includes ALGs that affect TCP, it is RECOMMENDED
      that all of those ALGs (except for FTP [RFC0959]) be disabled by
      default.

   Justification:  The intent of this requirement is to prevents ALGs
      from interfering with UNSAF methods.  The default state of a FTP
      ALG is left unspecified because of legacy concerns: as of writing
      this memo, a large fraction of legacy FTP clients do not enable
      passive (PASV) mode by default and require an ALG to traverse
      NATs.

and then we decided to keep it and see what the wg feeling was.

i am personally all for dropping this...

Regards, marcelo

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 14 Jun 2008 11:04:36 -0700

> Sent: Saturday, June 14, 2008 2:02 AM
> To: Dan Wing
> Cc: 'Behave WG'
> Subject: Re: [BEHAVE] comments on draft-bagnulo-behave-nat64-00
> 
> Hi Dan,
> 
> thanks for the comments
> 
> see replies in-line
> 
> Dan Wing escribió:
> > (as an individual)
> >
> actually, the requirements defined in v6ops for v4-v6 
> translation 

draft-bagnulo-behave-nat64-00 does not cite
draft-ietf-v6ops-nat64-pb-statement-req-00 as its source of 
requirements.  If that is what nat64 is trying to meet, it
would be useful to cite the v6ops problem statement document.

> make the last two optional (i.e. SHOULD be supported)
> and the first one 

draft-ietf-v6ops-nat64-pb-statement-req-00 says:

   R11: IPsec support.

   The translator MUST support communication between IPv4 node and IPv6
   node using UDP Encapsulation of IPsec ESP Packets as defined in
   [RFC3948] as applicable.  RFC3948 should be interpreted as with the
   IPv6 side on the IPv6-IPv4 translator being the IPv4 private side of
   the conventional NAT.  IPsec support MAY require updating also the
   IPv4 side.

For approximately the last 8 years, v4v4 NAPTs have included "IPsec
Passthrough", which allows IPsec ESP tunnel mode to work with those
NAPTs, without any host changes whatsoever.  This works for IPsec
connections initiated from the 'inside' of the NAPT.  NAT64 can 
support this same functionality as this long-standing v4v4 NAPT 
feature, and do so without host changes.

> allows its support and define it somewhere else, i am ok either way

Ok.

> W.r.t. IPSec, it will require to change the end hosts (at 
> least one),

I do not believe that is necessary.

> so 
> haven't heard any discussion about this before, so i guess 
> the issue is open.

I see the v6ops NAT64 requirement document is silent on DSCP.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 16 Jun 2008 12:21:27 +0200

below...

right

we were planning to include a section describing how nat64 complies with 
the requirements, but didn't make it for the first version (but we 
shoudl have probably include a placeholder at least...)

> feature, and do so without host changes.
right, but my understanding is that in the nat64 case, we will need some 
host support
I mean, in the nat64 one side is v4 only and the other side is v6 only
the packet inside the IPSec tunnel will have an IP header, that cannot 
be translated cause is protected by IPSec
so, it is hard that this will work without v6 only host completely 
lacking v4 support and v4 only node completely lacking v6 support, if 
you see my point

So, it seems that the easier modification is for the v6 only node to 
impleent a v4 stack, and can parse the v4 header inside the ipsec tunnel
But this is considered host changes

in addition to that, we need to understand how to provision the v4 
configuration for the v6 node that is in a v6 only network (i.e. the v4 
address and the mask)

so i think more analysis is needed and i am not sure if the host 
modifications should fit in the nat64 document
> I see the v6ops NAT64 requirement document is silent on DSCP.

ooops

this was mentioned in the phily meeting so it should be there

will be there in the next version of the document

regards, marcelo

>>>   to include an FTP ALG?  I ask because a seemingly 
>>>       
>> significant aspect
>>     
>>>   of NAT64 is that there are no v4-initiated connections to 
>>>       
>> v6 hosts;
>>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Jun 2008 10:03:50 -0700

> right, but my understanding is that in the nat64 case, we 
> will need some host support

v4/v6 inside of the IPsec tunnel is not a NAT64 issue, rather it is an IPsec
issue.  And yes the client host or the server host will have to understand
that just because the packet was sent via v6 (in the IPsec client's view) or
received via v4 (in the IPsec server's view), has no bearing on the IP family
of the packets inside the tunnel.

What I was bringing up, though, is my desire for NAT64 to describe how IPsec
ESP tunnel-mode can be supported in NAT64, without the IPsec ESP tunnel-mode
needing to be sent over UDP.  That is, for NAT64 to describe and standardize
the feature that has been in consumer-grade NATs for ~8 years for v4v4 NATting
of IPsec ESP tunnel mode, and describe IPsec ESP tunnel mode packets being
NATting much the same as the current text describes TCP, UDP, and ICMP.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 16 Jun 2008 19:36:32 +0200

> NATting much the same as the current text describes TCP, UDP, and ICMP.

right
i agree that needs to be included in the nat64 document
but i also think that we need a document that explains how this is used 
by the ipsec endpoints and how do they deal with the inner header
makes sense?

regards, marcelo

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Jun 2008 16:52:01 -0700

> by the ipsec endpoints and how do they deal with the inner header

I expect that IPsec ESP tunnel mode does not assume or require the IP family
of the tunneled traffic to have the same IP family of the IPsec tunnel itself.
But if it does then I agree a document needs to be written that describes how
this would work.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 20 Jun 2008 18:37:42 -0700

> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Tuesday, June 17, 2008 4:48 AM
> To: Dan Wing
> Cc: 'marcelo bagnulo braun'; 'Behave WG'
> On 13 jun 2008, at 21:30, Dan Wing wrote:
> 
> >    - DCCP
> 
> I'm not familiar enough with DCCP to say anything definitive, but I  
> don't see any show stoppers there.
> 
> >    - SCTP
> 
> SCTP uses a non-standard checksum which probably can't be updated  
> incrementally, which would be bad for performance for the NAT64 box.  
> Also, there is the address agility which will probably be hard to  
> maintain through NAT. Considering that SCTP is not in wide use it's  
> probably not worth the trouble to make this work through a fairly  
> temporary mechanism like NAT64.
> 
> Why? Any router may change these bits, so presumably a NAT64 
> could, too.

At the request of the ADs, TURN (draft-ietf-behave-turn) includes
a discussion of DSCP.  I expect NAT64 will need to include some
discussion on how a NAT64 is expected to handle DSCP bits.

> Obviously active FTP won't work. PASV is incompatible with IPv6. So  
> the only thing that will work through NAT64 without an ALG is EPSV.  
> Obviously FTP software that supports IPv6 will tend to 
> support EPSV. I  
> have no idea how pervasive EPSV support is in the IPv4 world, though.

Thanks - I had forgotten EPSV was needed for v6.

The intent is for other protocols which embed IP addresses in their
control protocol will need to fend for themselves?  For example, RTSP
and SIP?  This is reasonable, but the document should discuss why
only an FTP ALG is described.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Jun 2008 15:46:55 +1200

> discussion on how a NAT64 is expected to handle DSCP bits.

It isn't hard to define this correctly. There are (non-normative)
practices defined for DSCPs in and out of tunnels in RFC 2983
and section 6 indicates how the arguments apply to translators,
including v4/v6 translators.

The simple version is that if a translator is placed at a diffserv
domain boundary, it can be in series with a diffserv classifier
and marker. Otherwise it can usually just copy the DSCP (which
is carefully defined to have identical semantics for v4 and v6).
But RFC2765 defines this exactly, and there's nothing wrong with
what it says.

     Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 22 Jun 2008 15:19:21 +0200

> discussion on how a NAT64 is expected to handle DSCP bits.

RFC 2765 "Stateless IP/ICMP Translation Algorithm (SIIT)", which is a  
normative reference, says:

          Traffic Class:
                  By default, copied from IP Type Of Service and
                  Precedence field (all 8 bits are copied).  According
                  to [DIFFSERV] the semantics of the bits are identical
                  in IPv4 and IPv6.  However, in some IPv4 environments
                  these fields might be used with the old semantics of
                  "Type Of Service and Precedence".  An implementation
                  of a translator SHOULD provide the ability to ignore
                  the IPv4 "TOS" and always set the IPv6 traffic class
                  to zero.

I think that should be sufficient...

> only an FTP ALG is described.

I believe this was imported from BEHAVE requirements, and the  
reasoning there being that ALGs often end up getting in the way of  
connectivity but FTP was apparently grandfathered in.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 22 Jun 2008 08:51:50 -0700

> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Sunday, June 22, 2008 6:19 AM
> To: Dan Wing

Yes.  Thanks.

> connectivity but FTP was apparently grandfathered in.

Ok.  Thanks.

-d

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 23 Jun 2008 10:55:56 +0300

> Thanks - I had forgotten EPSV was needed for v6.

Typically, you have the IPv6-capable FTP servers on one side. These support 
EPSV for IPv4 as well. And then you have the IPv4-only FTP servers, and they 
don't do EPSV. Both of these types are commonly found on the IPv4 Internet 
today.

Therefore, it might be that some NAT64 implementations to embed an FTP ALG, 
doing EPSV/IPv6 to PASV/IPv4 translation. At the very least, we may want to 
warn about the need to handle of "EPSV ALL" at the ALG level, in that case.

> and SIP?

RTSP/1.0 does not support IPv6 in any way. RTSP/2.0 works a lot like FTP/EPRT, 
using only port numbers.

Pathological protocols like these... I don't really expect them to work 
through NAT64 unless an ICE-like scheme is used, or an application-layer IPv4 
socket API is provided on the end IPv6 node.

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Tue, 24 Jun 2008 12:31:22 -0400

Sorry to be late in commenting here. I just have a few additional  
comments.

>  discuss, or at least have placeholeders for,

Very few NATs today support DCCP or SCTP. In my personal opinion, the  
right way to support these protocols is to carry them over UDP.

> * Can ASM or SSM multicast be supported with NAT64?

I think this could be added, but personally I feel this should be a  
separate document.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Jun 2008 13:33:13 +0200

> RTSP/1.0 does not support IPv6 in any way. RTSP/2.0 works a lot like FTP/EPRT, 

For RTSP 1.0 there are some tricks that can be applied, using domain 
names instead of explicit addresses that makes it possible to handle 
IPv6. However, RTSP 2.0 will have full v6 support. I also expect that we 
can get the NAT traversal solution to help 2.0 work also across a NAT64.

Which to me appears to be what SIP will need to use also.

cheers

Magnus Westerlund
RTSP 2.0 author

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Jun 2008 13:38:36 +0200

Philip Matthews skrev:
> Sorry to be late in commenting here. I just have a few additional comments.
> 

Well, you are talking about placing a NAT in a new architectural 
location compared to where NAT44 classically has existed. Not natively 
supporting SCTP and DCCP seems a direct action to declaring them 
impossible to go forward with.

I am not buying that the new waist of the internet is only UDP. 
Especially not in a case where we are actually talking about something 
that is being designed. Even NAT-PT has very marginal deployment so 
there are little legacy reason for us to taking short-cuts.

Cheers

Magnus Westerlund

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 25 Jun 2008 14:57:22 +0300

Le Wednesday 25 June 2008 14:33:13 ext Magnus Westerlund, vous avez écrit :
> > RTSP/1.0 does not support IPv6 in any way. RTSP/2.0 works a lot like
> > FTP/EPRT, using only port numbers.
>

AFAICT, if someone wants to reach an IPv4-only SIP infrastructure from an 
IPv6-only network, using translation, SIP Outbound is the way. In that case, 
it should "just work", as it should be a plain TCP connection.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 25 Jun 2008 15:07:16 +0300

> impossible to go forward with.

I am still of the technical opinion that DCCP is all the same as TCP 
_when_it_comes_to_NATs_ and (forgotten) UDP-Lite is all the same as UDP. So 
yeah, it is really lame not to support these two if you support TCP & UDP in 
a _new_ box.

SCTP however... Pending a draft-ietf-behave-nat-sctp document, it is not clear 
to me how a "nice" NAT64 box should even handle it.

And would-be future protocols... we would need to predefine which future IP 
protocol numbers will use source/destination ports in the first four bytes, 
and which will not. Then firewalls could be somewhat forward-compatible. For 
NATs, we would also need to define how checksumming will (or won't) be 
affected by port mangling.

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Wed, 25 Jun 2008 10:34:59 -0400

> yeah, it is really lame not to support these two if you support TCP  

My current opinion is that a NAT64 is just another kind of NAT (but  
hopefully better specified!). DCCP and SCTP do not work through most  
existing NATs, so even if we make them work through a NAT64, an  
application will not be able to count on them working end-to-end, and  
will thus have to revert to running them over UDP. Since running DCCP  
over UDP will always work, why do the effort to specify DCCP over UDP  
for NAT64 (except, perhaps, for specialized situations).

- Philip

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 25 Jun 2008 20:04:10 +0200

On 25 jun 2008, at 14:07, Rémi Denis-Courmont wrote:

> and which will not. Then firewalls could be somewhat forward- 
> compatible. For NATs, we would also need to define how checksumming  
> will (or won't) be

So we fix these fields so we know where they are in future protocols.  
Maybe add an extra field for 32-bit alignment? Might as well store the  
packet length there.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 25 Jun 2008 20:04:08 +0200

On 25 jun 2008, at 13:38, Magnus Westerlund wrote:

>> Very few NATs today support DCCP or SCTP. In my personal opinion,  
>> the right way to support these protocols is to carry them over UDP.

> location compared to where NAT44 classically has existed. Not  
> natively supporting SCTP and DCCP seems a direct action to declaring  
> them impossible to go forward with.

Don't forget that NAT64 is just a mechanism to keep existing stuff  
working. A requirement for using NAT64 is IPv6 connectivity, so the  
host concerned should be able to do DCCP and SCTP over IPv6.

I don't think there are any issues with translating DCCP, but SCTP  
will be problematic because of the address management that it does and  
the CRC32 as a checksum which I'm pretty sure can't be updated  
incrementally like the regular checksum in other protocols, so a NAT  
would have to invest much more CPU time into translating SCTP.

> I am not buying that the new waist of the internet is only UDP.

Agree.

On 25 jun 2008, at 16:34, Philip Matthews wrote:

> application will not be able to count on them working end-to-end,  
> and will thus have to revert to running them over UDP. Since running  
> DCCP over UDP will always work, why do the effort to specify DCCP  
> over UDP for NAT64 (except, perhaps, for specialized situations).

But hosts behind a NAT64 are IPv6 hosts which could reasonably expect  
DCCP to work. And if some hosts use DCCP raw and some over UDP, how  
are these hosts going to talk to each other?

No short term hacks in IPv6, please.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 26 Jun 2008 09:44:20 +0300

> Maybe add an extra field for 32-bit alignment? Might as well store the

As a matter of fact, of the 5 port-based IETF transport protocols (DCCP, SCTP, 
TCP, UDP and UDP-Lite in alphabetical order), only one (UDP) has a length 
field.

If we really want to go down that route, we can simply say that NATs MUST NOT 
the "opaque" value (reserved for protocol-specific use):

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Source Port Number        |     Destination Port Number   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Opaque             |            Checksum           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As you hinted in another mail, this will only work if the checksum is 
incrementally modifiable. If it were not, there is not only a CPU consumption 
problem. The NAT would also need to know the checksum coverage, a 
non-starter, I think.

Oh well, I guess I should push a strawman I-D rather than long emails.

-- 
Rémi Denis-Courmont

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 26 Jun 2008 09:32:35 +0200

> As a matter of fact, of the 5 port-based IETF transport protocols  
> (DCCP, SCTP, TCP, UDP and UDP-Lite in alphabetical order), only one  
> (UDP) has a length field.

You did notice that I was being somewhat sarcastic, didn't you?

The length field in UDP is stupid, because the length of the UDP  
segment can be derived from the total packet length which is already  
in the IP header.

> Oh well, I guess I should push a strawman I-D rather than long emails.

You're a bit late: draft-rosenberg-internet-waist-hourglass-00.txt
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Després <[email-masked]>
Date: Thu, 26 Jun 2008 11:23:18 +0200

Hi Iljitsch,

   Thanks for pointing to the Internet-waist-hourglass draft, IMO a 
great one.

   I don't know whether the point I make here will be considered timely,
but it insistently comes to my mind, and may interest some paricipants
in this discussion.

   All problems of checksum adjustments in NATs can disappear with the
DSTM-APBP approach:
   With it, the client host borrows a public-address+port couple for
each of its transport connections, and then exchanges packets E2E using
this couple.
   Where needed the E2E packets are appropriately encapsulated (ref
draft-despres-v6ops-apbp-00.txt).

   APBP servers lend the public-address+port couples.
   They have for this to manage mappings like the NATS have to.
   But they have besides that NO TRANSLATION to perform, only some sort
of encapsulation-decapsulation of E2E packets.

   Many variations of the detailed protocol can be imagined.
   However, a buildup of enough interest in the subject would be
approriate before the burden of a complete design can be borne.

   APBP can be seen as a compatible extension of NAT devices, with the
following payoff:
   - *Transport protocol independence*, in particular SCTP 
compatibility, for upgraded dual stack hosts that communicate via APBP 
supporting ISPs.
   - In ISP infrastructures, improved scalability of APBP servers
compared to that of NATs.

Rémi

> You're a bit late:
draft-rosenberg-internet-waist-hourglass-00.txt

---

From: Philip Matthews <[email-masked]>
Date: Thu, 26 Jun 2008 08:50:45 -0400

On Wed, 25-Jun-08, at 07:33 , Magnus Westerlund wrote:
> IPv6. However, RTSP 2.0 will have full v6 support. I also expect  
> that we can get the NAT traversal solution to help 2.0 work also  
> across a NAT64.
>

I will just note that we (the authors of draft-bagnulo-behave-nat64)  
were careful to make sure that ICE works properly with NAT64. We  
worked a number of ICE examples involving NAT64 to make sure  
everything worked out. In the process, we changed how hairpinning  
worked to ensure hairpinning worked correctly with ICE.

- Philip

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 26 Jun 2008 16:12:28 +0300

> worked to ensure hairpinning worked correctly with ICE.

I think Magnus and I were concerned about the signaling path here. I doubt SIP 
would work properly through a NAT64 _even_ with ICE, _unless_ SIP Outbound is 
used. SIP Outbound will be needed for signaling, while ICE would be needed 
for media.

---

From: Lars Eggert <[email-masked]>
Date: Thu, 26 Jun 2008 16:14:18 +0300

Hi,

(I never got Iljitsch's original email, so I'm replying to Dan's reply.)

>> From: Iljitsch van Beijnum [mailto:[email-masked]]
...
>> incrementally, which would be bad for performance for the NAT64 box.

Not any worse than for a regular NAT44. IMO, a NAT64 should strive to  
support the same set of protocols that a NAT44 supports.

(We currently don't have a spec for NAT'ing SCTP, but once we do, we  
should recommend if for NAT44 and NAT64.)

Lars

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 26 Jun 2008 15:22:56 +0200

> Not any worse than for a regular NAT44.

You mean SCTP over NAT44? Well, sure. But I was more thinking of  
comparing NAT64 (or NAT44) for SCTP with NAT for TCP. The TCP checksum  
can be incrementally updated with a few add and subtract operations,  
while SCTP's CRC32 requires calculating a new CRC32 over the entire  
packet. This will certainly be a performance hit. And the NAT would  
need to understand SCTP's address management.

Considering all that and the fact that SCTP has no deployment to speak  
of, I would leave out SCTP support if I were to implement a NAT64.

---

From: Lars Eggert <[email-masked]>
Date: Thu, 26 Jun 2008 16:27:21 +0300

On 2008-6-25, at 17:34, ext Philip Matthews wrote:
> and will thus have to revert to running them over UDP.

There are no specifications for "running them over UDP".

> Since running DCCP over UDP will always work, why do the effort to  
> specify DCCP over UDP for NAT64 (except, perhaps, for specialized  
> situations).

IMO a well-behaved NAT will translate all our transport protocols,  
irrespective of whether IPv4 or IPv6 is used.

Yes, there aren't many well-behaved NATs out there, but one of the  
motivations behind BEHAVE is to make such specs available such that  
NAT vendors have something to implement.

Once such RFCs are out and appear in RFPs, things might slowly change.  
(Or not, maybe I'm an idealist.)

Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 26 Jun 2008 16:34:11 +0300

Hi,

On 2008-6-26, at 16:22, ext Iljitsch van Beijnum wrote:
> comparing NAT64 (or NAT44) for SCTP with NAT for TCP. The TCP  
> checksum can be incrementally updated with a few add and subtract  
> operations, while SCTP's CRC32 requires calculating a new CRC32 over  
> the entire packet. This will certainly be a performance hit. And the  
> NAT would need to understand SCTP's address management.

Sure, but that SCTP is less translation-friendly than other transports  
is well-known. And there are some proposals in this space, such as  
draft-stewart-behave-sctpnat.

> Considering all that and the fact that SCTP has no deployment to  
> speak of, I would leave out SCTP support if I were to implement a  
> NAT64.

Sure, that's your judgment call as an implementor.

As the standards body that has defined SCTP, however, IMO it behooves  
us to describe how it can be NAT'ed (and what the issues are.)

Lars

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 26 Jun 2008 15:34:37 +0200

Iljitsch van Beijnum skrev:
> packet. This will certainly be a performance hit. And the NAT would need 
> to understand SCTP's address management.

I think you should take a look at SCTP. There are an important 
differences to all the other transport protocols in regards to NAT. 
First, the checksum does not cover any pseudo header as in UDP or TCP. 
Secondly, there is a VTAG which makes it possible to avoid changing 
ports also. Thus, checksum recalculation needs to happen only when you 
really need to change to content of the packet. Which, may be necessary 
for the NAT64 case.

For a proposal on how NAT44 can be done for SCTP please see:

http://tools.ietf.org/html/draft-stewart-behave-sctpnat-03

Cheers

Magnus Westerlund

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 26 Jun 2008 16:36:11 +0300

> worked to ensure hairpinning worked correctly with ICE.

And hmm... Say you have two SIP UAs, one ICE-capable IPv6-only, one 
ICE-capable IPv4-only. Further assume that the SIP signaling path works fine.

For this to work, at least one of the node will need to determine an ICE 
candidate in the other IP world. In fact, I expect the IPv6-only node will 
create and learn one IPv4 mapping, for instance by querying an IPv4 STUN 
server through the NAT64 box. That means the IPv6-only node MUST understand 
IPv4 mapped-addresses within an IPv6 STUN packet:

It might be worth to point this out somewhere so that ICE/STUN implementors 
don't make wrong assumptions. But I fully expect that an IPv6-capable ICE 
stack can cope with this.

Now lets take things a bit further. Both sides sends their candidates to the 
other party. First problem: the IPv6 side probably has IPv6 candidates, that 
the IPv4 side needs to "ignore" properly. Second problem: when the IPv4 side 
sends ICE connectivity checks to the IPv6 side through the NAT64... the IPv6 
side will answer with an IPv6 peer-reflexive mapped address, that the IPv4 
side needs to be able to cope with as well.

Again, I expect IPv6-capable ICE stacks to understand IPv4, but I am not so 
sure about IPv4-only ICE stacks understanding IPv6 addresses...

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 26 Jun 2008 16:02:17 +0200

> First, the checksum does not cover any pseudo header as in UDP or TCP.

Right, I knew that...

http://www.ietf.org/proceedings/08mar/slides/shim6-2.pdf

I'll shut up now.  :-)

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 26 Jun 2008 10:05:54 -0700

... 
> Again, I expect IPv6-capable ICE stacks to understand IPv4, 
> but I am not so sure about IPv4-only ICE stacks understanding 
> IPv6 addresses...

The v4-only ICE endpoints only need to ignore the v6 candidates.  Both v4 and
v6 are part of ICE's grammar, but of course a v4-only host can't do anything
with v6 addresses; similarly, if we extended ICE to include DCCP and there was
a DCCP candidate, a host that does not understand DCCP can do only one thing:
ignore the DCCP candidate.

-d

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 27 Jun 2008 09:29:17 +0300

Le Thursday 26 June 2008 20:05:54 ext Dan Wing, vous avez écrit :
> The v4-only ICE endpoints only need to ignore the v6 candidates.  Both v4
> and v6 are part of ICE's grammar, but of course a v4-only host can't do
> anything with v6 addresses; similarly, if we extended ICE to include DCCP
> and there was a DCCP candidate, a host that does not understand DCCP can do
> only one thing: ignore the DCCP candidate.

Yeah. Basically, you need to ignore candidates of unknown/unsupported types.

I am still worried about the use of IPv6 in the MAPPED-ADDRESS attribute of 
the STUN/ICE connectivity check response.

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 27 Jun 2008 18:00:21 +0200

On Jun 26, 2008, at 8:44 AM, Rémi Denis-Courmont wrote:

> (DCCP, SCTP,
SCTP has a common header which looks different:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Source Port Number        |     Destination Port Number   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Verification Tag                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Checksum                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I need to read the draft-bagnulo-behave-nat64-00, but for nat44 there
is a much better way to do NAT than to adapt the DPC/TCP methods since
SCTP has the verification tag. See draft-stewart-behave-sctpnat-03.txt.
We'll update it to cover multihoming in the next revision...

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Jun 2008 10:26:27 -0700

> the STUN/ICE connectivity check response.

I just re-read section 7.1.2 ("Processing the Response") of
ice-19 and I didn't see where the MAPPED-ADDRESS (or XOR-
MAPPED-ADDRESS) is examined -- rather, only the source IP 
address of the response is examined (section 7.1.2.2, 
"Success Cases").  So even if the (XOR-)MAPPED-ADDRESS 
had an unrecognized address family (IPv7, let's say), it
shouldn't cause havok with ICE connectivity checks.

-d

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 30 Jun 2008 10:39:48 +0300

> shouldn't cause havok with ICE connectivity checks.

| 7.1.2.2.1.  Discovering Peer Reflexive Candidates
|
|    The agent checks the mapped address from the STUN response.  If the
|    transport address does not match any of the local candidates that the
|    agent knows about, the mapped address represents a new candidate - a
|    peer reflexive candidate.

In principles, a very well written ICE stack could cope with unknown address 
families. It could simply assume that a mapped address of unknown family 
always represents a new candidate, and it would never try to use it in an 
updated offer (because it would not know how to spell it in the SDP).

But... to me, this seems unlikely to work unless it has been specifically 
considered by the implementor.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jun 2008 10:01:17 -0700

> updated offer (because it would not know how to spell it in the SDP).

That's a good point.

> But... to me, this seems unlikely to work unless it has been 
> specifically considered by the implementor.

We may very well need a 'ICE implementators guide'.  I recently became aware
of a Microsoft document that includes some aspects of what could be an ICE
implementors guide, <http://msdn.microsoft.com/en-us/library/cc431495.aspx>.

-d