Subject: Re: [Softwires] Call for agenda items

From: Shishio Tsuchiya <[email-masked]>
Date: Thu, 01 Mar 2012 22:47:10 +0900

Alain and Yong
I would like to request time slot for 6rd mib draft.
http://tools.ietf.org/html/draft-cai-softwire-6rd-mib-01

Regards,
-Shishio

(2012/03/01 0:16), Alain Durand wrote:
> If you intend to present in Paris, please send Yong and I a request by 3/7.
> 
> - Alain.
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 2 Mar 2012 13:42:55 -0600

Hi Chairs,

I would like to present my draft on 6rd multicast

http://tools.ietf.org/html/draft-sarikaya-softwire-6rdmulticast-02

Thank God 6rd does not have two names :-).

Regards,

Behcet

---

From: Rémi Després <[email-masked]>
Date: Sat, 3 Mar 2012 15:08:56 +0100

> If you intend to present in Paris, please send Yong and I a request by 3/7.

I plan to send, in a few days, an updated version of draft-despres-softwire-stateless-analysis-tool.
While -00 was up to date for the Beijing interim meeting, this one will be in line with the latest MAPT, MAP-E and 4rd documents.

I would like a time slot for its presentation.

Thanks,
RD

---

From: Qiong <[email-masked]>
Date: Sun, 4 Mar 2012 12:04:17 +0800

Dear Chairs,

On behalf of our co-authors, I would like to have a time slot for our
merged version of lightweight 4over6
(http://www.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-05.txt)
and another deployment document coming soon.

Thanks in advance!

Best wishes

Qiong

---

From: Qiong <[email-masked]>
Date: Tue, 6 Mar 2012 01:36:56 +0800

Dear Chairs,

With the newly published map-d document, we also would like to apply for a
slot on:
http://www.ietf.org/id/draft-mdt-softwire-map-deployment-00.txt

Thanks in advance!

Qiong

On Thu, Mar 1, 2012 at 1:09 AM, Ole Trøan <[email-masked]> wrote:

> Chairs,
> on behalf of the MAP design team I would like to request a set of slots to
> present the results of the DT effort.
>  draft-mdt-softwire-mapping-address-and-port-03
>  draft-mdt-softwire-map-dhcp-option-02
>  draft-mdt-softwire-map-encapsulation-00
>  draft-mdt-softwire-map-translation-00
>
> cheers,
> Ole
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 5 Mar 2012 22:33:14 +0100

Hello all,

The new version of the unified 4rd proposal is now available at: 
http://tools.ietf.org/html/draft-despres-softwire-4rd-u-04

A summarized comparison of its features with those of MAP-T and MAP-E is about to be posted in draft-despres-softwire-stateless-analysis-tool-01. 

All questions and comments are most welcome.

Regards,
Remi, Reinaldo, Jacni, Yiu

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 5 Mar 2012 15:57:23 -0600

Hi Remi,

Why is this draft informational?

Behcet

---

From: Naoki Matsuhira <[email-masked]>
Date: Tue, 06 Mar 2012 14:14:05 +0900

Hi, Alain and Yong,

I would like to present SA46T interoperability test results.

5min is enough.

Naoki Matsuhira

On Wed, 29 Feb 2012 07:16:38 -0800

---

From: Rémi Després <[email-masked]>
Date: Tue, 6 Mar 2012 07:46:51 +0100

> Why is this draft informational?

An enormous typo!!!
Will for sure be corrected in -05.
Thanks,
RD

---

From: GangChen <[email-masked]>
Date: Tue, 6 Mar 2012 18:09:54 +0800

Hello Remi,

Here are few comments for the draft.
Generally speaking, I'm not sure always carrying fragmentation header
in 4rd domain is a good idea.
Since the receiver always treat that as regular fragments.
That means it tries to reassembly on the BRs and cause some potential risks.
Some analysis is in draft-gont-6man-ipv6-atomic-fragments-00.txt

Secondly, -04 added NAT64+ parts.
If I understood correctly, there are no additional requirements for NAT64 boxes.
The only change is to add NAT64+ mapping rule into the domain.
I guess the intention is to let 4rd-u become friendly to NAT64, since
some operators already deployed it.
IMHO, that seems unnecessary. NAT64 is another standalone system.
4rd-U could naturally coexist with NAT64 by taking proper routing planning.
And, you have a good designing on V bits.
There should be no additional works requested to make these two sets
into unified one.
Besides, I guess NAT64+ mapping rule in some sense would do same thing
in I-D.ietf-behave-nat64-discovery-heuristic

Going into more detailed, I guess there are some editorial suggestions.
In Table 2:
I guess the field of IDENTIFICATION is missing

In R-5, there is term "Domain-IPv6-suffix". I guess it should be "Rule
IPv6 suffix"
In R-7, it uses the indicator of k. I guess that is different meaning
with k in R-5?
In Table 3, at the eighth column, it should be N-N-Y. Otherwise, it
would be duplicated with sixth column
I might back with more comments after my second review.
Many thanks

Gang

2012/3/6, Rémi Després <[email-masked]>:
> A summarized comparison of its features with those of MAP-T and MAP-E is
> about to be posted in draft-despres-softwire-stateless-analysis-tool-01.
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 6 Mar 2012 11:59:24 +0100

Hi Gang,

Thanks a lot for for the quick and detailed review.
More comments below.

> That means it tries to reassembly on the BRs and cause some potential risks.

A receiver that receives a fragment header showing that the packet is compete (Offset=O, M=0) has no reassembly to perform.
No new risk is therefore introduced.
 
> Some analysis is in draft-gont-6man-ipv6-atomic-fragments-00.txt

Note that in the 4rd case, the only destinations of Tunnel packets are CEs or BRs (or also NAT64+ as discussed below).
No conflict can exist with hosts that might have a provisional difficulty with a received fragment header having Offset=0 and M=0. 

> If I understood correctly, there are no additional requirements for NAT64 boxes.

Well, NAT64 boxes remain what they are.
Any host can use BIH to look like an IPv6-only host in the NAT64 although it has a dual stack.

But the advantage of 4rd tunneling over RFC6145 double translation is better IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future protocols that may use the TCP checksum algorithms)
For an ISP to extend this advantage to its stateful NAT64, it need to be 4rd aware (become a NAT64+).
NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address (with a V octet instead of a "u" octet), use the 4rd header mapping instead of RFC6145 translation.  

> some operators already deployed it.

It is to extend advantages of full transparency of header mapping to ISPs that deploy stateful NAT64s.

> in I-D.ietf-behave-nat64-discovery-heuristic

Only almost the same thing, a MAP64+ mapping rule must be announced ONLY with NAT64s that are upgraded to be NAT64+s.

> I guess the field of IDENTIFICATION is missing

Not understood:

+---------------------+-----------------------------------------+
| IPv4 FIELDS         | VALUES SET AT DOMAIN EXIT               |
+---------------------+-----------------------------------------+
   ...
| Identification      | IPv4 ID                                 |
  ...
                             Table 2

> In R-5, there is term "Domain-IPv6-suffix". I guess it should be "Rule

Yes, thanks.

> In R-7, it uses the indicator of k. I guess that is different meaning

Yes
Was supposed to be clear enough, but will replace k by s in R-5, no problem.
 
> would be duplicated with sixth column

Good catch, thanks.

> I might back with more comments after my second review.

Kind regards,
RD

---

From: Peng Wu <[email-masked]>
Date: Wed, 7 Mar 2012 00:04:15 +0800

Dear Chairs,

We would like to present two drafts:Public 4over6 & softwire mesh mib

https://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/
https://datatracker.ietf.org/doc/draft-cui-softwire-mesh-mib/

Thanks!

//Email account switching, apologize for the possible duplication...

--Peng Wu

---

From: GangChen <[email-masked]>
Date: Wed, 7 Mar 2012 15:33:39 +0800

2012/3/6, Rémi Després <[email-masked]>:
> A receiver that receives a fragment header showing that the packet is
> compete (Offset=O, M=0) has no reassembly to perform.

I guess that meet the definition of so-called "atomic fragment". It's
better to involve some discussions with 6man

> Note that in the 4rd case, the only destinations of Tunnel packets are CEs
> or BRs (or also NAT64+ as discussed below).
> No conflict can exist with hosts that might have a provisional difficulty
> with a received fragment header having Offset=0 and M=0.

How about the two CPE sharing one IPv4 address in hub&spoke mode?
Are there some risks if CPEs send packages with identical ID in IPv6
fragmentation header?

> But the advantage of 4rd tunneling over RFC6145 double translation is better
> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future protocols that may
> use the TCP checksum algorithms)
> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address (with a V
> octet instead of a "u" octet), use the 4rd header mapping instead of RFC6145
> translation.

I perfer to leave NAT64 out of scope.
Such transparency could be achieved by whther to add fragmentation header.
Anyway, let's hear some comments from the group

> Only almost the same thing, a MAP64+ mapping rule must be announced ONLY
> with NAT64s that are upgraded to be NAT64+s.

>> I guess the field of IDENTIFICATION is missing
Ok. I missed that. This comment is withdrawed

BRs

Gang

---

From: Rémi Després <[email-masked]>
Date: Wed, 7 Mar 2012 11:53:33 +0100

Gang,

Le 2012-03-07 à 08:33, GangChen a écrit :

> I guess that meet the definition of so-called "atomic fragment".

Yes, AKA single-fragment packet.
  
> It's

6man needs not being concerned in this particular instance, because the fragment header of single-fragment packets only concerns  4rd-aware nodes (4rd CEs, 4rd BRs, NAT64+s).

Note also that the usual rule which says "be strict in what you send and tolerant in what you receive" is sufficient to imply that all hosts should accept IPv6 packets with fragment header having Offset=O and M=0 (without obligation to send any).

> Are there some risks if CPEs send packages with identical ID in IPv6

Section 5.5.1 of 4rd-u-04 makes it impossible.

> I perfer to leave NAT64 out of scope.

NAT64 as is remains out of scope.
What is in scope is only the possibility to improve IPv4 transparency of NAT64 nodes by using transparent tunneling, instead of double translation, when reached by 4rd CEs (making them NAT64+ nodes).

This new capability, introduced in -04, is derived from the 464XLAT proposal. 
With 464XLAT, IPv4 applications in hosts attached to IPv6-only networks can communicate via NAT64s, but IPv4 transparency has limitations which can be eliminated by upgrading NAT64s to NAT64+ status (a backward compatible evolution). 

> Anyway, let's hear some comments from the group

OK

Thanks,
RD

---

From: Washam Fan <[email-masked]>
Date: Thu, 8 Mar 2012 10:47:01 +0800

Hi Remi,

