[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tunnel-to-NAT scenario



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