how mobile do we want to be

[Iljitsch van Beijnum <iljitsch@muada.com>]

In the discussion in the BOF yesterday there were different viewpoints 
on the relationship between mobility and multihoming in general and 
shim6 in particular.

Apparently, some people are equating renumbering with mobility. Now 
obviously mobility mechanisms can be used to renumber without skipping 
a beat, but that doesn't mean mobility and renumbering are the same 
thing.

I think the important difference is the timescale. In mobility, the 
assumption is that TCP sessions and other state are longer-lived than 
locator addresses. In site renumbering, I very much doubt that this is 
the case. At the very least, we're talking about the order of days 
here, and _very_ few sessions or associations last for days. So in 
nearly all cases, site renumbering can be addressed with regular 
stateless autoconfiguration address deprecation.

Please don't forget: adding a new address in the middle of a session is 
a security nightmare. The only way this can be done reasonably is with 
the help of strong crypto (magic PKI dust) or a home agent that is 
impervious to on-path nastiness such as sniffing and MitM. Obviously, 
for a good number of applications strong crypto isn't a problem as they 
already use it today. But mandating strong crypto for *everything* is 
very problematic for reasons of performance, configuration and 
robustness. (Let the person who never clicked "accept" on an SSL 
warning cast the first stone here.)

I think HBAs are a very good compromise between reasonable security and 
usability. It would be a shame to throw this out the window just so one 
or two applications are saved from reconnecting once in a blue moon. It 
takes a lot of reconnects to waste the same amount of time that it 
takes to obtain and install an X.509 certificate...