> What is in scope is only the possibility to improve IPv4 transparency of NAT64 nodes by using transparent tunneling, instead of double translation, when reached by 4rd CEs (making them NAT64+ nodes…

Can I interpret NAT64+ as 4rd BR co-located with NAT64? What justify a
new term NAT64+ invented?

> With 464XLAT, IPv4 applications in hosts attached to IPv6-only networks can communicate via NAT64s, but IPv4 transparency has limitations which can be eliminated by upgrading NAT64s to NAT64+ statu…

In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is?

Thanks,
washam

---

From: Rémi Després <[email-masked]>
Date: Thu, 8 Mar 2012 15:04:49 +0100

> new term NAT64+ invented?

NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64 needs to be upgraded to replace RFC5145 translation by header mapping when IPv6 addresses it deals with are 4rd addresses (have the V octet). 

> In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is?

To take advantage, for customers that are 4rd capable, of better IPv4 transparency than with double translation, the NAT64 MUST be upgraded. 
Naturally, this has no impact on other NAT64 users (e.g. IPv6-only hosts, or dual-stack hosts supporting BIH of RFC6535): they can continue to use the NAT64+ as an ordinary NAT64.

Regards,
RD

---

From: Naoki Matsuhira <[email-masked]>
Date: Fri, 09 Mar 2012 09:39:14 +0900

Hi, Alain and Yong,

I would like to update the title of our presentation request.

Naoki Matsuhira, Ryo Nakamura "SA46T interoperability test report" (5min)

Best Regards,
Naoki Matsuhira

(2012/03/06 14:14), Naoki Matsuhira wrote:
> Alain Durand<[email-masked]>  wrote:
>

---

From: Maoke <[email-masked]>
Date: Fri, 9 Mar 2012 02:14:47 +0000

hi Remi,

sorry but i follow this late. something not clear to me, according to our
earlier discussions.

2012/3/8 Rémi Després <[email-masked]>

> >>>>> If I understood correctly, there are no additional requirements for
> NAT64
> >>>>> boxes.
> >>>>
> >>>> Any host can use BIH to look like an IPv6-only host in the NAT64
> although it
> >>>> has a dual stack.
> >>>>

to clarify my understanding:
1. DF transparency is kept totally in 4rd-U but RFC6145 sacrificies the
DF=1/MF=1 cases
2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 message
directly as IPv6 payload is a wise idea. lack of address consistency
ensurance mechanism (i.e. no header checksum in IPv6 header no
pseudo-header checksum in ICMPv4 message)
3. for the "future protocols", i remember our earlier discussion concluded
that CNP can free the code change with ALREADY KNOWN tcp-checksumed
protocols. am i wrong here?

> >>>> For an ISP to extend this advantage to its stateful NAT64, it need to
> be 4rd
> >>>> aware (become a NAT64+).

questions: 1. NAT64+ here refers to stateful case only, right? 2. for the
IPv4-to-IPv6 directly, how does the 4rd-aware box make decision between
4rd-U pseudo-encapsulation (let me use this term because  i argue it does
not conform to the behavior of encapsulation) and NAT64 translation? (as we
have neither V nor U in the IPv4 addresses).

> >> What is in scope is only the possibility to improve IPv4 transparency
> of NAT64 nodes by using transparent tunneling, instead of double
> translation, when reached by 4rd CEs (making them NAT64+ nodes).
> >
> NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64 needs
> to be upgraded to replace RFC5145 translation by header mapping when IPv6
> addresses it deals with are 4rd addresses (have the V octet).
>
>
> >
> >> With 464XLAT, IPv4 applications in hosts attached to IPv6-only networks
> can communicate via NAT64s, but IPv4 transparency has limitations which can
> be eliminated by upgrading NAT64s to NAT64+ status (a backward compatible
> evolution).
> >>
> >
> To take advantage, for customers that are 4rd capable, of better IPv4
> transparency than with double translation, the NAT64 MUST be upgraded.
>

may i add that it (4rd-U) provides better IPv4 transparency than double
translation but less simplicity in the term of layering architecture than
encapsulation? (here i avoid sticking things on my understanding to
"transparency"). personally i don't think transparency is the most
important reason that generally operators prefer encapsulation rather than
translation. simplicity and clear concept in architecture is the reason. no
matter how much we keep IPv4 information unchanged across the IPv6 domain,
as long as the IPv4 header is destroyed, it is a solution of "translation"
rather than of "encapsulation".

i don't incline to use the term "tunneling" since tunnel could have a
variety of forms, among which encapsulation is one but not the only one.

cheers,
maoke

> Naturally, this has no impact on other NAT64 users (e.g. IPv6-only hosts,
> or dual-stack hosts supporting BIH of RFC6535): they can continue to use
> the NAT64+ as an ordinary NAT64.
>
> Regards,
> RD
>
> >
> > Thanks,
> > washam

---

From: Rémi Després <[email-masked]>
Date: Fri, 9 Mar 2012 09:49:35 +0100

Thanks Maoke for the opportunity to clarify some of the points below.

2012-03-09  03:14, Maoke:

> hi Remi,
> 
> sorry but i follow this late. something not clear to me, according to our earlier discussions.
> 
> 1. DF transparency is kept totally in 4rd-U but RFC6145 sacrificies the DF=1/MF=1 cases
> 2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 message directly as IPv6 payload is a wise idea. lack of address consistency ensurance mechanism (i.e. no header checksum in IPv6 header no pseudo-header checksum in ICMPv4 message)

The 4rd ICMPv4 error message has as only purpose to be delivered to a 4rd-aware node. There, it will be treated as an ICMPv4 error.
It is assumed that no DPI in some middle box will need to interpret ICMPv4 error messages. 

> 3. for the "future protocols", i remember our earlier discussion concluded that CNP can free the code change with ALREADY KNOWN tcp-checksumed protocols. am i wrong here? 

I think you are. As the 4rd-u-04 says (sec 4.4):
"NOTE: This guarantees that, for all protocols that use the same checksum algorithm as TCP, Tunnel packets are valid IPv6 packets, and this independently from where the checksum field is placed for each protocol.  Today, such protocols are UDP [RFC0768], TCP [RFC0793], UDP-Lite [RFC3828], and DCCP [RFC5595].  Should new ones be specified, BRs will support them without needing an update."

> questions: 1. NAT64+ here refers to stateful case only, right?

> 2. for the IPv4-to-IPv6 directly, how does the 4rd-aware box make decision between 4rd-U pseudo-encapsulation (let me use this term because  i argue it does not conform to the behavior of encapsulation) and NAT64 translation? (as we have neither V nor U in the IPv4 addresses).

a) Note that there is no claim that 4rd-u would be an encapsulation solution (it isn't!). What is claimed is that it is a transparent-tunnel solution (same IPv4 packet received by destinations as sent by sources, except for TTL which progress, and for ECNs that may be changed if congestion is met between source and destination).

b) In draft -04, R-7 (8) says:
"CEs that are assigned unspecified IPv4 addresses (Section 4.3), MUST derive 4rd IPv6 addresses from 4rd IPv4 addresses as follows (Figure 6): take the Rule IPv6 prefix of the NAT64+ mapping rue; append the IPv4 address; append the CNP.
<----------- Rule IPv6 prefix --------->:
+-------------------------------+---+---+-------------+------+
|      NAT64+ IPv6 prefix       |"u"| 0 | IPv4 address|  CNP |
+-------------------------------+---+---+-------------+------+
:               64              : 8 : 8 :      32     :  16  :

                                       Figure 6              "
 
> may i add that it (4rd-U) provides better IPv4 transparency than double translation but less simplicity in the term of layering architecture than encapsulation? (here i avoid sticking things on my understanding to "transparency"). personally i don't think transparency is the most important reason that generally operators prefer encapsulation rather than translation. simplicity and clear concept in architecture is the reason. no matter how much we keep IPv4 information unchanged across the IPv6 domain, as long as the IPv4 header is destroyed, it is a solution of "translation" rather than of "encapsulation". 

Different view here.
a) Ole had a nice slide in the interim meeting about how double translation tends to break transparency. I use "reversible header mapping" which I find intuitive, or just "header mapping", but "reversible header translation" could be OK. 
 A key difference, is that payloads are transparently tunneled in 4rd while they are processed, with dependence of upper layer protocols in double translation. This is AFAIK an important difference. (To take an example, RFC6145 requires to discard UDP-lite packets (RFC3828) while they are tunneled with 4rd)

b) As said in Sec 1 of draft -04:
 " While IPv6 headers are too long to be mapped into IPv4 headers, so that 6rd requires encapsulation of full IPv6 packets in IPv4 packets, IPv4 headers can be reversibly mapped into IPv6 headers so that 4rd tunnel packets can be designed to be valid IPv6 packets, thus ensuring compatibility with IPv6-only middle boxes that perform deep-packet-inspection."
 I see no real complexity in noting that IPv4 headers are small enough to be reversibly mapped in IPv6 headers.
 Of course this still requires careful technical verification, but once done, it's done once and for all. 

> i don't incline to use the term "tunneling" since tunnel could have a variety of forms, among which encapsulation is one but not the only one. 

Exactly: 4rd uses header-mapping tunnels, and MAP-E uses encapsulation tunnels.

Cheers,
RD

---

From: Maoke <[email-masked]>
Date: Fri, 9 Mar 2012 11:04:46 +0000

2012/3/9 Rémi Després <[email-masked]>

> The 4rd ICMPv4 error message has as only purpose to be delivered to a
> 4rd-aware node. There, it will be treated as an ICMPv4 error.
> "NOTE: This guarantees that, for all protocols that use the same checksum
> algorithm as TCP, Tunnel packets are valid IPv6 packets, and this
> independently from where the checksum field is placed for each protocol.
>  Today, such protocols are UDP [RFC0768], TCP [RFC0793],
> UDP-Lite [RFC3828], and DCCP [RFC5595].  Should new ones be specified, BRs
> will support them without needing an update."
>

 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
exactly here it is the point of disagreement. here the "update" refers to
implementation, right? then what is the BR's logic?

A. if (L4_Proto in LIST{UDP, TCP, UDP-Lite, DCCP}) {
      calculate IPv6 address for dst, taking the port from L4_proto.header;
      /* do nothing with checksum, CNP applied for the LIST */
   } else {
      discard;
   }

B. if (1) {
      calculate MAP IPv6 address for dst, supposing dst port is always
there;
      /* do nothing with checksum suppose CNP applied to all protocols */
   }

if you refer to logic B, the "BR will support them without needing an
update" is true. however, the risk is should new ones specified but not
having the tcp-like layout or the tcp-checksum may fail to become a valid
IPv6 packet and (because of the layout difference) it is possible that the
destination IPv6 address is wrong.

if you refer to logic A, the BR must be updated whenever any new protocol
is added to the LIST. this is the same as RFC6145. btw, RFC6145's logic,
when applied with MAP, is:
A'. if (Payload_Proto in LIST{UDP, TCP, ICMP}) {
      calculate IPv6 address for dst, taking the port (or equivalent field
when ICMP) from Payload_Proto.header;
      recalculate the checksum in Payload_Proto.header;
   } else {
      discard;
   }

both A and A' has no risk as B has.

>
>  >>>> For an ISP to extend this advantage to its stateful NAT64, it need
>> to be 4rd
>> >>>> aware (become a NAT64+).
> 2. for the IPv4-to-IPv6 directly, how does the 4rd-aware box make decision
> between 4rd-U pseudo-encapsulation (let me use this term because  i argue
> it does not conform to the behavior of encapsulation) and NAT64
> translation? (as we have neither V nor U in the IPv4 addresses).
>
>
> a) Note that there is no claim that 4rd-u would be an encapsulation
> solution (it isn't!). What is claimed is that it is a transparent-tunnel
> solution (same IPv4 packet received by destinations as sent by sources,
> except for TTL which progress, and for ECNs that may be changed if
> congestion is met between source and destination).
>

yes. TTL is progressing as if it were in translation. ECN is another topic:
it changes even in the encapsulation.

> "CEs that are assigned unspecified IPv4 addresses (Section 4.3), MUST
> derive 4rd IPv6 addresses from 4rd IPv4 addresses as follows (Figure 6):
> take the Rule IPv6 prefix of the NAT64+ mapping rue; append the IPv4
> address; append the CNP.
>
> what do you mean with the unspecified IPv4 address*es*? isn't it only the
0.0.0.0, or you mean 0.0.0.0/0 excluding the mapped-in-rule block?

reading your example in 5.1, i understand your point: the above picture
describes the mapping for the source address if the packet is sent to the
IPv6 world through BR but without the inverse-header-mapping. in this case
the U-octet is applied and the CE-delegated prefix plays also the role of
NAT64+ IPv6 prefix. and the NAT64+ translation happens at CE. right? if i'm
right, it is clear.

but i haven't seen the necessity of defining the V-octet here. with the V,
BR seeing the V does the header mapping while seeing the U does nothing but
only the regular routing. without the V, BR seeing the CE-delegated /64
does the header mapping while seeing another prefix (no matter how long the
length is) does nothing but only the regular routing.

the V-attached stuff in fact makes another, more-specific prefix under the
delegated prefix of a CE.

> confused. how does NAT64+ happens at BR? without the V octet, NAT64 needs
not to be upgraded at all.

>> >> With 464XLAT, IPv4 applications in hosts attached to IPv6-only
>> networks can communicate via NAT64s, but IPv4 transparency has limitations
>> which can be eliminated by upgrading NAT64s to NAT64+ status (a backward
>> compatible evolution).
>> >>
>> >
Remi didn't answer this question of Washam. 4rd-U keeps only stateful NAT64
as it is at CE, to my understanding.

> a) Ole had a nice slide in the interim meeting about how double
> translation tends to break transparency. I use "reversible header mapping"
> which I find intuitive, or just "header mapping", but "reversible header
> translation" could be OK.
>  A key difference, is that payloads are transparently tunneled in 4rd
> while they are processed, with dependence of upper layer protocols in
> double translation. This is AFAIK an important difference. (To take an
> example, RFC6145 requires to discard UDP-lite packets (RFC3828) while they
> are tunneled with 4rd)
>

where is it stated in RFC6145 that it requires to DISCARD UDP-lite packets?

>  " While IPv6 headers are too long to be mapped into IPv4 headers, so that
> 6rd requires encapsulation of full IPv6 packets in IPv4 packets, IPv4
> headers can be reversibly mapped into IPv6 headers so that 4rd tunnel
> packets can be designed to be valid IPv6 packets, thus ensuring
> compatibility with IPv6-only middle boxes that perform
> deep-packet-inspection."

our terminologies are biased. i emphasize the simplicity is in the term of
architecture. encapsulation is a widely used concept in the networking,
making one protocol as an underlay of another. we may have a packet with
all the Ethernet-IP-TCP-HTTP header fields in a PPP framework plus but
re-ordered and re-organized, into, e.g., a super L2-U. it is surely a
reversible header mapping but we can't say that of either encapsulation or
the (narrow-sense) tunneling. this is my point. from the operator's view,
once it is not the simple layered encapsulation, i cannot see it as a
substitute for the encapsulation, but see it as a substitute of other
translations, if i see this is a more gentle translation than others and
this gentleness costs little.

> Exactly: 4rd uses header-mapping tunnels, and MAP-E uses encapsulation

well, in general sense "tunnel" means a source route essentially (RFC1241
made a very good summary about variety of tunnels). to such extent, RFC6145
makes *translation tunnels* (in general sense of the term "source route").
but we never call it like that, because, when most people are talking about
"tunnel" today, we refers to the narrow sense "tunnel", which means the
encapsulation. it is fine that 4rd-U call itself as a tunnel solution but
it should be pointed out that this is a tunnel in the general sense.

therefore i emphasize that, maybe too academic, the counterpart of
translation is encapsulation but not the "tunneling". in the architecture,
we have either the building block of making an underlay protocol as a
virtual link or the building block of making another protocol as a
participant in the path of end-to-end delivery. although you argued this is
*ONLY* the understanding of some diffserv guys, i don't think this
understanding is not generic.

for the simplicity in operation, we often think in such a way: if we would
like to hide the underlay and make a protocol as an underlay or we would
like to expose the things out. both have their use cases. if 4rd-U is said
it fills some important gaps between the two, it would be great. if 4rd-U
is said it replaces the both, i doubt it can. once we want to make a stuff
having advantage of this and that, we often make out a stuff also having
disadvantage of both. for me, i prefer if 4rd-U is moderately defined with
specific use-case and fully description on its pros/cons,
features/limitations, approaches/tradeoffs.

cheers,
maoke

---

From: Rémi Després <[email-masked]>
Date: Fri, 9 Mar 2012 14:14:23 +0100

Maoke,
Thanks for the detailed question.
Clarification below.

2012-03-09 12:04, Maoke  :
> exactly here it is the point of disagreement. here the "update" refers to implementation, right? then what is the BR's logic? 

>       /* do nothing with checksum, CNP applied for the LIST */

No. R-7 (3) isn't ambiguous about this.

