Re: 6MAN WG Last Call - draft-ietf-6man-multi-homed-host-03.txt

"Fred Baker (fred)" <fred@cisco.com> Wed, 03 February 2016 23:06 UTC

Return-Path: <fred@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBCA1B3637 for <ipv6@ietfa.amsl.com>; Wed, 3 Feb 2016 15:06:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.502
X-Spam-Level:
X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQGzln6htYqp for <ipv6@ietfa.amsl.com>; Wed, 3 Feb 2016 15:06:54 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9E81B3636 for <ipv6@ietf.org>; Wed, 3 Feb 2016 15:06:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3651; q=dns/txt; s=iport; t=1454540814; x=1455750414; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eHEOiltloeLEXa0JvsjdypmlTBr9OgmjdeA2tuKEicc=; b=BmCY7vFSO51rK5oaR1dSxgbBMHDf7WbBycMk2WK2r7n8P5qaklfWrB8r r0UQhOFQkIY1hpFrnndwECuUXk0VAErhr3U850yByKNlHfL9oPghOOYeG g60E7O0kigUBVcXILMUjatZen6Bzhf+tssz8ap2jEzd74fd50nHyXbl/j s=;
X-Files: signature.asc : 833
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C7AgDWh7JW/5tdJa1egzqBPwaIVbEaDoFmhg0CgUE4FAEBAQEBAQGBCoRBAQEBAwEjVgULAgEIGCoCAiERJQIEDgUOh3gDCgixZIpEDYQ/AQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiHfwiCQoI3gVWDJiuBDwWWcQGCe4FjhnuBc4Fbh2iFLoVwgQ+HQAEeAUODZGqIMj18AQEB
X-IronPort-AV: E=Sophos;i="5.22,392,1449532800"; d="asc'?scan'208";a="67750183"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Feb 2016 23:06:41 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u13N6fOt016367 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Feb 2016 23:06:41 GMT
Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 3 Feb 2016 17:06:41 -0600
Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Wed, 3 Feb 2016 17:06:41 -0600
From: "Fred Baker (fred)" <fred@cisco.com>
To: Bob Hinden <bob.hinden@gmail.com>
Subject: Re: 6MAN WG Last Call - draft-ietf-6man-multi-homed-host-03.txt
Thread-Topic: 6MAN WG Last Call - draft-ietf-6man-multi-homed-host-03.txt
Thread-Index: AQHRXtMz+oGF3eRmbkuVf5Gu7fEtVp8bVgKA
Date: Wed, 03 Feb 2016 23:06:40 +0000
Message-ID: <42523014-C715-428A-9549-B16FA3AC470B@cisco.com>
References: <2052A806-4D40-4A17-9892-90E39B67C65C@gmail.com> <CA38FB16-7B79-4708-9EB1-3D761C5871E2@gmail.com>
In-Reply-To: <CA38FB16-7B79-4708-9EB1-3D761C5871E2@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3112)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.248.216]
Content-Type: multipart/signed; boundary="Apple-Mail=_0E337A64-7B6E-40AB-B61E-F04D4BC1C46E"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/SH1-dzSt7TUDFxUKhots5FDICzU>
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2016 23:06:56 -0000

> On Feb 3, 2016, at 2:35 PM, Bob Hinden <bob.hinden@gmail.com> wrote:
> 
> Brian, Fred,
> 
> I started the w.g. last call.  I read the draft again, looks fine overall.  I think it would helpful if it was clearer as to what the update is for RFC4861.  Having done some updates a few times recently, it better to be very clear what the change is.
> 
> I like the “Bob” and “Alice” host names.  Maybe it should be “Ole” and “Bob” :-)

The text in question is, at least,

   Note that, apart from ensuring that a message with a given source
   address is given to a first-hop router that appears to know about the
   prefix in question, this specification is consistent with [RFC4861].
   Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC
   4861 will need to extend their implementations accordingly.  This
   specification is fully consistent with [RFC6724] and implementers
   will need to add support for its Rule 5.5.  Hosts that do not support
   these features may fail to communicate in the presence of filters as
   described above.

Section 5.2 basically says that on-link prefixes should result in local traffic ("the next hop address is the destination address") and off-link prefixes operate as described in 6.3.6. Based on that, I think this draft is primarily proposing an inserted step in 6.3.6:

0) IF the source address is a member of a prefix being advertised to the host in an RA, the set of routers being considered as possible next hops is limited to the set of routers advertising the prefix, as opposed to "all neighboring routers".

(which there may be a better way of wording)

Regarding 6.2.3 and 6.2.4, I need to defer to my co-author; I'm not sure what he had in mind. It may have to do with the RIO/PIO/DIO considerations in the draft.

In Section 8, there is a limitation on the set of routers a router might redirect to: it MUST be among the set of routers advertising the indicated prefix in its RA, or the redirecting router must in some other way know that it has the information necessary for SADR routing.

If putting words directly into draft-ietf-6man-multi-homed-host would help you with a 4861bis, we can do that.