Re: Tunnel-to-NAT scenario

[Jari Arkko <[e-mail]>]

Remi,

> In this respect, The APBP-E2E scenario of draft-despres-v6ops-apbp-00
> sec. 5.2 goes *one step further* than Tunnel-to-NAT.
>
> When a (modified) dual stack client connects to a v4-only server:
> - v4 packets are unchanged E2E.
> - The (dual stack) client application sees its public v4 address, so 
> that no NAT is needed.
>
> It then seems that, if and when time comes to discuss the APBP 
> protocol, after the problem statement, Softwires would be the right 
> place.

Does APBP involve host changes?

The work put to SOFTWIRE is a very specific task: cross the v6-only 
cloud using tunneling, allow optional fairly standard NATting at the 
other side to handle overlapping RFC1918 space, no changes at all in the 
subscriber sites or hosts. That WG has a lot of expertise in getting 
tunneling like this to work.

However, generally speaking other protocol work will go elsewhere, as 
soon as we know what that work is. The reason why SOFTWIRE is having a 
head start is that they are attacking a separable, reasonably well 
understood part of the overall space that fits the profile of an 
existing WG. We are looking at rechartering BEHAVE for the rest of the work.

Jari