> B. if (1) {
>       calculate MAP IPv6 address for dst, supposing dst port is always there;

Yes, as specified in R-7 (3).

As a matter of fact, it doesn't "suppose dst port is always there". 
It just takes bits that are the right ones if dst port (or ICMPv4 ID) is present, unless a source has, by mistake, sent a port-less packet to a shared IPv4 address.
What happens in this mistake case is detailed below.  

> if you refer to logic B, the "BR will support them without needing an update" is true.

Right.

> however, the risk is should new ones specified but not having the tcp-like layout or the tcp-checksum may fail to become a valid IPv6 packet and (because of the layout difference) it is possible that the destination IPv6 address is wrong. 

If a source sends to a shared IPv4 address with a port-less protocol, it will receive a  "destination unreachable" ICMPv4 packet.
Its code will be either "network unreachable", because no CE had the derived IPv6 address (sec. 4.7), or "protocol unreachable", because the reached CE NAT44 cannot process this port-less protocol.
The usual error-signalling mechanism works as it has to.

> if you refer to logic A, the BR must be updated whenever any new protocol is added to the LIST. this is the same as RFC6145. btw, RFC6145's logic, when applied with MAP, is:
>       calculate IPv6 address for dst, taking the port (or equivalent field when ICMP) from Payload_Proto.header; 

See above why B has no operational risk.

Thanks,
RD

> yes. TTL is progressing as if it were in translation. ECN is another topic: it changes even in the encapsulation. 
>  
> 
> what do you mean with the unspecified IPv4 address*es*? isn't it only the 0.0.0.0, or you mean 0.0.0.0/0 excluding the mapped-in-rule block?  
> 
> reading your example in 5.1, i understand your point: the above picture describes the mapping for the source address if the packet is sent to the IPv6 world through BR but without the inverse-header-mapping. in this case the U-octet is applied and the CE-delegated prefix plays also the role of NAT64+ IPv6 prefix. and the NAT64+ translation happens at CE. right? if i'm right, it is clear. 
> 
> but i haven't seen the necessity of defining the V-octet here. with the V, BR seeing the V does the header mapping while seeing the U does nothing but only the regular routing. without the V, BR seeing the CE-delegated /64 does the header mapping while seeing another prefix (no matter how long the length is) does nothing but only the regular routing. 
> 
> the V-attached stuff in fact makes another, more-specific prefix under the delegated prefix of a CE. 
>> >>>
> confused. how does NAT64+ happens at BR? without the V octet, NAT64 needs not to be upgraded at all. 
>> 
>> 
>> >
> Remi didn't answer this question of Washam. 4rd-U keeps only stateful NAT64 as it is at CE, to my understanding. 
>  
>> 
> our terminologies are biased. i emphasize the simplicity is in the term of architecture. encapsulation is a widely used concept in the networking, making one protocol as an underlay of another. we may have a packet with all the Ethernet-IP-TCP-HTTP header fields in a PPP framework plus but re-ordered and re-organized, into, e.g., a super L2-U. it is surely a reversible header mapping but we can't say that of either encapsulation or the (narrow-sense) tunneling. this is my point. from the operator's view, once it is not the simple layered encapsulation, i cannot see it as a substitute for the encapsulation, but see it as a substitute of other translations, if i see this is a more gentle translation than others and this gentleness costs little. 
>  
> well, in general sense "tunnel" means a source route essentially (RFC1241 made a very good summary about variety of tunnels). to such extent, RFC6145 makes *translation tunnels* (in general sense of the term "source route"). but we never call it like that, because, when most people are talking about "tunnel" today, we refers to the narrow sense "tunnel", which means the encapsulation. it is fine that 4rd-U call itself as a tunnel solution but it should be pointed out that this is a tunnel in the general sense. 
> 
> therefore i emphasize that, maybe too academic, the counterpart of translation is encapsulation but not the "tunneling". in the architecture, we have either the building block of making an underlay protocol as a virtual link or the building block of making another protocol as a participant in the path of end-to-end delivery. although you argued this is *ONLY* the understanding of some diffserv guys, i don't think this understanding is not generic. 
> 
> for the simplicity in operation, we often think in such a way: if we would like to hide the underlay and make a protocol as an underlay or we would like to expose the things out. both have their use cases. if 4rd-U is said it fills some important gaps between the two, it would be great. if 4rd-U is said it replaces the both, i doubt it can. once we want to make a stuff having advantage of this and that, we often make out a stuff also having disadvantage of both. for me, i prefer if 4rd-U is moderately defined with specific use-case and fully description on its pros/cons, features/limitations, approaches/tradeoffs. 
> 
> cheers,
> maoke
>  
> 
> 
> Cheers,
> RD
> 
> 
> 
> 
>> 
>> cheers,
>> maoke
>>

---

From: Maoke <[email-masked]>
Date: Mon, 12 Mar 2012 11:08:14 +0900

>>> >>>>> If I understood correctly, there are no additional requirements
>>> for NAT64
>>> >>>>> boxes.
>>> >>>>
>> 3. for the "future protocols", i remember our earlier discussion
>> concluded that CNP can free the code change with ALREADY KNOWN
>> tcp-checksumed protocols. am i wrong here?
>>
>>
> It just takes bits that are the right ones if dst port (or ICMPv4 ID) is
> present, unless a source has, by mistake, sent a port-less packet to a
> shared IPv4 address.
> update" is true.
> however, the risk is should new ones specified but not having the tcp-like
> layout or the tcp-checksum may fail to become a valid IPv6 packet and
> (because of the layout difference) it is possible that the destination IPv6
> address is wrong.
>
>
> If a source sends to a shared IPv4 address with a port-less protocol, it
> will receive a  "destination unreachable" ICMPv4 packet.
> Its code will be either "network unreachable", because no CE had the
> derived IPv6 address (sec. 4.7), or "protocol unreachable", because the
> reached CE NAT44 cannot process this port-less protocol.

ok. now i got the whole picture. sorry for the late understanding.
but does this means 4rd-U is an extension of NAT44 or at least depends upon
NAT44?

RFC6145 has no such dependence at all.

- maoke

>> 2. for the IPv4-to-IPv6 directly, how does the 4rd-aware box make
>> decision between 4rd-U pseudo-encapsulation (let me use this term because
>>  i argue it does not conform to the behavior of encapsulation) and NAT64
> yes. TTL is progressing as if it were in translation. ECN is another
> topic: it changes even in the encapsulation.
>
>
>>
>>> NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64
>>> needs to be upgraded to replace RFC5145 translation by header mapping when
>>> IPv6 addresses it deals with are 4rd addresses (have the V octet).
>>>
> Remi didn't answer this question of Washam. 4rd-U keeps only stateful
> NAT64 as it is at CE, to my understanding.
>
>
>>
>>  " While IPv6 headers are too long to be mapped into IPv4 headers, so
>> that 6rd requires encapsulation of full IPv6 packets in IPv4 packets, IPv4
>>> Naturally, this has no impact on other NAT64 users (e.g. IPv6-only
>>> hosts, or dual-stack hosts supporting BIH of RFC6535): they can continue to
>>> use the NAT64+ as an ordinary NAT64.
>>>
>>> Regards,
>>> RD
>>>
>>> >
>>> > Thanks,
>>> > washam

---

From: Maoke <[email-masked]>
Date: Mon, 12 Mar 2012 03:09:19 +0000

2012/3/12 Maoke <[email-masked]>

>>> "NOTE: This guarantees that, for all protocols that use the same
>>> checksum algorithm as TCP, Tunnel packets are valid IPv6 packets, and this
>> however, the risk is should new ones specified but not having the
>> tcp-like layout or the tcp-checksum may fail to become a valid IPv6 packet
>> and (because of the layout difference) it is possible that the destination
>> IPv6 address is wrong.
>>
>>
> but does this means 4rd-U is an extension of NAT44 or at least depends
> upon NAT44?
>

btw, BR also depends upon NAT44 to deal with the unknown protocol, right?
if so, may i say your statement "BR will support them without needing an
update" is a proposition actually not existing? because NAT44 won't support
them without any update. right?

- maoke

>>       calculate IPv6 address for dst, taking the port (or equivalent
>> field when ICMP) from Payload_Proto.header;
>>> what do you mean with the unspecified IPv4 address*es*? isn't it only
>> the 0.0.0.0, or you mean 0.0.0.0/0 excluding the mapped-in-rule block?
>>
>> but i haven't seen the necessity of defining the V-octet here. with the
>> V, BR seeing the V does the header mapping while seeing the U does nothing
>> but only the regular routing. without the V, BR seeing the CE-delegated /64
>>>> >> What is in scope is only the possibility to improve IPv4
>>>> transparency of NAT64 nodes by using transparent tunneling, instead of
>>>> double translation, when reached by 4rd CEs (making them NAT64+ nodes).
>>>> >
>> our terminologies are biased. i emphasize the simplicity is in the term
>> of architecture. encapsulation is a widely used concept in the networking,
>> for the simplicity in operation, we often think in such a way: if we
>> would like to hide the underlay and make a protocol as an underlay or we
>> would like to expose the things out. both have their use cases. if 4rd-U is
>> said it fills some important gaps between the two, it would be great. if
>> 4rd-U is said it replaces the both, i doubt it can. once we want to make a
>> stuff having advantage of this and that, we often make out a stuff also
>> having disadvantage of both. for me, i prefer if 4rd-U is moderately
>> defined with specific use-case and fully description on its pros/cons,

---

From: Rémi Després <[email-masked]>
Date: Mon, 12 Mar 2012 09:33:06 +0100

...
> but does this means 4rd-U is an extension of NAT44 or at least depends upon NAT44?
>  

R-1 says:
"A node whose CE is assigned a shared IPv4 address MUST include a NAT44 [RFC1631].  This NAT44 MUST only use external ports that are in the CE assigned port set."
For other cases, the choice remains open. In CEs that are assigned IPv4 prefixes, NAT44s are clearly possible but not required. 

In a CE-node that is only a host, the NAT44 might be optional. Would it be good or not to permit it isn't clear to me but, in R-1, a SHOULD seems more appropriate than a MUST.
Thanks for the point.

RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 12 Mar 2012 09:43:35 +0100

2012-03-12 04:09, Maoke:
...
> btw, BR also depends upon NAT44 to deal with the unknown protocol, right? if so, may i say your statement "BR will support them without needing an update" is a proposition actually not existing? because NAT44 won't support them without any update. right?

Not right. Only CEs that need to support a new protocol are concerned:
- If a shared address server supports a new protocol, it can be reached via an unchanged BR.
- If a client using a new protocol tries to reach a shared-address CE that doesn't support this protocol, the client will be returned an error message by the destination NAT44.

RD

---

From: Maoke <[email-masked]>
Date: Mon, 12 Mar 2012 09:21:33 +0000

hi Remi,

2012/3/12 Rémi Després <[email-masked]>

>
> 2012-03-12 04:09, Maoke:
> ...
> > btw, BR also depends upon NAT44 to deal with the unknown protocol,
> right? if so, may i say your statement "BR will support them without
> needing an update" is a proposition actually not existing? because NAT44
> won't support them without any update. right?
>
> - If a client using a new protocol tries to reach a shared-address CE that
> doesn't support this protocol, the client will be returned an error message
> by the destination NAT44.
>

thanks a lot for the clarification! take an example:

 A --- NAT44/CE ---(IPv6 backbone of 4rd domain)--- BR ---(IPv4
Internet)--- B

now A and B are supposed to use a new protocol other than known
TCP/UDP/etc. my understanding:
B --> A
1. BR just passes the new protocol without any concern.
2. CE's NAT44 module would say "this is not supported and a 'destination
unreachable with port unknown' ICMP message is returned to B.
A --> B
1. CE's NAT44 module directly say "destination unreachable with port
unknown" ICMP message to A.

is the above what you mean? when NAT44 module DOESN'T support the new
protocol, things are working while we have no the problem about the
"change" at all for the time being.

then let's consider the case where the NAT44 module has been updated to
support the new protocol. i understand BR passing all protocols can be
survived if and only if the new protocol follows the TCP-layout for the
destination port and the TCP-checksum, right?

then you made a limitation (#1) to the NAT44 module of the CE: even if the
NAT44 has supported a new protocol not following TCP layout/checksum, this
support MUST be disabled in the 4rd-U environment; otherwise, BR may behave
wrong when making the mapped IPv6 addresses while the NAT44 would still try
to translate with the new protocol rather than dropping an error message
because it has known it. right?

further (#2), what if the packets don't pass through the NAT44 module at
all (in the case of non-shared IPv4 addresses)?

please clarify if the limitation of (#1) and (#2) are true or false. i
believe with requiring L4 modification, either MAP or RFC6145 has no such
two limitations: enforcing the checksum update at L4, their framework is
safe for either TCP-layout/checksum or alien-layout/checksum, either shared
or exclusive IPv4 addresses. i worry the CNP is making a situation of
"cutting feet to fit the shoes".

- maoke

---

From: Rémi Després <[email-masked]>
Date: Mon, 12 Mar 2012 18:25:41 +0100

Le 2012-03-12 à 10:21, Maoke a écrit :

>  A --- NAT44/CE ---(IPv6 backbone of 4rd domain)--- BR ---(IPv4 Internet)--- B
> 
> now A and B are supposed to use a new protocol other than known TCP/UDP/etc. my understanding:
> B --> A
> 2. CE's NAT44 module would say "this is not supported and a 'destination unreachable with port unknown' ICMP message is returned to B.

As now documented in 4rd-u-05 in the NOTE of 4.4 (3), the error message should be, more precisely, "protocol unreachable".
Everything OK.

> A --> B
> 1. CE's NAT44 module directly say "destination unreachable with port unknown" ICMP message to A.

Presumably also "protocol unreachable", but this remains a NAT44 matter. 4rd isn't involved.

> is the above what you mean? when NAT44 module DOESN'T support the new protocol, things are working while we have no the problem about the "change" at all for the time being. 
> 
> then let's consider the case where the NAT44 module has been updated to support the new protocol. i understand BR passing all protocols can be survived if and only if the new protocol follows the TCP-layout for the destination port and the TCP-checksum, right? 

The 4rd mechanism is for protocols that have ports at their usual place (all existing protocols that have ports have them at the same place, even if using another checksum algorithm like SCTP).

> then you made a limitation (#1) to the NAT44 module of the CE: even if the NAT44 has supported a new protocol not following TCP layout/checksum, this support MUST be disabled in the 4rd-U environment; otherwise, BR may behave wrong when making the mapped IPv6 addresses while the NAT44 would still try to translate with the new protocol rather than dropping an error message because it has known it. right? 

To me this looks like a far fetched theoretical problem, with no consequence in practice.
OTOH, the fact that RFC6145 doesn't tell you whether you MUST translate DCCP or not is a real problem, and so is the fact that it doesn't support UDP Lite, another already existing protocol.  

> further (#2), what if the packets don't pass through the NAT44 module at all (in the case of non-shared IPv4 addresses)? 

In case of non shared addresses, neither BRs nor CEs look at any port field (there in no PSID to be found).

> please clarify if the limitation of (#1) and (#2) are true or false.

Answered above.

> i believe with requiring L4 modification, either MAP or RFC6145 has no such two limitations: enforcing the checksum update at L4, their framework is safe for either TCP-layout/checksum or alien-layout/checksum, either shared or exclusive IPv4 addresses.

This remains AFAIK a belief that ignores DCCP and UDP Lite limitations of RFC6145.

> i worry the CNP is making a situation of "cutting feet to fit the shoes". 

Hopefully, you will see that no such worry is justified.

Cheers,
RD

---

From: Maoke <[email-masked]>
Date: Tue, 13 Mar 2012 02:18:08 +0000

>> - If a client using a new protocol tries to reach a shared-address CE
>> that doesn't support this protocol, the client will be returned an error
>> message by the destination NAT44.
>>
>
> As now documented in 4rd-u-05 in the NOTE of 4.4 (3), the error message
> should be, more precisely, "protocol unreachable".
>

thanks for the precise description.

> The 4rd mechanism is for protocols that have ports at their usual place
> (all existing protocols that have ports have them at the same place, even
> if using another checksum algorithm like SCTP).
>
>

to me, new protocols following TCP-layout and checksum are a far fetched
theoretical problem too, with no consequen in today's practice. i mean, it
is unfair when you state the 4rd-U pros you emphasize that BR needs no
change with some new protocols, but when we say some other new protocols
you say that's far fetched theoretical problem!

> OTOH, the fact that RFC6145 doesn't tell you whether you MUST translate
> DCCP or not is a real problem, and so is the fact that it doesn't support
> UDP Lite, another already existing protocol.
>

i understand RFC6145 said OPTIONAL supporting DCCP just because it was
considered less critical at that point of writing (may the authors give an
explanation?). UDP-Lite was not mentioned in RFC6145 then, i think, with
the same reason. implementation and operation can follow the RFC6145 logic
to deal with any L4 protocols. on the other hand, it is easy to update
RFC6145 or just making a suggestion anywhere, like a FYI on
double-translation behavior of RFC6145, with clarifying DCCP *optional*
support should be consistent throughout the domain and clarifying other
unmentioned L4 protocol processing should follow the protocol's checksum
logic that is specified.

i don't see it is necessary to enforcing the address-level checksum
neutrality rather than such a simple update or implementation/deployment
guidance.

it is surely fine technically that we enforce that. no problem. but if it
is so necessary? here i have a point regarding the
implementation/deployment: if the address mapping and header processing are
decoupled, the things would be happier than a solution making them tightly
coupled. MAP is made in such a fashion, where header processing could
follow either encapsulation standard or translation standard. RFC6145 is
made in such a way, where addresses could follow stateless mapping in
RFC6052 or processed with state as in RFC6146, and now it is also fine with
MAP. such a decoupling property makes implementation modularized and the
operators may have better flexibility of choice.

in the term of decoupling, surely we have two choices:
1) making address format checksum-neutral, suitable for either with L4
recalculation or without.
2) making L4 recalculation, suitable for either addresses are
checksum-neutral or aren't.

RFC6052 explains why the authors gave up the CNP in the address and choose
2). i also have an understanding that 2) is a solution in implementation,
once distributed, not easy to modify; while 1) is a solution in deployment,
easy to change at any time. for example, if our equipment is made with
RFC6145, the same equipment can be used in either RFC6052, or MAP, or 4rd-U
address-mapping environment, but if our equipment is made with 4rd-U, we
must only use it in 4rd-U environment. once we find we need to try
something others, we have to buy new equipment, which means cost.

> field (there in no PSID to be found).

thanks. then (#2) is not a limitation. my mis.

then the behavior of a new protocol (of the far fetched theoretical case,
where non-tcp-layout/checksum is applied) would be very tricky:
#2.1 address shared while NAT doesn't support the new protocol => dropped
at NAT44, possibly not the correct NAT44 though;
#2.2 address shared while NAT does support the new protocol => not dropped
but it is possible to be incorrectly delivered because BR may take wrong
value for the port;
#2.3 address not shared => passes to the end systems.

correct understanding?

> i believe with requiring L4 modification, either MAP or RFC6145 has no
> such two limitations: enforcing the checksum update at L4, their framework
> is safe for either TCP-layout/checksum or alien-layout/checksum, either
> shared or exclusive IPv4 addresses.
>
>
see above.

cheers,
maoke

---

From: Rémi Després <[email-masked]>
Date: Tue, 13 Mar 2012 11:12:48 +0100

> To me this looks like a far fetched theoretical problem, with no consequence in practice.

I said far fetched because:
- For shared-address CEs, only protocols that use ports at their usual place and the TCP checksum algorithm are in scope (H6 of comparison tables). With them, there is never anything to "disable".
- For non-shared address CEs, MAP-T needs updates for all newly supported protocols (including an existing one such as UDP Lite). Like MAP-E, 4rd works for all layer-4 protocols, never needing any update.  

> to me, new protocols following TCP-layout and checksum are a far fetched theoretical problem too, with no consequen in today's practice. i mean, it is unfair when you state the 4rd-U pros you emphasize that BR needs no change with some new protocols, but when we say some other new protocols you say that's far fetched theoretical problem! 
>  
> i understand RFC6145 said OPTIONAL supporting DCCP just because it was considered less critical at that point of writing (may the authors give an explanation?). UDP-Lite was not mentioned in RFC6145 then, i think, with the same reason. implementation and operation can follow the RFC6145 logic to deal with any L4 protocols.

Non-documented reasons were what they were, but consequences should not depend on them.

> on the other hand, it is easy to update RFC6145 or just making a suggestion anywhere, like a FYI on double-translation behavior of RFC6145, with clarifying DCCP *optional* support should be consistent throughout the domain and clarifying other unmentioned L4 protocol processing should follow the protocol's checksum logic that is specified.
> 
> i don't see it is necessary to enforcing the address-level checksum neutrality rather than such a simple update or implementation/deployment guidance. 

Different view on practical consequences of the TBD "update or implementation/deployment guidance" you propose.
Accepting an NIH feature that solves the problem without this TBD would IMHO be a step forward.

> it is surely fine technically that we enforce that. no problem. but if it is so necessary? here i have a point regarding the implementation/deployment: if the address mapping and header processing are decoupled, the things would be happier than a solution making them tightly coupled. MAP is made in such a fashion, where header processing could follow either encapsulation standard or translation standard. RFC6145 is made in such a way, where addresses could follow stateless mapping in RFC6052 or processed with state as in RFC6146, and now it is also fine with MAP. such a decoupling property makes implementation modularized and the operators may have better flexibility of choice.
>  
> 
> 1) making address format checksum-neutral, suitable for either with L4 recalculation or without. 
> 2) making L4 recalculation, suitable for either addresses are checksum-neutral or aren't. 
> 
> RFC6052 explains why the authors gave up the CNP in the address and choose 2). i also have an understanding that 2) is a solution in implementation, once distributed, not easy to modify; while 1) is a solution in deployment, easy to change at any time. for example, if our equipment is made with RFC6145, the same equipment can be used in either RFC6052, or MAP, or 4rd-U address-mapping environment, but if our equipment is made with 4rd-U, we must only use it in 4rd-U environment. once we find we need to try something others, we have to buy new equipment, which means cost. 

