2012/3/9 Rémi Després <[email protected]>
> Maoke,
> Thanks for the detailed question.
> Clarification below.
>
>
> 2012-03-09 12:04, Maoke :
>
> 2012/3/9 Rémi Després <[email protected]>
>
>> 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 <[email protected]>
>>
>>>
>>> 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?
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
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>
>>
>>
>
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
