Subject: a comment on nat requirements draft

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Jun 2008 20:22:21 +0300

I was reading the requirements draft today, and I noticed this:

>    I5: MIPv6 support
>
>    The translation mechanism SHOULD not prevent MIPv6 Route Optimization
>    when the CN is a v4-only node
I'm not sure this requirement makes a lot of sense. An IPv4-only node 
clearly does not have any Mobile IPv6 code in it. Even if by some magic 
the RO packets were made to go through the NAT, the peer would drop them 
on the floor :-)

I actually believe R3 (allowing the use of native connectivity when 
dual-stack is available) already covers most of what we want to say 
about mobility in this context. That is, the NATted path should not take 
precedence over the native IPv6 path, because otherwise many things 
currently possible in IPv6 no longer work.

I don't know if you want to remove I5 altogether or consider saying 
something else. There is a need to allow two dual-stack hosts, one in 
v6-only network and the other in a v4-only network, to be able to use 
Mobile IPv6 route optimization with each other. But I don't know if our 
future NAT spec needs to include that, or if its simply an additional 
scenario for the Mobile IPv6 Dual Stack spec. That spec already allows a 
dual-stack mobile node to connect to its home agent over v4-only networks.

Jari

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 17 Jun 2008 22:05:37 +0200

Jari Arkko escribió:
> clearly does not have any Mobile IPv6 code in it. Even if by some 
> magic the RO packets were made to go through the NAT, the peer would 
> drop them on the floor :-)
what people had in mind was that the NAT box could perform the RO on 
behalf of the v4 CN, but some people already said that this wasn't that 
useful neither, what do you think?

regards, marcelo

> about mobility in this context. That is, the NATted path should not 
> take precedence over the native IPv6 path, because otherwise many 
> things currently possible in IPv6 no longer work.
>
> Mobile IPv6 route optimization with each other. But I don't know if 
> our future NAT spec needs to include that, or if its simply an 
> additional scenario for the Mobile IPv6 Dual Stack spec. That spec 
> already allows a dual-stack mobile node to connect to its home agent 
> over v4-only networks.
>
> Jari
>
>
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Jun 2008 23:25:42 +0300

Marcelo,

> behalf of the v4 CN, but some people already said that this wasn't 
> that useful neither, what do you think?

Uh-oh.

That might be doable in the base RFC 3775 mobility, but not in any of 
the extensions (shared secret keying for RO, for instance).

I question the goal to attempt full feature parity. I would spend your 
cycles more wisely and try to make sure that if both v4 and v6 are 
available, you choose v6, making it possible to use any feature.

Or in my opinion this is right at least for mobility route optimization. 
It is indeed just an optimization. Even with direct IPv6 connectivity 
there is no way to guarantee that the optimization is supported by the 
implementation of the peer, accepted policy-wise by the peer, or passes 
through firewalls in between. That's why the optimization is designed to 
be fail-safe. If you can turn it on, great. If you cannot, things will 
still work.

Jari

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 17 Jun 2008 23:02:41 +0200

so, i understand that you are ok with dropping this one?

Jari Arkko escribió:
> Or in my opinion this is right at least for mobility route 
> optimization. It is indeed just an optimization. Even with direct IPv6 
> connectivity there is no way to guarantee that the optimization is 
> supported by the implementation of the peer, accepted policy-wise by 
> the peer, or passes through firewalls in between. That's why the 
> optimization is designed to be fail-safe. If you can turn it on, 
> great. If you cannot, things will still work.
>
> Jari
>
>
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 18 Jun 2008 00:28:52 +0300

Yes.

Jari

marcelo bagnulo braun wrote:
>> I question the goal to attempt full feature parity. I would spend 
>> your cycles more wisely and try to make sure that if both v4 and v6 
>> are available, you choose v6, making it possible to use any feature.
>>
>> optimization. It is indeed just an optimization. Even with direct 
>> IPv6 connectivity there is no way to guarantee that the optimization 
>> is supported by the implementation of the peer, accepted policy-wise 
>> by the peer, or passes through firewalls in between. That's why the