In RFC6052, checksum neutrality was abandoned "because it would not help with stateful translation and because checksum neutrality can also be achieved by an appropriate choice of the Network-Specific Prefix, i.e., selecting a prefix whose one's complement checksum equals either 0 or 0xffff."
- Stateful translation is off scope
- MAP-T cannot select for each CE "a prefix whose one's complement checksum equals either 0 or 0xffff".

> then the behavior of a new protocol (of the far fetched theoretical case, where non-tcp-layout/checksum is applied) would be very tricky:
> #2.1 address shared while NAT doesn't support the new protocol => dropped at NAT44,

> possibly not the correct NAT44 though; 

???

> #2.2 address shared while NAT does support the new protocol => not dropped but it is possible to be incorrectly delivered because BR may take wrong value for the port; 

As stated many times, 4rd only deals, for shared-address CEs, with protocols, existing or future, that have ports their usual place and the TCP checksum algorithm.
With these, no problem.

Since this seems to be misunderstood, H6 of the comparison tables ca clarify, in a next version, that future protocols that are considered are supposed to have ports at their usual place (that of all existing port-based protocols, be they or not with the TCP checksum algorithm).  

> #2.3 address not shared => passes to the end systems. 

See just above.

Cheers,
RD

---

From: Maoke <[email-masked]>
Date: Tue, 13 Mar 2012 11:02:36 +0000

2012/3/13 Rémi Després <[email-masked]>

> may you have a check on the statement of "all existing protocols" again? i
noticed RFC908/RFC1151. sorry if that are not a transport protocol over IP.

- maoke

>
>>
>> then you made a limitation (#1) to the NAT44 module of the CE: even if
>> the NAT44 has supported a new protocol not following TCP layout/checksum,
>> this support MUST be disabled in the 4rd-U environment; otherwise, BR may
>> behave wrong when making the mapped IPv6 addresses while the NAT44 would
>> still try to translate with the new protocol rather than dropping an error
>> message because it has known it. right?
>>
>>
> - For shared-address CEs, only protocols that use ports at their usual
> place and the TCP checksum algorithm are in scope (H6 of comparison
> tables). With them, there is never anything to "disable".
> - For non-shared address CEs, MAP-T needs updates for all newly supported
> protocols (including an existing one such as UDP Lite). Like MAP-E, 4rd
> works for all layer-4 protocols, never needing any update.
>
> to deal with any L4 protocols.
>
>
> on the other hand, it is easy to update RFC6145 or just making a
> suggestion anywhere, like a FYI on double-translation behavior of RFC6145,
> with clarifying DCCP *optional* support should be consistent throughout the
> domain and clarifying other unmentioned L4 protocol processing should
> follow the protocol's checksum logic that is specified.
>
> Different view on practical consequences of the TBD "update
> or implementation/deployment guidance" you propose.
> at NAT44,
> As stated many times, 4rd only deals, for shared-address CEs, with
> protocols, existing or future, that have ports their usual place and the
> TCP checksum algorithm.
> With these, no problem.
>
> Since this seems to be misunderstood, H6 of the comparison tables ca
> clarify, in a next version, that future protocols that are considered are
> supposed to have ports at their usual place (that of all existing
> port-based protocols, be they or not with the TCP checksum algorithm).
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 13 Mar 2012 14:58:11 +0100

...

> 
> may you have a check on the statement of "all existing protocols" again? i noticed RFC908/RFC1151. sorry if that are not a transport protocol over IP. 

I missed this one.
None of the proposed stateless solutions supports it, but it remains that you are right: it has ports at a different place.
Thanks for this info.

RD

---

From: Maoke <[email-masked]>
Date: Wed, 14 Mar 2012 05:51:24 +0000

> None of the proposed stateless solutions supports it, but it remains that
> you are right: it has ports at a different place.
>

alright. so 4rd-U doesn't not support "all existing transport protocol"
either. but i suppose you may make an update in the 4rd-u-06 so that a new
"if...else..." is added the port pick-up logic, and surely the CNP is not a
problem for RDP because the old version (RFC908) has 32bit checksum but not
involving pseudo-header while the newer version (RFC1151) changed to use
TCP-checksum. no big deal but only needs a new patch to the draft.

but this is not my point. my point is: there must be something we don't
know ("non omnia possumus omnes"). even we have gone through the RFCs,
there might be some other proprietary L4 protocols, or experimental
protocols. even they are minority, i don't think ignoring their existance
in our solution fits the spirit of the Internet. it might be argued that
NAT44 doesn't support such L4 protocols now, but an L4 protocol owner may
makes his own NAT44, either attached to the CE or separated. if 4rd-U
respects such an effort, it should state "currently blahblabla L4 protocols
are supported". the similar statement applies to the RFC6145 or MAP as
well. i somehow am hard to accept words like "far fetched theoretical
problem".

the L4-recalculate is a generic, architectural solution, surely needing
codes for every L4 protocol. but this generality in architecture makes
RFC6145 or MAP-T equipment be easily enhanced to support anything new with
the same logic. but for the 4rd-U BR, it looks to me we cannot have the
unified logic for all (even limited to existing and well-known) L4
protocols.

only my 2 cents.

maoke

---

From: Rémi Després <[email-masked]>
Date: Wed, 14 Mar 2012 09:47:40 +0100

> alright. so 4rd-U doesn't not support "all existing transport protocol" either.

Never said that without qualifying which protocols.

> but i suppose you may make an update in the 4rd-u-06 so that a new "if...else..." is added the port pick-up logic, and surely the CNP is not a problem for RDP because the old version (RFC908) has 32bit checksum but not involving pseudo-header while the newer version (RFC1151) changed to use TCP-checksum. no big deal but only needs a new patch to the draft.

In the Note in 4.4 (7), the first sentence is:
"This guarantees that, for all protocols that use the same checksum algorithm as TCP, Tunnel packets are valid IPv6 packets, and this independently from where the checksum field is placed for each protocol."
It can become: 
"This guarantees that, for all protocols that use the same checksum algorithm as TCP and have ports at the same place, Tunnel packets are valid IPv6 packets, and this independently from where the checksum field is placed for each protocol."

Similarly, in the comparison table, H6 is:
"For shared IPv4 addresses, DCCP and UDP-Lite supported, as well as future  protocols using the TCP checksum algorithm"
It can become:
"For shared IPv4 addresses, DCCP and UDP-Lite supported, as well any future protocol that might use the TCP checksum algorithm and ports at the same place"    

> but this is not my point. my point is: there must be something we don't know ("non omnia possumus omnes"). even we have gone through the RFCs, there might be some other proprietary L4 protocols, or experimental protocols. even they are minority, i don't think ignoring their existance in our solution fits the spirit of the Internet. it might be argued that NAT44 doesn't support such L4 protocols now, but an L4 protocol owner may makes his own NAT44, either attached to the CE or separated. if 4rd-U respects such an effort, it should state "currently blahblabla L4 protocols are supported". the similar statement applies to the RFC6145 or MAP as well.

> i somehow am hard to accept words like "far fetched theoretical problem". 

If I had thought it might be so, I would have avoided the word.

> the L4-recalculate is a generic, architectural solution, surely needing codes for every L4 protocol. but this generality in architecture makes RFC6145 or MAP-T equipment be easily enhanced to support anything new with the same logic. but for the 4rd-U BR, it looks to me we cannot have the unified logic for all (even limited to existing and well-known) L4 protocols. 
> 
> only my 2 cents. 

With amendments above, the point is AFAIK completely covered: everything is rigorously true, and worth noting.
Thanks for the useful reference to the RDP of RFC1151.

RD

---

From: Maoke <[email-masked]>
Date: Wed, 14 Mar 2012 09:00:27 +0000

2012/3/14 Rémi Després <[email-masked]>

>>  may you have a check on the statement of "all existing protocols"
>> again? i noticed RFC908/RFC1151. sorry if that are not a transport protocol
>> over IP.
>>
>>
>> I missed this one.
> either.
> but i suppose you may make an update in the 4rd-u-06 so that a new
> "This guarantees that, for all protocols that use the same checksum
> independently from where the checksum field is placed for each protocol."
> It can become:
> "This guarantees that, for all protocols that use the same checksum
> algorithm as TCP and have ports at the same place, Tunnel packets are
> valid IPv6 packets, and this independently from where the checksum field is
> placed for each protocol."
>
> "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well as
> future  protocols using the TCP checksum algorithm"
> It can become:
> "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well any
> future protocol that might use the TCP checksum algorithm and ports at the
> same place"
>

then it is fine. with these statement, 4rd-U can support
- TCP
- UDP
- DCCP
- any future or less well-known protocol as long as it uses TCP checksum
and port at the same place

as a counterpart, we may suggest MAP-T to state it supports
- TCP
- UDP
- DCCP (with enforcing it rather than RFC6145's "optional")
- any future or less well-known protocol, no matter what layout it is nor
how the checksum is defined, with the similar logic of L4 checksum
recalculation

;-)
maoke

> are supported". the similar statement applies to the RFC6145 or MAP as well.
>
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 14 Mar 2012 10:29:12 +0100

Le 2012-03-14 à 10:00, Maoke a écrit :

> - any future or less well-known protocol as long as it uses TCP checksum and port at the same place
> 
> - any future or less well-known protocol, no matter what layout it is nor how the checksum is defined, with the similar logic of L4 checksum recalculation 

Maybe I get the point you are making: you implicitly consider that BR and CE modifications can be synchronized. This is feasible if ISPs provide all CE nodes, but not in the general case.
  
Changing DCCP support from optional to mandatory in RFC6145 isn't backward compatible (an upgraded node isn't guaranteed to interwork with a non upgraded node).
 
