Re: administrivia (on avoiding injury) (fwd)

[Greg Maxwell <gmaxwell@martin.fl.us>]

On Wed, 11 Apr 2001, Brian E Carpenter wrote:

> > > 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 agree.
 
> > >
> > > 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.


Yes, but how would this work without:
 1) Changing hosts to understand they should try multiple SOURCE addresses.
	or
 2) Changing the network infrastructure and addressing so that it doesn't
    matter what SOURCE it uses?
 
> > > 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.

I would never suggest NAT be a requirement for IPv6. Eww. I'd rather
require that people who use nat be shot. :)

However, I can't figure out how to make my preferred form of trasport
level multhoming work with zero host changes without some kind of lite-nat
for these legacy hosts (the nat would map the 'wrong' source address used
by a non-multihome-aware IPv6 host to an alternate prefix during link
failure, but would stay out of the way for multihome-aware hosts).