Subject: Re: [Softwires] Path to move forward with 4rd?

From: "Justin Chen" <[email-masked]>
Date: Mon, 26 Mar 2012 10:17:19 +0800

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
[email-masked]
发送时间: 2012年3月25日 1:47
收件人: [email-masked]
主题: Softwires Digest, Vol 76, Issue 94

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/softwires

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or
Plain Text Digests?" to MIME.  You can set this option globally for all the
list digests you receive at this point.

Send Softwires mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/softwires
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Softwires digest..."

Today's Topics:

   1. Re: Path to move forward with 4rd? (Jan Zorz @ go6.si)
   2. Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th	from
      15h30 to 17h00 room #201 at IETF in Paris (Alistair Woodman)
   3. Re: Path to move forward with 4rd? (R?mi Despr?s)
   4. Re: 4rd-u tunnels and stateful NAT64s (R?mi Despr?s)

----------------------------------------------------------------------

Message: 1
Date: Sat, 24 Mar 2012 17:29:43 +0100
From: "Jan Zorz @ go6.si" <[email-masked]>
To: [email-masked]
Subject: Re: [Softwires] Path to move forward with 4rd?
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=windows-1252; format=flowed

On 3/23/12 4:04 AM, Guanghui Yu wrote:
> Hi Yiu
>
>     4rd-u changes the IPv6 header architecture (redefine fragmentation 
> header extension) and IPv6 address architecture (different meaning of 
> u-bit when g-bit=1). These are the fundamental changes. If 4rd-u 
> becomes the standard, then there will be new defined ?IPv6?
> packets on the Internet, which are not compatible with existing IPv6 
> packets and no existing devices can understand those packets.

Exactly.

+1

Cheers, Jan Zorz

+1

Justin Chen

------------------------------

Message: 2
Date: Sat, 24 Mar 2012 09:37:53 -0700
From: "Alistair Woodman" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday
	25th	from 15h30 to 17h00 room #201 at IETF in Paris
Message-ID: <356701cd09dc$7872b190$695814b0$@org>
Content-Type: text/plain; charset="us-ascii"

All, you are cordially invited.

Francis Dupont, Paul Selkirk and Alain Durant are hosting a live demo of
draft-penno-softwire-sdnat-02. 

The following will be shown:

1) Stateless DS-Lite

2) Stateless CPE B4 NAT

3) Anycast Failover

4) DHCPv4 proxy over v6

5) NAT Port range re-allocation via ICMP method.

When:                  Sunday the 25th from 15h30 to 17h00.

Where:                 Room #201 (Front left of Hall Maillot when facing
Porte Maillot), IETF 83, Paris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/softwires/attachments/20120324/fa23069
f/attachment.htm>

------------------------------

Message: 3
Date: Sat, 24 Mar 2012 17:58:25 +0100
From: R?mi Despr?s <[email-masked]>
To: Jan Zorz @ go6.si <[email-masked]>
Cc: [email-masked]
Subject: Re: [Softwires] Path to move forward with 4rd?
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=windows-1252

Hi, Jan,

Please see my answer to Guanghui.

Thanks,
RD

Le 2012-03-24 ? 17:29, Jan Zorz @ go6.si a ?crit :

> On 3/23/12 4:04 AM, Guanghui Yu wrote:
>> Hi Yiu
>> 
>>   4rd-u changes the IPv6 header architecture (redefine fragmentation 
>> header extension) and IPv6 address architecture (different meaning of 
>> u-bit when g-bit=1). These are the fundamental changes. If 4rd-u 
>> becomes the standard, then there will be new defined ?IPv6?
>> packets on the Internet, which are not compatible with existing IPv6 
>> packets and no existing devices can understand those packets.
> 
> Exactly.
> 
> +1
> 
> Cheers, Jan Zorz
> 
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

------------------------------

Message: 4
Date: Fri, 23 Mar 2012 18:46:52 +0100
From: R?mi Despr?s <[email-masked]>
To: Maoke <[email-masked]>
Cc: Softwires WG <[email-masked]>
Subject: Re: [Softwires] 4rd-u tunnels and stateful NAT64s
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

Le 2012-03-19 ? 11:44, Maoke a ?crit :

> 
> 
> 2012/3/19 R?mi Despr?s <[email-masked]>
> 
> Le 2012-03-19 ? 10:21, Maoke a ?crit :
> 
>> 
>> 
>> 2012/3/19 R?mi Despr?s <[email-masked]>
>> 
>> Le 2012-03-19 ? 09:16, Maoke a ?crit :
>> 
>>> 
>>> 
>>> 2012/3/16 R?mi Despr?s <[email-masked]> 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 
>>> NAT64+ 4rd IPv6 addresses (the minimum), or also for native IPv6 
>>> NAT64+ addresses (the complete upgrade, with UDP-Lite checksum 
>>> NAT64+ 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 <[email-masked]>
>>>> 
>>>> Le 2012-03-15 ? 14:47, Maoke a ?crit :
>>>> 
>>>>> 
>>>>> 
>>>>> 2012/3/15 R?mi Despr?s <[email-masked]>
>>>>> 
>>>>> 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.

Seems right.

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

Seems right too.

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

To know what to do with IPv4 packets if assigned no public IPv4 address.

> is the NAT64+ mapping rule stateless or stateful?

The rule is neither. It just says what the CE has to do if having no public
IPv4 address.
What the NAT64+ must be stateful, at least for IPv6 addresses that are not
mapped to any public IPv4 address.

> what the behavior of NAT64+ in the case of "except"? is there "and" or
"or" between the "received ..." and the "have IPv6 prefixes..." clauses?

Not understood.

> please answer directly: do you mean c. instead of b.? (or, if either 
> is not applied, and you may have d.)

If pressed to make a choice, c. seems closer to what I described.

RD

> 
> 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 <[email-masked]>
>>>>>> 
>>>>>> 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-masked]
>>>>>> > https://www.ietf.org/mailman/listinfo/softwires
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/softwires/attachments/20120323/7b71236
d/attachment.htm>

------------------------------

_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

End of Softwires Digest, Vol 76, Issue 94
*****************************************