To be even more precise, H6 of the comparison table can be:
"For ISPs that don't provide all CE nodes, and for shared IPv4 addresses, DCCP and UDP-Lite are supported, as well as future protocols using the TCP checksum algorithm and ports at the same place"

Does this cover the point?

RD

---

From: Maoke <[email-masked]>
Date: Wed, 14 Mar 2012 09:46:06 +0000

>>>  The 4rd mechanism is for protocols that have ports at their usual
>>>>> place (all existing protocols that have ports have them at the same place,
>>>>> even if using another checksum algorithm like SCTP).
>>>>>
>>>>
>>> None of the proposed stateless solutions supports it, but it remains
>>> that you are right: it has ports at a different place.
>>>
>>
> Maybe I get the point you are making: you implicitly consider that BR and
> CE modifications can be synchronized. This is feasible if ISPs provide all
> CE nodes, but not in the general case.
>

i don't consider their modifications are synced but i do consider that each
device, either BR or CE, should has a specification on its supported
functionalities.

>
> Changing DCCP support from optional to mandatory in RFC6145 isn't backward
> compatible (an upgraded node isn't guaranteed to interwork with a non
> upgraded node).
>

the CE/BR specified RFC6145-compliant might be a problem but MAP-T is still
in development. if we state to enforce DCCP mandatorily rather than
optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward
compatible problem. to this extend, MAP-T is at the same kick-off line of
the 4rd-U.

> "For ISPs that don't provide all CE nodes, and for shared IPv4 addresses,
> DCCP and UDP-Lite are supported, as well as future protocols using the TCP
> checksum algorithm and ports at the same place"
>

i actually think the original text is fine. "For .... shared IPv4
addresses" is not needed for 4rd-U, to my understanding, nor needed to
MAP-T.

maoke

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 14 Mar 2012 14:04:40 +0000

Hi Maoke and Remi,

Thanks very much for discussing this issue on the mailing-list. I guess the
points are now clear for both options. IMHO, there is no one better than the
other, it is all about choice of implementation. Perhaps it is time for more
people to comment how they feel for both options.

Thanks again for the great discussion.

B.R.,
Yiu

From:  Maoke <[email-masked]>
Date:  Wed, 14 Mar 2012 09:46:06 +0000
To:  Rémi Després <[email-masked]>
Cc:  Softwires WG <[email-masked]>, Yong Cui <[email-masked]>
Subject:  Re: [Softwires] IPv4 Residual Deployment - Unified-standard
proposal 4rd

>>>>>>> (all existing protocols that have ports have them at the same place,
>>>>>> may you have a check on the statement of "all existing protocols" again?
>>>>>> i noticed RFC908/RFC1151. sorry if that are not a transport protocol over
>>>>>> IP. 
>>>>> 
>>>>> I missed this one.
>>> algorithm as TCP and have ports at the same place, Tunnel packets are valid
>>> IPv6 packets, and this independently from where the checksum field is placed
>>> for each protocol."
>>> 
>>> "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well as future
>>> protocols using the TCP checksum algorithm"
>>> It can become:
>>> "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well any future
>>> protocol that might use the TCP checksum algorithm and ports at the same
>>> place"    
>> 
>> - any future or less well-known protocol, no matter what layout it is nor how
>> the checksum is defined, with the similar logic of L4 checksum recalculation
> 
> Maybe I get the point you are making: you implicitly consider that BR and CE
> modifications can be synchronized. This is feasible if ISPs provide all CE
> nodes, but not in the general case.

> compatible (an upgraded node isn't guaranteed to interwork with a non upgraded
> node).

the CE/BR specified RFC6145-compliant might be a problem but MAP-T is still
in development. if we state to enforce DCCP mandatorily rather than optional
in MAP-T, a MAP-T-compliant CE/BR won't has the backward compatible problem.
to this extend, MAP-T is at the same kick-off line of the 4rd-U.
 
> "For ISPs that don't provide all CE nodes, and for shared IPv4 addresses, DCCP
> and UDP-Lite are supported, as well as future protocols using the TCP checksum
> algorithm and ports at the same place"

i actually think the original text is fine. "For .... shared IPv4 addresses"
is not needed for 4rd-U, to my understanding, nor needed to MAP-T.

maoke 
 
>>>> well.

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

---

From: Maoke <[email-masked]>
Date: Thu, 15 Mar 2012 01:04:38 +0000

>
> Le 2012-03-14 à 10:46, Maoke a écrit :
>
>
>
> i don't consider their modifications are synced but i do consider that
> each device, either BR or CE, should has a specification on its supported
> functionalities.
>
>
>>
>> Changing DCCP support from optional to mandatory in RFC6145 isn't
>> backward compatible (an upgraded node isn't guaranteed to interwork with a
>> non upgraded node).
>>
>
> the CE/BR specified RFC6145-compliant might be a problem but MAP-T is
> still in development. if we state to enforce DCCP mandatorily rather than
> 1. I agree that, between CEs and BRs, there can be no problem for DCCP
> (provided the draft is completed to this effect). The comparison table was
> explicitly made with existing drafts, and intended to be updatable.
>
> 2. The MAP-T draft is also claimed to allow "communication between
> IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only
> servers in the domain that are using IPv4-mapped IPv6 address". In this
> case, AFAIK, the backward compatibility problem exists
> Thought?
>

surely it does not exist. that statement applies to the MAP-T-compliant
equipments, when it is used as a IPv4-to-IPv6 single translator or as an
native IPv6 router. same deployment of equipments should support
double-translation, single-translation, and native IPv6 accesses
simultanenously. that's one of the points of the MAP-T.

- maoke

> Will see what to do, then, when changes to the MAP-T draft concerning DCCP
> are known.
>

>>>  but this is not my point. my point is: there must be something we
>>> don't know ("non omnia possumus omnes"). even we have gone through the
>>> RFCs, there might be some other proprietary L4 protocols, or experimental

---

From: Rémi Després <[email-masked]>
Date: Thu, 15 Mar 2012 09:54:42 +0100

Maoke,

Let's try, once more, to understand each other.

If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which is AFAIAC a positive result of our discussion):
a) Such a CE can communicate with an IPv6-only host including in DCCP.
b) The same would apply to UDP lite if MAP-T would also require UDP-lite translation.
c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't translate DCCP (as permitted by RFC6145).
d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP translation, nodes complying with modified versions and those complying with previous versions wouldn't be guaranteed to interwork for DCCP.

If we don't agree on this, there is still something to be clarified between us.
If we agree, I have nothing else on this point.

Regards,
RD

If, as you suggest, 

...
>> the CE/BR specified RFC6145-compliant might be a problem but MAP-T is still in development. if we state to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward compatible problem. to this extend, MAP-T is at the same kick-off line of the 4rd-U. 
> 
> 1. I agree that, between CEs and BRs, there can be no problem for DCCP (provided the draft is completed to this effect). The comparison table was explicitly made with existing drafts, and intended to be updatable. 
> 
> 2. The MAP-T draft is also claimed to allow "communication between IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only servers in the domain that are using IPv4-mapped IPv6 address". In this case, AFAIK, the backward compatibility problem exists  
> Thought? 
> 
> surely it does not exist. that statement applies to the MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 single translator or as an native IPv6 router. same deployment of equipments should support double-translation, single-translation, and native IPv6 accesses simultanenously. that's one of the points of the MAP-T. 
> 
> - maoke
>  
> 
> 
>> i actually think the original text is fine. "For .... shared IPv4 addresses" is not needed for 4rd-U, to my understanding, nor needed to MAP-T.
> 
> Will see what to do, then, when changes to the MAP-T draft concerning DCCP are known. 
> 
> RD
> 
> 
>>  
>> 
>> maoke 
>>  
>>

---

From: Maoke <[email-masked]>
Date: Thu, 15 Mar 2012 09:02:13 +0000

2012/3/15 Rémi Després <[email-masked]>

> If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which
> is AFAIAC a positive result of our discussion):
> c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, i.e.
> with DCCP optional), DCCP is broken if the NAT64 doesn't translate DCCP (as
> permitted by RFC6145).
> d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP
> translation, nodes complying with modified versions and those complying
> with previous versions wouldn't be guaranteed to interwork for DCCP.
>

surely do not. RFC6146 clearly states:

   The current specification only defines how stateful NAT64 translates
   unicast packets carrying TCP, UDP, and ICMP traffic. Multicast
   packets and other protocols, including the Stream Control
   Transmission Protocol (SCTP), the Datagram Congestion Control
   Protocol (DCCP), and IPsec, are out of the scope of this
   specification.

- maoke

>>> "For ISPs that don't provide all CE nodes, and for shared IPv4
>>> addresses, DCCP and UDP-Lite are supported, as well as future protocols
>>> using the TCP checksum algorithm and ports at the same place"
>>>
>>
>>>> With amendments above, the point is AFAIK completely covered:
>>>> everything is rigorously true, and worth noting.

---

From: Rémi Després <[email-masked]>
Date: Thu, 15 Mar 2012 10:08:56 +0100

>    Protocol (DCCP), and IPsec, are out of the scope of this

I said "If RFC614... would be modified to also impose DCCP translation" => I take the point that you are not interested in that, but I don't think there was a contradiction.
OK?

RD

---

From: Maoke <[email-masked]>
Date: Thu, 15 Mar 2012 09:22:13 +0000

2012/3/15 Rémi Després <[email-masked]>

>> c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145,
>> i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't translate
>> DCCP (as permitted by RFC6145).
>> d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose
>> DCCP translation, nodes complying with modified versions and those
>> complying with previous versions wouldn't be guaranteed to interwork for
>> DCCP.
>>
> I said "If RFC614... would be modified to also impose DCCP translation" =>
> I take the point that you are not interested in that, but I don't think
> there was a contradiction.
> OK?
>

it is not yet modified. with the current statement of RFC6146, the current
equipment doesn't support DCCP. if it is modified, the update may state
mandatory imposement for DCCP. i don't see any problem here. on the other
hand, i cannot understand how the CNP helps stateful checksum validity. may
you please to clarify?

maoke

>>>>> the L4-recalculate is a generic, architectural solution, surely
>>>>> needing codes for every L4 protocol. but this generality in architecture
>>>>> makes RFC6145 or MAP-T equipment be easily enhanced to support anything new
>>>>> with the same logic. but for the 4rd-U BR, it looks to me we cannot have
>>>>> the unified logic for all (even limited to existing and well-known) L4
>>>>> protocols.
>>>>>
>>>>> only my 2 cents.
>>>>>
>>>>>

---

From: Maoke <[email-masked]>
Date: Thu, 15 Mar 2012 09:29:25 +0000

2012/3/15 Maoke <[email-masked]>

>> I said "If RFC614... would be modified to also impose DCCP translation"
>> => I take the point that you are not interested in that, but I don't think
> mandatory imposement for DCCP. i don't see any problem here.
>

more clearly speaking: stateful NAT64, i think, only needs to be done once
in a delivery, therefore either the DCCP is supported or it is not. there's
no "interwork" between NAT64 who has been modified with the NAT64 who has
not. incorrect?

> on the other hand, i cannot understand how the CNP helps stateful checksum
> validity. may you please to clarify?
>
> maoke
>
>
>>
>> RD
>>
>>
>>
>> - maoke
>>
>>
>>>> servers in the domain that are using IPv4-mapped IPv6 address". In
>>>> this case, AFAIK, the backward compatibility problem exists
>>>> Thought?
>>>>
>>>

---

From: Rémi Després <[email-masked]>
Date: Thu, 15 Mar 2012 10:31:14 +0100

Le 2012-03-15 à 10:22, Maoke a écrit :

> it is not yet modified. with the current statement of RFC6146, the current equipment doesn't support DCCP. if it is modified, the update may state mandatory imposement for DCCP. i don't see any problem here.

OK, we are now in sync on this point :-).

> on the other hand, i cannot understand how the CNP helps stateful checksum validity. may you please to clarify? 

