RE: Open question and Critical dependencies

["Bound, Jim" <jim.bound@hp.com>]

Brian,

Well then that needs to be in the charter and may still be discussion
point. This is a new working group and not all have ever bought into the
shim at all but to work on it. Even the spec has research flavor.
Industry is not going to implement research even if the IETF specifies
it.

The way it works is if the application restarts ergo TCP RESTART, UDP
disconnect.

The shim should be isolated to the node to solve its multhoming problem.

Otherwise the shims must be passed and the address pairs are not used
and that is highly questionable at the end of the day the address pairs
should still be used for end-to-end communications and that must be part
of the ULID strategy.  Changing the address pairs say for TCP session is
a completely different problem for implementation and if we want to do
that too then we are really on the wrong path here and SCTP is clearly
the way to do that.

/jim 

> -----Original Message-----
> From: Brian E Carpenter [mailto:brc@zurich.ibm.com] 
> Sent: Monday, March 28, 2005 9:09 AM
> To: Bound, Jim
> Cc: Iljitsch van Beijnum; Dave Crocker; shim6
> Subject: Re: Open question and Critical dependencies
> 
> Jim,
> 
> shim6 is a solution with state at both ends. I don't know
> how to make a solution with state at both ends work when
> there is only state at one end. This was very clear when
> multi6 recommended shim6 as the direction.
> 
>     Brian
> 
> Bound, Jim wrote:
> > both ends should not need to know about the shim to solve the MH
> > problem. if it the application restarts.
> > 
> > Are we saying in the charter the application does not have 
> to restart?
> > 
> > /jim 
> > 
> > 
> >>-----Original Message-----
> >>From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On 
> >>Behalf Of Brian E Carpenter
> >>Sent: Monday, March 28, 2005 6:20 AM
> >>To: Iljitsch van Beijnum
> >>Cc: Dave Crocker; shim6
> >>Subject: Re: Open question and Critical dependencies
> >>
> >>Iljitsch van Beijnum wrote:
> >>
> >>>On 27-mrt-05, at 20:21, Dave Crocker wrote:
> >>>
> >>>
> >>>>1. What does "This solution should work whether or not the 
> >>
> >>peer site 
> >>
> >>>>supports
> >>>>the shim6 protocol" mean in the draft charter and how can 
> >>
> >>it succeed?
> >>
> >>>
> >>>What Geoff wrote is:
> >>>
> >>>"Solutions for site exit router selection that works when 
> >>
> >>each ISP uses 
> >>
> >>>ingress filtering, i.e. when the chosen site exit needs to 
> >>
> >>be related to 
> >>
> >>>the source address chosen by the host. This solution should 
> >>
> >>work whether 
> >>
> >>>or not the peer site supports the shim6 protocol."
> >>>
> >>>I'm pretty sure "this solution" in this sentence refers to 
> >>
> >>site exit 
> >>
> >>>router selection, which is necessary to get around ingress 
> >>
> >>filtering by 
> >>
> >>>ISPs.
> >>
> >>And possibly also to the address selection mechanisms prior to
> >>exit router selection. Clearly, the double-ended stateful part of
> >>the shim cannot work when only one end knows about it.
> >>
> >>
> >>>A slight rewording would probably be a good idea.
> >>
> >>Yes
> >>
> >>
> >>>>2. Why is shim6 limited to IPv6?  What is it about the 
> >>
> >>problem space 
> >>
> >>>>and/or
> >>>>the solution space that is required to exclude IPv4?
> >>>
> >>>
> >>>There are many answers to this question.
> >>>
> >>>First of all, the multi6 wg was formed because the way 
> >>
> >>multihoming is 
> >>
> >>>done in IPv4 won't scale to the levels presumed necessary 
> >>
> >>in IPv6. So 
> >>
> >>>the problem is assumed to not exist in IPv4 as people can 
> >>
> >>get portable 
> >>
> >>>address space and announce it to multiple ISPs today. (Ok, 
> >>
> >>it doesn't 
> >>
> >>>scale in IPv4 either... But it seems to work for now.)
> >>>
> >>>Then there is the issue that with any multiaddress solution 
> >>
> >>you're going 
> >>
> >>>to burn IPv4 addresses at least twice as fast as by single 
> >>
> >>homing or 
> >>
> >>>PI/BGP multihoming, and we don't even have enough IPv4 
> >>
> >>addresses to give 
> >>
> >>>every person on the planet a single one.
> >>>
> >>>Also, IPv6 has some features that come in handy for solving 
> >>
> >>the problem. 
> >>
> >>>For instance, HBA or CGA which are proposed to secure the address 
> >>>agility, put cryptographic information in the bottom half 
> >>
> >>of the IPv6 
> >>
> >>>address, and there are / have been some ideas about using 
> >>
> >>the flow label.
> >>
> >>Exactly. IPv4 doesn't have the features we need to make 
> shim6 viable.
> >>
> >>
> >>>Last but not least, IPv4 is hampered with lots of ballast 
> >>
> >>in the form of 
> >>
> >>>overzealous firewalls, different kinds of NATs and old 
> >>
> >>implementations 
> >>
> >>>and all kinds of unwise assumptions that something as 
> >>
> >>radical as this 
> >>
> >>>stands a rather small chance of being deployable in the 
> >>
> >>current IPv4 
> >>
> >>>internet. (See ECN and path MTU discovery.) Presumably, 
> >>
> >>these issues 
> >>
> >>>won't be quite as bad in IPv6 because there is less old 
> >>
> >>crap and bad 
> >>
> >>>habits.
> >>>
> >>>
> >>>>3. What happens to shim6 if it must operate through a NAT?
> >>>
> >>>
> >>>Same as anything that must operate through a NAT: that 
> >>
> >>problem is either 
> >>
> >>>solved by the NAT builder or suffered by the NAT user.
> >>>
> >>>NAT in IPv6 is a very bad idea, both because NAT is a very 
> >>
> >>bad idea in 
> >>
> >>>and of itself, but also because NAT in IPv6 immediately 
> >>
> >>kills one of the 
> >>
> >>>main advantages of IPv6 and of course if you're going to 
> >>
> >>use NAT anyway, 
> >>
> >>>why bother adopting IPv6?
> >>
> >>If someone is foolish enough to install IPv6 NAT they will 
> be able to
> >>use that to support old-fashioned NAT-based multihoming. We started
> >>multi6, and we are continuing shim6, precisely as one of 
> the main ways
> >>to make NAT unnecessary. So actually, we simply don't care if shim6
> >>fails through NAT.
> >>
> >>
> >>>>Items 2 & 3 establish critical dependencies on the 
> >>
> >>wide-scale adoption 
> >>
> >>>>of IPv6
> >>>>and the elimination of NATs.
> >>>
> >>>
> >>>Since the former implies the latter (at least right now, 
> >>
> >>but hopefully 
> >>
> >>>also for time to come) and for the short-to-medium term 
> there is no 
> >>>multihoming problem in IPv4, this doesn't pose a problem. 
> >>
> >>(Other than 
> >>
> >>>the possibility that we're wasting our time, which is a risk that 
> >>>everyone will have to weigh for themselves.)
> >>
> >>Well yes. If IPv6 isn't widely adopted, or IPv6 NAT gets deployed,
> >>it will all have been a big waste of time. There's no news there.
> >>
> >>    Brian
> >>
> >>
> >>
> > 
> > 
> 
>