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

[Maoke <[e-mail]>]

2012/3/12 Maoke <[e-mail]>

>
> 2012/3/9 Rémi Després <[e-mail]>
>
>> Maoke,
>> Thanks for the detailed question.
>> Clarification below.
>>
>>
>> 2012-03-09 12:04, Maoke  :
>>
>> 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;
>>    }
>>
>>
>> No. R-7 (3) isn't ambiguous about this.
>>
>>
>> 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 */
>>    }
>>
>>
>> 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.
>>
>>
>
> 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?
>

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


>
> RFC6145 has no such dependence at all.
>
> - maoke
>
>
>>
>>
>> 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.
>>
>>
>> See above why B has no operational risk.
>>
>> Thanks,
>> RD
>>
>>
>>
>>
>>
>>
>>
>>>
>>>  >>>> 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
>>>>
>>>
>>>
>>>
>>
>>
>