On this new subject, could you be more precise on what you mean by "stateful checksum validity"? 

RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 15 Mar 2012 10:38:10 +0100

Le 2012-03-15 à 10:29, Maoke a écrit :

> more clearly speaking: stateful NAT64, i think, only needs to be done once in a delivery, therefore either the DCCP is supported or it is not. there's no "interwork" between NAT64 who has been modified with the NAT64 who has not. incorrect? 

The full sentence was: "If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP translation, nodes complying with modified versions and those complying with previous versions wouldn't be guaranteed to interwork for DCCP." 

I assumed an RFC6145 complying node can talk to a NAT64, right or not?
(A NAT64 talking to another NAT64 was part of what I wrote!!!)

RD

---

From: Maoke <[email-masked]>
Date: Thu, 15 Mar 2012 09:38:24 +0000

> by "stateful checksum validity"?

i mean i didn't understand the how the stateful NAT64 benefits from CNP.

maoke

---

From: Rémi Després <[email-masked]>
Date: Thu, 15 Mar 2012 10:59:41 +0100

Maoke,

Thanks for this question.
This subject being new, I take it on a new thread.

2012-03-15 10:38, Maoke:
...
> i didn't understand the how the stateful NAT64 benefits from CNP. 

The point is that if a NAT64 is upgraded to support 4rd-u tunnels (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads. 
Any protocol that this NAT64 supports is then supported e2e for 4rd-u CEs
These CEs need not being dependent on which NAT64 supports which protocols.

Note that the NAT64 doesn't need to have CNP code. It just happens that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv4 payloads are the same for all protocols that have ports at the same place as TCP/UDP/..., and the same checksum algorithm)

RD

---

From: Maoke <[email-masked]>
Date: Thu, 15 Mar 2012 10:40:51 +0000

>> it is not yet modified. with the current statement of RFC6146, the
>> current equipment doesn't support DCCP. if it is modified, the update may
>> state mandatory imposement for DCCP. i don't see any problem here.
>>
>
> The full sentence was: "If RFC6146 (NAT64) and/or RFC6145 would be
> modified to also impose DCCP translation, nodes complying with modified
> versions and those complying with previous versions wouldn't be guaranteed
> to interwork for DCCP."
>

you mean the stateful NAT64-ed IPv4 host (let's call it A) having access to
an IPv4 host (let's call it B) behind a stateless RFC6145 translator,
mapped to IPv4-converted IPv6 address in the IPv6 domain. if so, it is not
right that RFC6145 complying node can talk to a NAT64. let's see the
details:

model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6 cloud)--- RFC6145
translator --- B

because A would be translated by NAT64 to an arbitrary IPv6 address, A',
which is not an IPv4-converted one either in MAP or in RFC6052, the RFC6145
translator cannot handle it statelessly for any end-to-end communication.
the box in front of B should be another NAT64, and as i said previously, no
problem in interwork. if one NAT64 supports DCCP, it adjusts the checksum;
if the other doesn't support, it drops DCCP. no case of asymmetrically
processed but end-to-end deliverable DCCP here.

- maoke

>> on the other hand, i cannot understand how the CNP helps stateful
>> checksum validity. may you please to clarify?
>>
>> maoke
>>
>>
>>>
>>> RD
>>>
>>>
>>>
>>> - maoke
>>>
>>>

---

From: Rémi Després <[email-masked]>
Date: Thu, 15 Mar 2012 11:40:46 +0100

> Note that the NAT64 doesn't need to have CNP code. It just happens that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv4 payloads are the same for all protocols that have port…

Oops.
This is only true for the IPv6 host address. To construct an IPv6 address when transmitting to  a 4rd-u CE, the NAT64 should compute a CNP. (This is to maintain the property that that middleboxes can treat tunnel packets as valid IPv6 packets. Not a big deal, but necessary).
Sorry for having hastily added this sentence. 

RD

---

From: Maoke <[email-masked]>
Date: Thu, 15 Mar 2012 10:45:45 +0000

i understand NAT64 makes translation between arbitrary IPv6 address to
arbitrary IPv4 address. i don't understand how you make CNP in any IPv6
address. in other words, we cannot limit NAT64 stateful service only serve
those IPv6 addresses with CNP. - maoke

> > The point is that if a NAT64 is upgraded to support 4rd-u tunnels (thus
> becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads.
> > Note that the NAT64 doesn't need to have CNP code. It just happens that
> host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv4
> payloads are the same for all protocols that have ports at the same place
> as TCP/UDP/..., and the same checksum algorithm)
>
> Oops.
> This is only true for the IPv6 host address. To construct an IPv6 address
> when transmitting to  a 4rd-u CE, the NAT64 should compute a CNP. (This is
> to maintain the property that that middleboxes can treat tunnel packets as
> valid IPv6 packets. Not a big deal, but necessary).

---

From: Rémi Després <[email-masked]>
Date: Thu, 15 Mar 2012 11:58:52 +0100

Le 2012-03-15 à 11:45, Maoke a écrit :

> i understand NAT64 makes translation between arbitrary IPv6 address to arbitrary IPv4 address. i don't understand how you make CNP in any IPv6 address.

> in other words, we cannot limit NAT64 stateful service only serve those IPv6 addresses with CNP.

That's no the case at all(!). 
A NAT64+ is a *backward compatible* extension of NAT64 (everything that worked before still works completely unchanged).

The draft says:
"NAT64+:  An ISP NAT64 of [RFC6146] that is upgraded to support 4rd tunneling when IPv6 addresses it deals with have the 4rd-IPv6-address format."
Because 4rd IPv6 addresses of CEs are distinguishable from all other IPv6 addresses (due to the V octet), NAT64s are concerned with CNPs ONLY for addresses that actually are 4rd CE addresses.

RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 15 Mar 2012 12:02:18 +0100

> I assumed an RFC6145 complying node can talk to a NAT64, right or not?

Just referring to:

DS-RFC6145-host --(v4net) -- NAPT64 -- IPv4 Internet

Is this excluded?

RD

> 
> you mean the stateful NAT64-ed IPv4 host (let's call it A) having access to an IPv4 host (let's call it B) behind a stateless RFC6145 translator, mapped to IPv4-converted IPv6 address in the IPv6 domain. if so, it is not right that RFC6145 complying node can talk to a NAT64. let's see the details:  
> 
> model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6 cloud)--- RFC6145 translator --- B 
> 
> because A would be translated by NAT64 to an arbitrary IPv6 address, A', which is not an IPv4-converted one either in MAP or in RFC6052, the RFC6145 translator cannot handle it statelessly for any end-to-end communication. the box in front of B should be another NAT64, and as i said previously, no problem in interwork. if one NAT64 supports DCCP, it adjusts the checksum; if the other doesn't support, it drops DCCP. no case of asymmetrically processed but end-to-end deliverable DCCP here. 
> 
> - maoke 
>

---

From: Rémi Després <[email-masked]>
Date: Thu, 15 Mar 2012 12:19:21 +0100

> DS-RFC6145-host --(v4net) -- NAPT64 -- IPv4 Internet

Oops again (v6net) instead of (v4net) ... of course.

---

From: Maoke <[email-masked]>
Date: Thu, 15 Mar 2012 22:47:57 +0900

> address.
> A NAT64+ is a *backward compatible* extension of NAT64 (everything that
> worked before still works completely unchanged).
>
> The draft says:
> "NAT64+:  An ISP NAT64 of [RFC6146] that is upgraded to support
> 4rd tunneling when IPv6 addresses it deals with have the 4rd-IPv6-address
> format."
>
>

this phrase is not understood yet. do you mean using 4rd-IPv6-address
format for stateful translation service? please draw an example of A <--->
B communication as i did for clarification.

>
> Because 4rd IPv6 addresses of CEs are distinguishable from all other IPv6
> addresses (due to the V octet), NAT64s are concerned with CNPs ONLY for
> addresses that actually are 4rd CE addresses.
>
>

we need to make sure if the NAT64s make both src and dst addresses
checksum-neutral. i cannot imagine what the use case is. please specify!

- maoke

---

From: Maoke <[email-masked]>
Date: Thu, 15 Mar 2012 22:52:55 +0900

>> more clearly speaking: stateful NAT64, i think, only needs to be done
>> once in a delivery, therefore either the DCCP is supported or it is not.
>> there's no "interwork" between NAT64 who has been modified with the NAT64
>> who has not. incorrect?
>>
>>

what is RFC6145-host?? (seeing you have corrected the v4net with v6net) if
it is a host connected to an IPv6 network, it is the case of single NAT64,
where we have the problem of "interwork"?

- maoke

>
>
> Is this excluded?
>
> RD
>
>
>
> you mean the stateful NAT64-ed IPv4 host (let's call it A) having access
> to an IPv4 host (let's call it B) behind a stateless RFC6145 translator,
>>>>>> 1. I agree that, between CEs and BRs, there can be no problem for
>>>>>> DCCP (provided the draft is completed to this effect). The comparison table
>>>>>> was explicitly made with existing drafts, and intended to be updatable.
>>>>>>
>>>>>> IPv4-only, as well as any IPv6 enabled end hosts, to native
>>>>>> IPv6-only servers in the domain that are using IPv4-mapped IPv6
>>>>>> address". In this case, AFAIK, the backward compatibility problem
>>>>>> exists
>>>>>> Thought?
>>>>>>
>>>>>
>>>>> surely it does not exist. that statement applies to the
>>>>> MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 single
>>>>> translator or as an native IPv6 router. same deployment of equipments
>>>>> should support double-translation, single-translation, and native IPv6
>>>>> accesses simultanenously. that's one of the points of the MAP-T.
>>>>>
>>>>> - maoke
>>>>>
>>>>>
>>>>>>
>>>>>>

---

From: Rémi Després <[email-masked]>
Date: Thu, 15 Mar 2012 16:05:17 +0100

Le 2012-03-15 à 14:52, Maoke a écrit :

> what is RFC6145-host??

E.g. a host with BIH (RFC6535) or with 464XLAT, i.e. one that supports IPv4 applications and is attached to an IPv6-only network.
Clear enough?

> (seeing you have corrected the v4net with v6net) if it is a host connected to an IPv6 network, it is the case of single NAT64, where we have the problem of "interwork"?

See above.

RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 15 Mar 2012 16:30:41 +0100

Le 2012-03-15 à 14:47, Maoke a écrit :

> this phrase is not understood yet. do you mean using 4rd-IPv6-address format for stateful translation service?

Yes (but, &s said, only for CE nodes that are 4rd capable (with the advantage of better IPv4 transparency between CEs and NAT64+ than between RFC6145 and NAT64).

> please draw an example of A <---> B communication as i did for clarification.

Here is an example scenario:

v4appli-BIH ----. => A>B NOK (because, according to RFC6535, BIH uses RFC6145) 
     A1         |     
                :----(v6net)----- NAT64+ ---(IPv4 Internet)--- Server
                |                UDP-lite                      UDP-lite
v4Appli-4rdCE --'                 capable                         B
     A2          => A-B OK

> we need to make sure if the NAT64s make both src and dst addresses checksum-neutral.

Correct, iff the host address has the V octet.

> i cannot imagine what the use case is. please specify!

Hope the picture above helps.

RD

---

From: Maoke <[email-masked]>
Date: Fri, 16 Mar 2012 00:27:36 +0000

>>>>> I said "If RFC614... would be modified to also impose DCCP
>>>>> translation" => I take the point that you are not interested in that, but I
>>>>> don't think there was a contradiction.
>>>>> OK?
>>>>>
>>>>
> E.g. a host with BIH (RFC6535) or with 464XLAT, i.e. one that supports
> IPv4 applications and is attached to an IPv6-only network.
>

then inside the host, there a RFC6145 module, right? my point is, if there
is no NAT64 module, this cannot talk with another NAT64 box elsewhere as
only one of the (src,dst)-pair is stateless IPv4-converted IPv6 address. my
previous analysis doesn't matter whether the translator and the end host
are separated or integrated into one box.

- maoke

> Clear enough?
>
> (seeing you have corrected the v4net with v6net) if it is a host connected
> to an IPv6 network, it is the case of single NAT64, where we have the
> problem of "interwork"?
>
>
> See above.
>
> RD
>
>
>
> - maoke
>
>
>>
>>
>> Is this excluded?
>>
>> RD
>>
>>
>>
>>>>>>> the CE/BR specified RFC6145-compliant might be a problem but MAP-T
>>>>>>> is still in development. if we state to enforce DCCP mandatorily rather
>>>>>>> than optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward
>>>>>>>>>  but this is not my point. my point is: there must be something
>>>>>>>>> we don't know ("non omnia possumus omnes"). even we have gone through the

---

From: Maoke <[email-masked]>
Date: Fri, 16 Mar 2012 00:59:31 +0000

> format for stateful translation service?
>
>
> Yes (but, &s said, only for CE nodes that are 4rd capable (with the
> advantage of better IPv4 transparency between CEs and NAT64+ than between
> RFC6145 and NAT64).
>
yes, BIH uses RFC6145 that doesn't claim supporting UDP-Lite. but exactly
speaking, if the "not support" means passing-it-through without checksum
adjustment, A --> B is fine because neither BIH nor NAT64+ does nothing
with the L4, right? B --> A is a question mark, if we use the NAT64+ which
does nothing with the L4 checksum, it is also not a problem. however, if we
use, as you mentioned before, an UDP-Lite-aware update of RFC6146, that may
updates the checksum while the BIH doesn't know that.

my point here is: what is the use case with the details of addressing? if
and only if A1 or A2 is configured with an RFC6052 or a MAP or a 4rd-U
address while NAT64+ has a pool of checksum-neutral IPv6 address to serve B
for the communications, A1 BIH or A2 CE may do the stateless processing
successfuly. if NAT64+ hasn't such a address pool for B, things will fail
because only one among src and dst is checksum-neutral.

> checksum-neutral.

1. without the V-octet, CE and NAT64 can also distinguish the 4rd-CE
addresses from others.
2. even with the V-octet, do you mean B's IPv4 address also translated (by
the NAT64+) to a CNP-and-V-containing IPv6 address?

if 2 is true, why you use stateful NAT64+ here for B rather than a
stateless one? if 2 is not true, then the NAT64 can use any arbitrary IPv6
address for B's communications, and such a case results only A's mapped
address is checksum-neutral, and thus anyway L4 adjustment is needed.

if 2 is true, i do suggest you naming NAT64+ as NAT64- instead, because
NAT64 doesn't have the limitation on the IPv6 address pool in use.

3. RFC6535 states, explicitly, "Use of BIH together with a NAT64 is NOT
RECOMMENDED [RFC6180]" (but the above technical discussion can omit this
for the time being).

- maoke

>>> > The point is that if a NAT64 is upgraded to support 4rd-u tunnels
>>> (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads.
>>> > Note that the NAT64 doesn't need to have CNP code. It just happens
>>> that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv4
>>> This is only true for the IPv6 host address. To construct an IPv6
>>> address when transmitting to  a 4rd-u CE, the NAT64 should compute a CNP.
>>> (This is to maintain the property that that middleboxes can treat tunnel
>>> packets as valid IPv6 packets. Not a big deal, but necessary).

---

From: Maoke <[email-masked]>
Date: Fri, 16 Mar 2012 01:07:03 +0000

on the other hand, may i suggest not to term "4rd tunnel" anymore? it
confuses. i emphasized it is NOT a TUNNEL to the common understanding at
all (but it seems you never?seldom respond to this point, nor to the ICMP
issue details. ) - maoke

---

From: Rémi Després <[email-masked]>
Date: Fri, 16 Mar 2012 09:28:22 +0100

2012-03-16 02:07, Maoke:

> 
> on the other hand, may i suggest not to term "4rd tunnel" anymore? it confuses. i emphasized it is NOT a TUNNEL to the common understanding at all

A "4rd" tunnel isn't "any" tunnel. 
It is only that which is defined by the 4rd-u specification.

> (but it seems you never?seldom respond to this point, nor to the ICMP issue details. ) - maoke

Having already answered (see just below), and having received so far no reaction on this subject, I don't think I should have done more.
Your complaining about my insufficiently answering is therefore undeserved (IMHO).

Please restate the ICMP issue you still have in mind.
I will try to answer (as usual).

"2012-03-09 09:49, Rémi Després :
> Exactly: 4rd uses header-mapping tunnels, and MAP-E uses encapsulation tunnels."

The fact is that there is no noticeable difference, e2e, between:
- IPv4 packets that are only natively routed
- IPv4 packets that are tunneled on their way any number of times (be it with 4rd tunnels or any other tunnels).

We have, I think, more important subjects to debate.

RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 16 Mar 2012 10:14:29 +0100

Maoke,

In a forthcoming answer to another of you emails, on thread "4rd-u tunnels and stateful NAT64s", I will try to describe more completely what the latest 4rd brings in the stateful NAT64 context.

...
>> 
>> Just referring to:
>> 
>> DS-RFC6145-host --(v6net) -- NAPT64 -- IPv4 Internet
(Typo corrected, as indicated in another email)
> then inside the host, there a RFC6145 module, right?

Right:
- RFC6535 says:
"When BIH is implemented at the network layer, the IPv4 packets are intercepted and converted to IPv6 using the IP conversion mechanism defined in the Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145].
- The v6ops draft on 464XLAT says that it combines "existing and well-known stateful protocol translation RFC 6146 in the core and stateless protocol translation RFC 6145 at the edge". 

> my point is, if there is no NAT64 module, this cannot talk with another NAT64 box elsewhere as only one of the (src,dst)-pair is stateless IPv4-converted IPv6 address.

In my understanding, this discussion is about *stateful* NAT64s (those that work for hosts having no assigned public IPv4 address).
There is then no "stateless IPv4-converted IPv6 address" in this context.

> my previous analysis doesn't matter whether the translator and the end host are separated or integrated into one box.

Not sure to understand the point (which translator, and why separated?).
Yet, I think there is no problem here.

RFC6535 on BIH says:
"The IETF recommends using solutions based on dual stack or tunneling for IPv6 transition and specifically recommends against deployments utilizing double protocol translation."

This is why it is AFAIK useful, in BIH- and/or 464XLAT-capable hosts, to add support of 4rd NAT64+ mapping rules. 
Benefit is that, with upgraded NAT64s (NAT64+ supporting 4rd tunneling), DS hosts having no public IPv4 address  can reach IPv4 servers without any RFC6145 translation (avoiding transparency limitations)

In the answer I will send on on the other thread, I plan to restate this, and explain in more details. 
If you agree, we could limit this discussion to the other thread.

Regards,
RD

---

From: Maoke <[email-masked]>
Date: Fri, 16 Mar 2012 09:59:44 +0000

2012/3/16 Rémi Després <[email-masked]>

> all

"a white horse is not a horse. " - ancient Chinese proverb. ;-) anyway i
won't be stubborn on this anymore. :)

> Having already answered (see just below), and having received so far no
> reaction on this subject, I don't think I should have done more.

http://www.ietf.org/mail-archive/web/softwires/current/msg03626.html
i don't think that's only a replicate of our previous discussion. even if
so, i guess this is the first time in the mail list.

regards,
maoke

---

From: Maoke <[email-masked]>
Date: Fri, 16 Mar 2012 10:34:23 +0000

> Maoke,
>
> In a forthcoming answer to another of you emails, on thread "4rd-u tunnels
> and stateful NAT64s", I will try to describe more completely what the
> latest 4rd brings in the stateful NAT64 context.
>
>
> "When BIH is implemented at the network layer, the IPv4 packets are
> intercepted and converted to IPv6 using the IP conversion mechanism defined
> in the Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145].
>

no different understanding here.

> - The v6ops draft on 464XLAT says that it combines "existing and
> well-known stateful protocol translation RFC 6146 in the core and stateless
> protocol translation RFC 6145 at the edge".
>
>
well, a new topic. i don't think you plan to apply CNP into v6ops-464xlat
/96 address format. do you?

>
> my point is, if there is no NAT64 module, this cannot talk with another
> NAT64 box elsewhere as only one of the (src,dst)-pair is stateless
> IPv4-converted IPv6 address.
>
>
> In my understanding, this discussion is about *stateful* NAT64s (those
> that work for hosts having no assigned public IPv4 address).

ok. then in BIH case, no case of stateless translator talking with stateful
NAT64. cleared.

>
> my previous analysis doesn't matter whether the translator and the end
> host are separated or integrated into one box.
>
>
>
> RFC6535 on BIH says:
> "The IETF recommends using solutions based on dual stack or tunneling for
> IPv6 transition and specifically recommends against deployments utilizing
> double protocol translation."
>

i remember people has clarified this. but my question is: do you mean 4rd
tunneling is a sort of the recommended tunneling? but the other message of
you said 4rd tunnel is not of "any" tunnel.

> Benefit is that, with upgraded NAT64s (NAT64+ supporting 4rd tunneling),
> DS hosts having no public IPv4 address  can reach IPv4 servers without any
> RFC6145 translation (avoiding transparency limitations)
>

actually i must say "NAT64+ mapping rule" is a very confusing concept. may
i understand it is a rule that, when the stateful translation is performed,
the translator using an (IPv4 addr, CNP) combination for the IID for an
IPv4 remote peer out of the domain? may i ask you for a detailed example on
how this NAT64+ address is used, with specifying a pair of source and
destination addresses, and explaining how such a scenario happens.

> Regards,
> RD
>
>
>
>
>
>
>
> - maoke
>
>
>> Clear enough?
>>
>> (seeing you have corrected the v4net with v6net) if it is a host
>> connected to an IPv6 network, it is the case of single NAT64, where we have
>> the problem of "interwork"?
>>
>>
>> See above.
>>
>> RD
>>
>>
>>
>> - maoke
>>
>>
>>>
>>>
>>> Is this excluded?
>>>
>>> RD
>>>
>>>
>>>

---

From: Rémi Després <[email-masked]>
Date: Fri, 16 Mar 2012 15:16:57 +0100

Maoke,

Let me try a more complete picture than before:

    A1 -----.           
RFC6145-host|           .-- 4rd BR --. 
            |           |            |
    A2 -----:--(v6net)--:            :--(v4 Internet)--- B 
  4rd-CE    |           |            |             UDP Lite appli                   
(no IPv4 @) |           '-- NAT64+ --' 
            |          
    A3 -----' 
  4rd-CE                                                
(IPv4 @, shared or not)

NAT64+ is supposed to have a bindings for UDP Lite, either only for 4rd IPv6 addresses (the minimum), or also for native IPv6 addresses (the complete upgrade, with UDP-Lite checksum adjustment for these addresses)

Connectivities I get are: 
 A2  => B (via NAT64+)
 A3 <=> B (via 4rd BR)
(There is no A1-B connectivity)

Anything missed?

Other detailed comments follow.

Le 2012-03-16 à 01:59, Maoke a écrit :

> yes, BIH uses RFC6145 that doesn't claim supporting UDP-Lite. but exactly speaking, if the "not support" means passing-it-through without checksum adjustment, A --> B is fine because neither BIH nor NAT64+ does nothing with the L4, right?

A NAT64 that supports UDP Lite MUST update checksum for hosts that have native IPv6 addresses.
That's why A1 => B doesn't work unless the NAT64 recognizes which packets are those of IPv4 applications in DS hosts.

> B --> A is a question mark, if we use the NAT64+ which does nothing with the L4 checksum, it is also not a problem.

> however, if we use, as you mentioned before, an UDP-Lite-aware update of RFC6146, that may updates the checksum while the BIH doesn't know that. 

Note that an upgrade of RFC6146 isn't needed for A NAT64 (and NAT64+) to support more protocols than the two required by the RFC. It is just an extension which cannot break anything (backward compatible).

> 
> my point here is: what is the use case with the details of addressing? if and only if A1 or A2 is configured with an RFC6052 or a MAP or a 4rd-U address while NAT64+ has a pool of checksum-neutral IPv6 address to serve B for the communications, A1 BIH or A2 CE may do the stateless processing successfuly. if NAT64+ hasn't such a address pool for B, things will fail because only one among src and dst is checksum-neutral. 

Sec 4.4 (8) says that a CE that targets an off-domain IPv4 address reaches the NAT64+ at this IPv6 address:

+-------------------------------+---+---+-------------+------+
|      NAT64+ IPv6 prefix       |"u"| 0 |DST IPv4 add.|  CNP |
+-------------------------------+---+---+-------------+------+
:               64              : 8 : 8 :      32     :  16  :

In the reverse direction, and for the same IPv4 address, it is the same IPv6 address that must be synthesized by the NAT64+.
This is I suppose implicit, but it can advantageously be made explicit in the draft.
Thanks.

> 1. without the V-octet, CE and NAT64 can also distinguish the 4rd-CE addresses from others. 

True, but while testing the V octet is sufficient in 4rd, the NAT64 has in MAP to process mapping rules to find for null subnet IDs whose lengths depend on which mapping rule applies.
That's IMHO one instance where the V-octet potential is clear.

> 2. even with the V-octet, do you mean B's IPv4 address also translated (by the NAT64+) to a CNP-and-V-containing IPv6 address? 

Yes (see above).

> if 2 is true, why you use stateful NAT64+ here for B rather than a stateless one?

Because we consider hosts that are not assigned any public IPv4 address, even shared.

> if 2 is not true, then the NAT64 can use any arbitrary IPv6 address for B's communications, and such a case results only A's mapped address is checksum-neutral, and thus anyway L4 adjustment is needed. 
> 
> if 2 is true, i do suggest you naming NAT64+ as NAT64- instead, because NAT64 doesn't have the limitation on the IPv6 address pool in use. 

Suggestion not retained ;-).
What you call the IPv6 address pool isn't a reserved pool: as explained above, NAT64+ synthesizes its IPv6 source addresses using its unchanged /64 prefix. 

> 3. RFC6535 states, explicitly, "Use of BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]" (but the above technical discussion can omit this for the time being). 

Right.

RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 16 Mar 2012 16:20:53 +0100

Maoke,

Please see inline.

Le 2012-03-16 à 11:34, Maoke a écrit :

> well, a new topic. i don't think you plan to apply CNP into v6ops-464xlat /96 address format. do you?

I don't plan to propose modifications of the informational draft on 464XLAT discussed in v6ops.

What I propose is entirely in 4rd-u draft-05.
- The goal is to better treat the 464XLAT *use case* that with its current protocol specification, exploiting for this what had been initially designed in the context of stateless solutions.
- This use case is AFAIK characterized by DS nodes (hosts and/or routers) attached to an IPv6-only network in which they have no statelessly assigned IPv4 addresses. 

> ok. then in BIH case, no case of stateless translator talking with stateful NAT64. cleared. 
>  
> 
> i remember people has clarified this. but my question is: do you mean 4rd tunneling is a sort of the recommended tunneling? but the other message of you said 4rd tunnel is not of "any" tunnel.

With 4rd tunnels between CE nodes and NAT64+, IPv4 applications in DS nodes can access IPv4-only servers without using twice RFC5145. (RFC6145 is actually not used at all, thus ensuring better IPv4 transparency.)

> actually i must say "NAT64+ mapping rule" is a very confusing concept. may i understand it is a rule that, when the stateful translation is performed, the translator using an (IPv4 addr, CNP) combination for the IID for an IPv4 remote peer out of the domain?

The draft defines the NAT64+ mapping rule as that which applies to IPv4 addresses reachable via a NAT64+.
It also says that its Rule IPv4 prefix is /0, that its EA-bits length is 32, and that it is used by CEs that are assigned no public IPv4 address (and that are in a Domains having a NAT64+).

> may i ask you for a detailed example on how this NAT64+ address is used, with specifying a pair of source and destination addresses, and explaining how such a scenario happens.

When you have seen further explanations I just gave on the specific thread on NAT64+, we will see what you still find unclear.

Regards,
RD

---

From: Maoke <[email-masked]>
Date: Mon, 19 Mar 2012 08:16:01 +0000

> NAT64+ is supposed to have a bindings for UDP Lite, either only for 4rd
> IPv6 addresses (the minimum), or also for native IPv6 addresses (the
> complete upgrade, with UDP-Lite checksum adjustment for these addresses)
>

A2 is IPv6-only, right? if so, let me go down.

> with the L4, right?
> That's why A1 => B doesn't work unless the NAT64 recognizes which packets
> are those of IPv4 applications in DS hosts.
>

A1 -> B doesn't need stateful NAT64 but stateless service is enough. well,
stateful is also ok. it is true NAT64 supporting UDP-Lite must update
checksum.

>
> B --> A is a question mark, if we use the NAT64+ which does nothing with
> the L4 checksum, it is also not a problem.
>
>
>
> however, if we use, as you mentioned before, an UDP-Lite-aware update of
> RFC6146, that may updates the checksum while the BIH doesn't know that.
>
>
> Note that an upgrade of RFC6146 isn't needed for A NAT64 (and NAT64+) to
> support more protocols than the two required by the RFC. It is just an
> extension which cannot break anything (backward compatible).
>

confusing. upgrade vs. extension??

> In the reverse direction, and for the same IPv4 address, it is the same
> IPv6 address that must be synthesized by the NAT64+.
>

this address is used for A2 or used for B? if you mean B, then may i
conclude that NAT64+ is serving between A2 (native IPv6 address with 4rd-U
CNP) and B (synthesized by NAT64+ into another IPv6-converted address
having CNP)? if i can, may i further conclude that NAT64+ serves only for
the case where A2 has the 4rd-U-style address?

if the A2 is configured with any IPv6 address, for example, address with
the autoconfigured EUI64 IID, it is out of the scope of the NAT64+, right?

if so, i do really suggest you call it NAT64- instead of NAT64+ because
NAT64 can also serve hosts with any native IPv6 address to connect with an
IPv4 peer.

your answer below didn't respond my question, sorry. for example (in the
use case of NAT64 instead of NAT64-), A2 has native IPv6 address
2001:db8:1234:5678:208:1fff:fe4d:606e while B is 192.32.77.50. the CE might
synthesize an IPv6 address for B, with the NAT64+ prefix and the 0xc0204d32
and a CNP embedded, say B', and let A2 connect to B' through IPv6; however,
when this packet goes through the NAT64+, because only B' is
checksum-neutral while A2 is not, NAT64+ passing it without L4 checksum
adjustment will make B receive a packet with wrong checksum, for any L4
protocols.

