Re: administrivia (on avoiding injury) (fwd)

[Brian E Carpenter <brian@hursley.ibm.com>]

Greg Maxwell wrote:
> 
> ---------- Forwarded message ----------
> Date: Tue, 10 Apr 2001 22:23:30 -0400
>  From: Daniel Senie <dts@senie.com>
> To: Greg Maxwell <gmaxwell@martin.fl.us>
> Subject: Re: administrivia (on avoiding injury)
> 
> Greg Maxwell wrote:
> >
> > On Tue, 10 Apr 2001, Daniel Senie wrote:
> >
> > > Greg, could you reread your last post, reparse the sentences and see if
> > > you can phrase it in a way that parses? It's REALLY unclear what you're
> > > trying to say.
> >
> > I'm very sorry. I've been working too many 16 hour days, doing too
> > many concurrent tasks, and being constantly interrupted. :(
> >
> > Thank you for politely pointing this out to me.
> 
> :-)
> 
> I know how it gets...
> 
> >
> > The discussed language is the requirement that any proposal be compatible
> > with 2460 hosts achieving 'degraded multihoming' (DM means: no requirement
> > that TCP sessions survive a link failure, but the connection can be
> > reestablished right away).
> 
> I've expressed the opinion that we're there already today...
> applications wind up having to be able to do this, though it's VERY
> painful at times (like when the connection was an interactive terminal
> session, and you're in the middle of typing something).

Yes... my whole point is that inserting the new multihoming solution
must not break where we are today.

> 
> >
> > As far as I can tell, that sort of 'degraded multihoming' is acceptable to
> > the more vocal here for compatiblity with existing applications. That's my
> > opinion as well, but I'm not so sure that we need to leave the entire end
> > node unaltered and still achieve degraded multihoming on that end node.

I think we do need to do so, and the reason is totally pragmatic:
IPv6 products are going to roll before multi6 has finished its job.

> 
> I think it is generally acceptable IF there's some way to get
> reconnected to the same end node. Seems to me this still requires we
> have some way to talk about end nodes other than by use of IP addresses
> (v4 or v6).

Yes, and today that is DNS or nothing unfortunately. Longer term something
like HIP may be your friend.

> 
> >
> > Alternately,
> >
> > Would requiring the OS be modifyed be acceptable to provide degraded
> > multihoming, as long the changes were not substantial and caused no
> > visable API change and non-modifyed systems would be stuck single homed
> > without proxys/NATs?)
> 
> No.

I can't see any reason why they can't be stuck with the "let's try a bunch
of different addresses until it works" solution too.

> 
> >
> > I think the point is worth of consideration as end-to-end multihoming
> > might require provisions for NAT in routers if no host changes can be
> > required for degraded multihoming (and thus require discussions about the
> > accepeptibility of such methods, if they are not acceptable it might
> > fully exclude end-to-end multihoming).
> 
> There's a MAJOR problem here... When you introduce the requirement for a
> NAT in the stack, you're expressing a willingness to limit protocol
> choices to a very few, limit the ability to offer services, and thus
> severely limit what applications can work. As a transition strategy, NAT
> can be acceptable. As a permanent feature, we have to consider that VERY
> carefully. Many are trying to get people onto IPv6 to get them AWAY from
> NAT. If it's to be a permanent fixture, application protocol design will
> be severely affected.

Since requiring NAT for IPv6 would remove the major advantage of IPv6,
this would really be an own-foot-shooting choice.

> 
> >
> > If you feel that I sufficently clarified the post in question, and that
> > this clarification would be useful to others, you have my consent to
> > forward this onto the list.
> 
> I think it did. You may, at your discretion, also forward my comments if
> desired.
> 
> --
> -----------------------------------------------------------------
> Daniel Senie                                        dts@senie.com
> Amaranth Networks Inc.                    http://www.amaranth.com

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org