Re: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt

[Joe Abley <jabley@isc.org>]

On Wednesday, Apr 16, 2003, at 03:48 Canada/Eastern, Brian E Carpenter 
wrote:

> I think this is about ready to ship. Just a few points, essentially
> editorial except for the very last one.
>
> > Abstract
> >
> > Site-multihoming, i.e. connecting to more than one IP service
> > provider, is an essential component of service for many sites which
> > are part of the Internet.  Existing IPv4 site-multihoming practices
> > provide a set of capabilities that it would ideally be accommodated
> > by the adopted site-multihoming architecture in IPv6, and a set of
> > limitations that must be overcome, relating in particular to
> > scalability.
> The second sentence is very hard to understand, contains at least one
> grammatical error, and distracts from the main message. I would simply
> delete it.
Very happy to do so, and I apologise for my hideous wordcrime.

> ...
> > 3.2.2 Impact on Routers
> >
> >    The solution may require changes to IPv6 router implementations, 
> > but
> >    these changes must be either minor, or in the form of logically
> s/must/should/
fixed

> >    separate functions added to existing functions.
> >
> >    Such changes should not prevent normal single-homed operation, and
> >    routers implementing these changes must be able to interoperate 
> > fully
> s/must/should/
fixed

> >    with hosts and routers not implementing them.
> >
> > 3.2.3 Impact on Hosts
> >
> >    The solution should not destroy IPv6 connectivity for a legacy host
> >    implementing RFC 2373 [3], RFC 2460 [5], RFC 2553 [6] and other 
> > basic
> s/2373/3513/
fixed

> >    IPv6 specifications current in November 2001. That is to say, if a
> s/November 2001/April 2003/
fixed already

> >    host can work in a single-homed site, it must still be able to work
> s/must/should/
fixed

> >    in a multihomed site, even if it cannot benefit from
> >    site-multihoming.
> >
> >    It would be compatible with this requirement for such a host to 
> > lose
> s/requirement/goal/
fixed

> >    connectivity if a site lost connectivity to one transit provider,
> >    despite the fact that other transit provider connections were still
> >    operational.
> ...
>
> > 3.2.7 Multiple Solutions
> >
> >    There may be more than one approach to multihoming, provided all
> >    approaches are orthogonal (e.g. each approach addresses a distinct
> s/(e.g./i.e./
Arrgh, fixed.

> >    segment or category within the site multihoming problem. Multiple
> >    solutions will incur a greater management overhead, however, and 
> > the
> >    adopted solutions SHOULD attempt to cover as many multihoming
> s/SHOULD/should/
fixed


> >    scenarios as possible.
> s/scenarios/scenarios and goals/
good idea

> > 4. Security Considerations
> >
> >    A multihomed site should not be more vulnerable to security 
> > breaches
> >    than a traditionally IPv4-multihomed site.
> Should we add "or a single-homed IPv6 site"?
Is that reasonable? Or does the addition of an entry-point to a 
single-homed site make it inherently more vulnerable, in some small way?

In response to some other private feedback, I also added the following 
sentence to the security section:

    <t>Any changes to routing practices made to accommodate multihomed
      sites should not cause non-multihomed sites to become more
      vulnerable to security breaches.</t>

Comments on that would be appreciated.

Thanks, Brian.


Joe