the above example works well for TCP and UDP with today's NAT64, without
limitations on A2's address.

- maoke

>   Because 4rd IPv6 addresses of CEs are distinguishable from all other
>>> IPv6 addresses (due to the V octet), NAT64s are concerned with CNPs ONLY
>>> for addresses that actually are 4rd CE addresses.
>>>
>>>
>>
> True, but while testing the V octet is sufficient in 4rd, the NAT64 has in
> MAP to process mapping rules to find for null subnet IDs whose lengths
> depend on which mapping rule applies.
> stateless one?
> if 2 is not true, then the NAT64 can use any arbitrary IPv6 address for
> B's communications, and such a case results only A's mapped address is
> checksum-neutral, and thus anyway L4 adjustment is needed.
>
> What you call the IPv6 address pool isn't a reserved pool: as explained
> above, NAT64+ synthesizes its IPv6 source addresses using its unchanged /64
> prefix.
>
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 19 Mar 2012 09:48:22 +0100

Le 2012-03-19 à 09:16, Maoke a écrit :

> A2 is IPv6-only, right?

There seems to be a misunderstanding on what is IPv6-only.
a) A2 is dual stack. Being a CE node, it supports IPv4 applications, and typically includes a NAT44. 
b) Its IPv6 prefix matches neither a CE nor the BR mapping rule, it has no assigned public IPv4 address (even shared).
c) Because it has received a NAT64+ mapping rule, it knows it can tunnel IPv4 packets to the NAT64+.

