Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd

[Maoke <[e-mail]>]

2012/3/9 Rémi Després <[e-mail]>

> 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.
>
> 2012/3/8 Rémi Després <[e-mail]>
>
>>
>> Le 2012-03-08 à 03:47, Washam Fan a écrit :
>>
>> > Hi Remi,
>> >
>> >>>>> Secondly, -04 added NAT64+ parts.
>> >>>>> 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)
>>
>
> 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)
>
>
> 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."
>


 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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+).
>> >>>> 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.
>>
>
> 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).
>

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


>
> 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              "
>
> 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.

> >>>
>> >>> 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).
>> >
>> > Can I interpret NAT64+ as 4rd BR co-located with NAT64? What justify a
>> > 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).
>>
> confused. how does NAT64+ happens at BR? without the V octet, NAT64 needs
not to be upgraded at all.

>
>>
>> >
>> >> 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).
>> >>
>> >
>> > 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.
>>
>
Remi didn't answer this question of Washam. 4rd-U keeps only stateful NAT64
as it is at CE, to my understanding.


>
> 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)
>

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


>
> 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.
>

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.


>  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.
>

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
>
>
>> 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
>> >>> Such transparency could be achieved by whther to add fragmentation
>> header.
>> >>> Anyway, let's hear some comments from the group
>> >>
>> >> OK
>>
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>
>
>