Re: [Softwires] 4rd-u tunnels and stateful NAT64s

[Maoke <[e-mail]>]

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

>
> Le 2012-03-19 à 10:21, Maoke a écrit :
>
>
>
> 2012/3/19 Rémi Després <[e-mail]>
>
>>
>> Le 2012-03-19 à 09:16, Maoke a écrit :
>>
>>
>>
>> 2012/3/16 Rémi Després <[e-mail]>
>>
>>> 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)
>>>
>>
>> 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
>>
>>
>>
>>
>>>
>>> Anything missed?
>>>
>>>
>>> Other detailed comments follow.
>>>
>>> Le 2012-03-16 à 01:59, Maoke a écrit :
>>>
>>>
>>>
>>> 2012/3/15 Rémi Després <[e-mail]>
>>>
>>>>
>>>> Le 2012-03-15 à 14:47, Maoke a écrit :
>>>>
>>>>
>>>>
>>>> 2012/3/15 Rémi Després <[e-mail]>
>>>>
>>>>>
>>>>> 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."
>>>>>
>>>>>
>>>>
>>>> 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
>>>>
>>>>
>>> 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.
>>>
>>
>> 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??
>>
>>
>>>
>>>
>>>
>>> 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 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).
>>
>
> accepted. but i have pointed out the "better transparency" has some cost
> and uncertaity up to now (see another thread).
>
>
>>
>>
>> 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.
>>
>
> 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.
>

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
>
>
>
>>
>> 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
>>
>>
>>> This is I suppose implicit, but it can advantageously be made explicit
>>> in the draft.
>>> Thanks.
>>>
>>>
>>>   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.
>>>>
>>>> Correct, iff the host address has the V octet.
>>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>> - maoke
>>>
>>>
>>>>
>>>>  i cannot imagine what the use case is. please specify!
>>>>
>>>>
>>>> Hope the picture above helps.
>>>>
>>>> RD
>>>>
>>>>
>>>>
>>>>
>>>> - maoke
>>>>
>>>>
>>>>>
>>>>>
>>>>> RD
>>>>>
>>>>>
>>>>> - maoke
>>>>>
>>>>> 2012/3/15 Rémi Després <[e-mail]>
>>>>>
>>>>>>
>>>>>> Le 2012-03-15 à 10:59, Rémi Després a écrit :
>>>>>>
>>>>>> > 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)
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> >
>>>>>> > RD
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > Softwires mailing list
>>>>>> > [e-mail]
>>>>>> > https://www.ietf.org/mailman/listinfo/softwires
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>