> if so, let me go down. 

Not so => doesn't apply. 
(Yet some further comments below)

RD

> A1 -> B doesn't need stateful NAT64 but stateless service is enough. well, stateful is also ok. it is true NAT64 supporting UDP-Lite must update checksum. 
>  
> 
> this address is used for A2 or used for B? if you mean B, then may i conclude that NAT64+ is serving between A2 (native IPv6 address with 4rd-U CNP) and B (synthesized by NAT64+ into another IPv6-converted address having CNP)? if i can, may i further conclude that NAT64+ serves only for the case where A2 has the 4rd-U-style address? 

Let me repeat that:
- NAT64+ works as a NAT64 for addresses that aren't 4rd-u style.
- The only difference is that NAT64+ has a plus for addresses that are those of 4RD-u CEs (better IPv4 transparency).

> if the A2 is configured with any IPv6 address, for example, address with the autoconfigured EUI64 IID, it is out of the scope of the NAT64+, right? 
> 
> if so, i do really suggest you call it NAT64- instead of NAT64+ because NAT64 can also serve hosts with any native IPv6 address to connect with an IPv4 peer.
> 
> your answer below didn't respond my question, sorry. for example (in the use case of NAT64 instead of NAT64-), A2 has native IPv6 address 2001:db8:1234:5678:208:1fff:fe4d:606e while B is 192.32.77.50. the CE might synthesize an IPv6 address for B, with the NAT64+ prefix and the 0xc0204d32 and a CNP embedded, say B', and let A2 connect to B' through IPv6; however, when this packet goes through the NAT64+,

> because only B' is checksum-neutral while A2 is not,

If the /64 of A2 is 2001:db8:1234:5678::/64, its 4rd IPv6 address is, per Fig 6, 2001:db8:1234:5678:3000::<CNP> 
It IS checksum neutral.

> NAT64+ passing it without L4 checksum adjustment will make B receive a packet with wrong checksum, for any L4 protocols. 
> 
> the above example works well for TCP and UDP with today's NAT64, without limitations on A2's address. 
> 
> - maoke
>

---

From: Maoke <[email-masked]>
Date: Mon, 19 Mar 2012 09:21:09 +0000

2012/3/19 Rémi Després <[email-masked]>

> b) Its IPv6 prefix matches neither a CE nor the BR mapping rule, it has no
> assigned public IPv4 address (even shared).
> - The only difference is that NAT64+ has a plus for addresses that are
> those of 4RD-u CEs (better IPv4 transparency).
>

accepted. but i have pointed out the "better transparency" has some cost
and uncertaity up to now (see another thread).

> when this packet goes through the NAT64+,
>
>

well, it is saying A2 must have the 4rd address in order to get the benefit
of NAT64-, right? i have typed "for example (in the use case of NAT64
instead of NAT64-), ..." as the prerequisite of the above discussion. let
me have the following propositions:

a. NAT64 suitable for any case no matter A2 is assigned with any kind of
address, but currently only works for TCP and UDP.
b. NAT64+ works for the cases where A2 is assigned with a special type of
IPv6 address with the CNP, without need to update checksum for any L4
protocols.
c. NAT64+ works like:
   if A2 has a V-CNP-address, then it doesn't update the checksum for any
L4 protocols;
   if A2 has any other kind of native IPv6 address, then NAT64+ works just
like NAT64, updating the checksum but also currently only works for TCP and
UDP.

i think we are common that a. is true, right? do you mean c. instead of b. ?

thanks,
maoke

>
> NAT64+ passing it without L4 checksum adjustment will make B receive a
> packet with wrong checksum, for any L4 protocols.
>
>> True, but while testing the V octet is sufficient in 4rd, the NAT64 has
>> in MAP to process mapping rules to find for null subnet IDs whose lengths
>> 2. even with the V-octet, do you mean B's IPv4 address also translated
>> (by the NAT64+) to a CNP-and-V-containing IPv6 address?
>>
>>
>> Yes (see above).
>>

---

From: Rémi Després <[email-masked]>
Date: Mon, 19 Mar 2012 11:22:49 +0100

Le 2012-03-19 à 10:21, Maoke a écrit :

> accepted. but i have pointed out the "better transparency" has some cost and uncertaity up to now (see another thread). 
>  
> 
> 
> well, it is saying A2 must have the 4rd address in order to get the benefit of NAT64-, right?

(*) For native IPv6, it has whatever address applies (that of your example is OK).
Its CE is reached with all destination addresses starting with the site /64 followed by with the V octet.  

> i have typed "for example (in the use case of NAT64 instead of NAT64-), ..." as the prerequisite of the above discussion. let me have the following propositions: 
> 
> a. NAT64 suitable for any case no matter A2 is assigned with any kind of address, but currently only works for TCP and UDP. 

Yes (but with the DF bit transparency limitation that is avoided in case of NAT64+)

> b. NAT64+ works for the cases where A2 is assigned with a special type of IPv6 address with the CNP, without need to update checksum for any L4 protocols. 
> c. NAT64+ works like: 
>    if A2 has a V-CNP-address, then it doesn't update the checksum for any L4 protocols; 
>    if A2 has any other kind of native IPv6 address, then NAT64+ works just like NAT64, updating the checksum but also currently only works for TCP and UDP. 
> 
> i think we are common that a. is true, right?

Right, with the caveat above.

> do you mean c. instead of b. ?

NAT64+ works like NAT64 in all cases, except for 4rd CEs that:
- received a NAT64+ mapping rule
- have IPv6 prefixes from which no IPv4 address can be derived.
For them, better transparency is achieved by replacing double RFC6145 translation by a Reversible header mapping. 

That's IMHO clear enough, especially with the (*) above which clarifies AFAIK which native and 4rd IPv6 addresses are used by CEs.

Cheers,
RD

---

From: Maoke <[email-masked]>
Date: Mon, 19 Mar 2012 10:44:57 +0000

>> b) Its IPv6 prefix matches neither a CE nor the BR mapping rule, it has
>> no assigned public IPv4 address (even shared).
>>>>> A NAT64+ is a *backward compatible* extension of NAT64 (everything
>>>>> that worked before still works completely unchanged).
>>>>>
>>>>> The draft says:
>>> yes, BIH uses RFC6145 that doesn't claim supporting UDP-Lite. but
>>> exactly speaking, if the "not support" means passing-it-through without
>>> checksum adjustment, A --> B is fine because neither BIH nor NAT64+ does
>>> nothing with the L4, right?
>>>
>>>
>>> That's why A1 => B doesn't work unless the NAT64 recognizes which
>>> packets are those of IPv4 applications in DS hosts.
>>>
>>
>> A1 -> B doesn't need stateful NAT64 but stateless service is enough.
>> well, stateful is also ok. it is true NAT64 supporting UDP-Lite must update
>> checksum.
>>
>>
>>>
>>>  B --> A is a question mark, if we use the NAT64+ which does nothing
>>> with the L4 checksum, it is also not a problem.
>>>
>>>
>>>
>>> my point here is: what is the use case with the details of addressing?
>>> if and only if A1 or A2 is configured with an RFC6052 or a MAP or a 4rd-U
> i have typed "for example (in the use case of NAT64 instead of NAT64-),
> ..." as the prerequisite of the above discussion. let me have the following
> propositions:
>
> For them, better transparency is achieved by replacing double RFC6145
> translation by a Reversible header mapping.
>

not yet cleared. "receives a NAT64+ mapping rule" for what? is the NAT64+
mapping rule stateless or stateful? what the behavior of NAT64+ in the case
of "except"? is there "and" or "or" between the "received ..." and the
"have IPv6 prefixes..." clauses?

please answer directly: do you mean c. instead of b.? (or, if either is not
applied, and you may have d.)

thanks,
maoke

>
> That's IMHO clear enough, especially with the (*) above which clarifies
> AFAIK which native and 4rd IPv6 addresses are used by CEs.
>
>
> Cheers,
> RD
>
>
>
>
>
> thanks,
> maoke
>
>
>
>>

---

From: Naoki Matsuhira <[email-masked]>
Date: Wed, 21 Mar 2012 09:29:43 +0900

Dear Chairs,

I would like to ask a presentation slot for "SA46T interoperability test 
report" again.

I understand the agenda of softwire wg already full, so I ask add this 
report to the last of the agenda, and If the agenda finished early, 
please give the chance for presentation.

This test was done at WIDE camp spring 2012 on this march 5 - 8, and 
SA46T also serve IPv4 connectivity in IPv6-only network experiments 
which will be present at v6ops wg in this IETF meeting. This test 
results are useful for this wg, and interoperability test report also 
helpful and very very timely and hot topics, I believe.

Regards,

Naoki Matsuhra

---

From: Rémi Després <[email-masked]>
Date: Sat, 24 Mar 2012 09:24:46 +0100

...
>>  let me have the following propositions: 
>> 

Seems right: no L4 update for IPv6 addresses having 4rd-U format.

>>    if A2 has any other kind of native IPv6 address, then NAT64+ works just like NAT64, updating the checksum but also currently only works for TCP and UDP. 

Seems right too, and more precise. 

> not yet cleared. "receives a NAT64+ mapping rule" for what?

A CE receives the NAT64 mapping rule to know that, although it has no public IPv4 address, it can reach IPv4 servers via NAT64+, and thus avoid any v4/v6 translation (more transparent).

> is the NAT64+ mapping rule stateless or stateful?

The rule per se is neither. It just says what the CE has to do if having no public IPv4 address.
What the NAT64+ must be stateful, at least for IPv6 addresses that are not mapped to any public IPv4 address.

> what the behavior of NAT64+ in the case of "except"? is there "and" or "or" between the "received ..." and the "have IPv6 prefixes..." clauses?

Not understood.

> please answer directly: do you mean c. instead of b.? (or, if either is not applied, and you may have d.) 

If pressed to make a choice, c. seems a better expression of what is specified than b.  

Cheers,
RD

(Retransmitted with much unnecessary text deleted. The message was refused as being too long for the mailing list)

---

From: Rémi Després <[email-masked]>
Date: Fri, 23 Mar 2012 18:46:52 +0100

>> b. NAT64+ works for the cases where A2 is assigned with a special type of IPv6 address with the CNP, without need to update checksum for any L4 protocols.

Seems right.

>>    if A2 has any other kind of native IPv6 address, then NAT64+ works just like NAT64, updating the checksum but also currently only works for TCP and UDP. 

Seems right too.

> not yet cleared. "receives a NAT64+ mapping rule" for what?

To know what to do with IPv4 packets if assigned no public IPv4 address.

> is the NAT64+ mapping rule stateless or stateful?

The rule is neither. It just says what the CE has to do if having no public IPv4 address.
What the NAT64+ must be stateful, at least for IPv6 addresses that are not mapped to any public IPv4 address.

Not understood.

> please answer directly: do you mean c. instead of b.? (or, if either is not applied, and you may have d.) 

If pressed to make a choice, c. seems closer to what I described.

RD