Re: [renum] FW: New Version Notification for draft-liu-6renum-gap-analysis-02.txt

[Brian E Carpenter <[e-mail]>]

Wes,

You said:

> - no current mechanism exists to signal to the remote side of an active session that the local side's IP address is changing (in effect, "please send subsequent packets to this new address, retaining the current src/dst port and sequence numbers") - a change of address notification

Not completely so. SHIM6 is a proposed standard with running code that does
most of this, although there are some complicated security issues around
*adding* a new address to the existing address set. If you don't make
that secure, it is a major opportunity for session hijacking.

It was the session survivability requirement that led to shim6, of course.

I think there's scope for analysing shim6 in the context of renumbering.
It wasn't really a consideration during the design.

> - this may have value in the mobility space as a way to manage session continuity even during network to network handoffs without the need for map-and-encap methods

I think it's isomorphic. In MIPv6 we can have a change of c/o address without
a change of home address. The home address acts as the session ID. In a
notification model we have a change of locator without a change of ID (in
the shim6 case, the ID is the initial choice of locator).

In all cases, session survivability requires a persistent ID of some
kind, as far as the transport layer is concerned.

We do need to decide how much of a goal session survivability is. IMHO it
is a hard goal, and it only affects a very small number of applications.

Regards
   Brian

On 2011-11-12 13:33, George, Wes wrote:
> <WG Chair hat off>
> 
> sect 2 session survivability - This discussion is pretty weak right now. While it is a benefit to be able to use make-before-break numbering as described, that's not session survivability. All it allows for is for new sessions to use the new address. It does not necessarily fix sessions that go idle and attempt to resume where they've left off, and it definitely doesn't cover sessions that remain active.
> Inherent to the behavior of most TCP and UDP sessions is the expectation that while the session is active, a change in the IP address will result in a session reset. In a planned renumbering event, this may be acceptable in some cases (done during a maintenance window, etc). But since we are endeavoring to minimize the impacts of renumbering in order to make it more palatable, I think it's worth discussing real session survivability in the context of our gap analysis. Therefore we need to note a couple of items/gaps:
> - client/server relationships are often built on an assumption that the client's IP address will not change for the duration of a session, and if it does, it's a different session (eg log into a website, and if your IP changes, you must re-authenticate) - this may already be a faulty assumption given SLAAC/Privacy Addresses, because addresses do often change, and in a post-CGN world, tying addresses to a given session is probably going to create difficulties as well, but it's worth noting here.
> - no current mechanism exists to signal to the remote side of an active session that the local side's IP address is changing (in effect, "please send subsequent packets to this new address, retaining the current src/dst port and sequence numbers") - a change of address notification
>         - this may have value in the mobility space as a way to manage session continuity even during network to network handoffs without the need for map-and-encap methods, so it's probably something that should be pursued anyway. While using hostnames to abstract host from IP will help for incoming connections, existing sessions would be able to bypass the impact on the DNS infrastructure driven by the need for near-real-time changes to the FQDN-IP mapping if there is a method to manage in-flight changes directly, and allow DNS changes to be made with slightly longer turnaround times instead of near-realtime.
>         - this would likely give stateful security devices fits unless they are designed to watch for these messages and update their state accordingly
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Leo Liu(bing)
>> Sent: Monday, October 31, 2011 8:11 AM
>> To: [e-mail]
>> Subject: [renum] FW: New Version Notification for draft-liu-6renum-gap-
>> analysis-02.txt
>>
>> Hi, all
>>
>> Here's the new version of gap analysis.
>> As suggested after the last meeting, we tried to put all the gaps
>> documented in other drafts/RFCs into this version. And we put the gaps
>> we considered as out of the scope or unsolvable to the appendix.
>> Some rough consensus about several open questions was included in this
>> version.
>>
>> Regards,
>> Bing
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Monday, October 31, 2011 8:05 PM
>> To: Leo Liu(bing)
>> Cc: Sheng Jiang; [e-mail]; Leo Liu(bing)
>> Subject: New Version Notification for draft-liu-6renum-gap-analysis-
>> 02.txt
>>
>> A new version of I-D, draft-liu-6renum-gap-analysis-02.txt has been
>> successfully submitted by Bing Liu and posted to the IETF repository.
>>
>> Filename:      draft-liu-6renum-gap-analysis
>> Revision:      02
>> Title:                 IPv6 Site Renumbering Gap Analysis
>> Creation date:         2011-10-31
>> WG ID:                 Individual Submission
>> Number of pages: 20
>>
>> Abstract:
>>    This document briefly introduces the existing mechanisms could be
>>    utilized by IPv6 site renumbering and envisions the effort could be
>>    done. This document tries to cover the most explicit issues and
>>    requirements of IPv6 renumbering. Through the gap analysis, the
>>    document provides a basis for future work to identify and develop
>>    solutions or to stimulate such development as appropriate. The gap
>>    analysis is presented following a renumbering event procedure clue.
>>
>>
>>
>>
>>
>>
>> The IETF Secretariat
>> _______________________________________________
>> renum mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/renum
> 
> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
> _______________________________________________
> renum mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/renum
>