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

[Joe Abley <jabley@isc.org>]

On Friday, Apr 18, 2003, at 07:16 Canada/Eastern, 
Internet-Drafts@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Site Multihoming in IPv6 Working 
> Group of the IETF.
>
> 	Title		: Goals for IPv6 Site-Multihoming Architectures
> 	Author(s)	: J. Abley, B. Black, V. Gill
> 	Filename	: draft-ietf-multi6-multihoming-requirements-05.txt
> 	Pages		: 9
> 	Date		: 2003-4-17
These are Brian's changes, plus Marcelo's changes, plus that extra 
sentence in the security considerations section. Source diff follows.

Index: draft-ietf-multi6-multihoming-requirements.xml
===================================================================
RCS file: 
/home/cvs/doc/ietf/draft-ietf-multi6-multihoming-requirements.xml,v
retrieving revision 1.3
retrieving revision 1.5
diff -u -r1.3 -r1.5
--- draft-ietf-multi6-multihoming-requirements.xml      4 Apr 2003 
00:55:37 -0000       1.3
+++ draft-ietf-multi6-multihoming-requirements.xml      16 Apr 2003 
13:40:47 -0000      1.5
@@ -5,7 +5,7 @@
 <?rfc compact="yes"?>
 <?rfc subcompact="no"?>

-<rfc ipr="full2026" 
docName="draft-ietf-multi6-multihoming-requirements-04">
+<rfc ipr="full2026" 
docName="draft-ietf-multi6-multihoming-requirements-05">
 <front>
   <title abbrev="IPv6 Site-Multihoming Goals">
     Goals for IPv6 Site-Multihoming Architectures
@@ -48,12 +48,7 @@
   <abstract>
     <t>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.</t>
+      which are part of the Internet.</t>

     <t>This document outlines a set of goals for proposed new IPv6
       site-multihoming architectures.</t>
@@ -246,25 +241,25 @@

       <section anchor="routerImpact" title="Impact on Routers">
         <t>The solution may require changes to IPv6 router 
implementations,
-          but these changes must be either minor, or in the form of 
logically
+          but these changes should be either minor, or in the form of 
logically
           separate functions added to existing functions.</t>

         <t>Such changes should not prevent normal single-homed 
operation, and
-          routers implementing these changes must be able to 
interoperate
+          routers implementing these changes should be able to 
interoperate
           fully with hosts and routers not implementing them.</t>
       </section>

       <section anchor="hostImpact" title="Impact on Hosts">
         <t>The solution should not destroy IPv6 connectivity for a 
legacy host
-          implementing RFC 2373 <xref target="refs.RFC2373" />,
+          implementing RFC 3513 <xref target="refs.RFC3513" />,
           RFC 2460 <xref target="refs.RFC2460" />,
           RFC 2553 <xref target="refs.RFC2553" /> and other basic IPv6
-          specifications current in November 2001. That is to say, if 
a host
+          specifications current in April 2003. That is to say, if a 
host
           can work
-          in a single-homed site, it must still be able to work in a
+          in a single-homed site, it should still be able to work in a
           multihomed site, even if it cannot benefit from 
site-multihoming.</t>

-        <t>It would be compatible with this requirement for such a 
host to
+        <t>It would be compatible with this goal for such a host to
           lose connectivity if a site lost connectivity to one transit
           provider, despite the fact that other transit provider
           connections were still operational.</t>
@@ -305,11 +300,11 @@

       <section anchor="multipleSolutions" title="Multiple Solutions">
         <t>There may be more than one approach to multihoming, provided
-          all approaches are orthogonal (e.g. each approach addresses
+          all approaches are orthogonal (i.e. each approach addresses
           a distinct segment or category within the site multihoming
-          problem. Multiple solutions will incur a greater management
+          problem). Multiple solutions will incur a greater management
           overhead, however, and the adopted solutions
-          SHOULD attempt to cover as many multihoming scenarios
+          should attempt to cover as many multihoming scenarios and 
goals
           as possible.</t>
       </section>

@@ -319,6 +314,10 @@
   <section anchor="security" title="Security Considerations">
     <t>A multihomed site should not be more vulnerable to
       security breaches than a traditionally IPv4-multihomed site.</t>
+
+    <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>
   </section>
 </middle>

@@ -368,18 +367,18 @@
       <seriesInfo name="RFC" value="1918" />
     </reference>

-    <reference anchor="refs.RFC2373">
+    <reference anchor="refs.RFC3513">
       <front>
-        <title>IP Version 6 Addressing Architecture</title>
+        <title>Internet Protocol Version 6 (IPv6) Addressing 
Architecture</title>
         <author initials="R." surname="Hinden">
           <organization>Nokia</organization>
         </author>
         <author initials="S." surname="Deering">
-          <organization>Cisco</organization>
+          <organization>Cisco Systems</organization>
         </author>
-        <date month="July" year="1998" />
+        <date month="April" year="2003" />
       </front>
-      <seriesInfo name="RFC" value="2373" />
+      <seriesInfo name="RFC" value="3513" />
     </reference>

     <reference anchor="refs.RFC2374">