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

[Maoke <[e-mail]>]

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