Subject: Re: [MEXT] AD review of mext-nemo-v4traversal - CoA selection

From: Hesham Soliman <[email-masked]>
Date: Tue, 28 Oct 2008 00:08:40 +1100

Hi Jari,

I'm sorry this took so long. I'll have a new rev next week with your
comments handled as discussed on the list. There is one comment that
requires text. This comment:

> This is the priority, but its also likely to have the same problems as
> we have with dual stack hosts getting long timeouts due to trying out
> broken IPv6 connectivity. Look at the Stuart Cheshire's technical
> plenary presentation, for instance. I would suggest that you have an
> explicit specification of the recovery mechanism: trying out both in
> parallel, trying one first and then falling back -- I do not have the
> details but you have to have a recovery mechanism.

I suggest the following text:

When a mobile node is in a dual stacked visited network, it will have a
choice between an IPv4 and an IPv6 care-of address. The mobile node SHOULD
prefer the IPv6 care-of address and bind it to its home address(es). If a
mobile node attempted to bind the IPv6 care-of address to its home
address(es) and the binding update timed out, the mobile node SHOULD:

- Resend the binding update using the exponential back-off algorithm
described in [RFC3775].
- If after three attempts in total a binding acknowledgement was not
received, the mobile node SHOULD send a new binding update using the IPv4
care-of address. The exponential backoff algorithm described in [RFC3775]
should be used for re-transmission of the binding update if needed.

This procedure should be used to avoid scenarios where IPv6 connectivity may
not be as reliable as IPv4. This may take place during early deployments of
IPv6, or simply due to temporary outages affecting IPv6 routing.

It is RECOMMENDED that upon movement the mobile node does not change the IP
address family chosen for the previous binding update unless the mobile node
is aware that it has moved to a different administrative domain where
previous problems with IPv6 routing may not be present. Repeating the above
procedure upon every movement can cause significant degradation of the
mobile node's applications' performace due to extended periods of packet
losses after handover if the routing outage is still in effect.

When using an IPv4 care-of address and IP in IP encapsulation, if the mobile
node implementation is made aware by upper layers of persistent packet
losses , it may attempt to resend the binding update with the F flag set,
requesting UDP encapsulation for all packets. This may avoid packet losses
due to situations where local firewalling policies prevent the use of IP in
IP encapsulation. 

The effect of these address selection mechanism is to allow the follwing
preferences:
1. IPv6 
2. IPv4 (using IP in IP or UDP encapsulation if a NAT is detected)
3. UDP encapsulation when no NAT is detected but IP in IP is not allowed by
the local domain.

> 
> Similarly, it would be very useful if the document contained better
> instruction about when a mobile node sets the F flag. If there is no NAT
> but a firewall, the mobile node may wish to use UDP encapsulation. Would
> it be possible to have the mobile node revert back UDP encapsulation if
> the direct encapsulation does not appear to be working?
> 

=> See the second last paragraph above. I think it's not a good solution but
I'll wait for your response. I can't think of a cleaner way of doing this.

Comments?

Hesham

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