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)
Anything missed?
Other detailed comments follow.
Le 2012-03-16 à 01:59, Maoke a écrit :
>
>
> 2012/3/15 Rémi Després <[email protected]>
>
> Le 2012-03-15 à 14:47, Maoke a écrit :
>
>>
>>
>> 2012/3/15 Rémi Després <[email protected]>
>>
>> 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.
> 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).
>
> 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 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 <[email protected]>
>>>
>>> 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
>>> > [email protected]
>>> > https://www.ietf.org/mailman/listinfo/softwires
>>>
>>>
>>
>>
>
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
