IETF Logo Mail Archive

Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

"Hemant Singh (shemant)" <shemant@cisco.com> Sun, 15 November 2015 12:25 UTC

Return-Path: <shemant@cisco.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7971B33BA for <v6ops@ietfa.amsl.com>; Sun, 15 Nov 2015 04:25:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.186
X-Spam-Level:
X-Spam-Status: No, score=-13.186 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 nsxESUSDn2_A for <v6ops@ietfa.amsl.com>; Sun, 15 Nov 2015 04:25:39 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17A91B33B9 for <v6ops@ietf.org>; Sun, 15 Nov 2015 04:25:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1916; q=dns/txt; s=iport; t=1447590338; x=1448799938; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+Xgkj+SHlcCLsk3B+Rtu+qBSmfo5wFEqB32zXcZgc6Q=; b=KoFzbVCjdLmhz8vjEL2gUKSlvEuY6N/JjYk61vhw6oVbFjDJ2DRVD59m Oo3pkG8VwKHE7P9BqAJwlDgntu+VvfwrewR0O7Hs1CKxKmfZvDZ1VFNGh 8IPIkkluSId/c6MsVrnE9Ij8X0Q7rzKIdda2h+pYAiEkjxQb4G/9IUiq0 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D0AQACeUhW/4cNJK1egzuBQga+SQENgWSGEAKBIjgUAQEBAQEBAYEKhDQBAQEEOj8QAgEIEQQBAR8JBzIUCQgCBAENBQiIJrdVAQEBAQEBAQEBAQEBAQEBAQEBAQEBGItSiTkBBJZIAY0fgWKEQJYpAR8BAUKEBHKERIEHAQEB
X-IronPort-AV: E=Sophos;i="5.20,297,1444694400"; d="scan'208";a="207141038"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP; 15 Nov 2015 12:25:36 +0000
Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tAFCPaFg003262 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 15 Nov 2015 12:25:36 GMT
Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 15 Nov 2015 07:25:35 -0500
Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Sun, 15 Nov 2015 07:25:35 -0500
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, "Mukom Akong T." <mukom.tamon@gmail.com>
Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAIkUDw
Date: Sun, 15 Nov 2015 12:25:35 +0000
Message-ID: <831e60e2122547bc8bdf167e76f664c9@XCH-RTP-005.cisco.com>
References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <CAKD1Yr15C-uoxUw0kgWO-d=LmUK8qWGLS7vt+22W+k8xXtDY+g@mail.gmail.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <CAHDzDLBG8xZxUFsAuN-7WuruZcULF1QAS_ch=gD5rGQMZfskow@mail.gmail.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.233.244]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/1Z5R7mtyWpvEAEtiKKB8KXfPWwU>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Nov 2015 12:25:40 -0000

Fred,

Sorry for the delay.  I am catching up with the original thread.   Please see below.

>From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L
>Sent: Monday, November 09, 2015 3:00 PM
>To: Mukom Akong T.
>Cc: v6ops@ietf.org
>Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]


>>'N' sends a DHCPv6 PD Solicit over the WAN interface
>>and receives a prefix delegation 'P'. 'N' can now assign prefix 'P' to either the
>>loopback interface or the LAN interface, but MUST NOT assign 'P' to the WAN
>>interface.

>This is correct, since this WAN interface would have already gotten legitimate non-link-local addresses by other means.

There is another reason.  The prefix delegation (PD) RFC in RFC3633 says

[the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router.]

The reason RFC3633 has such a restriction is because if it were possible, then the WAN IPv6 global address is on-link to the northbound SP router.   The delegated prefix in P is supposed to be not on-link on the WAN.   Thus if a loopback (lo) interface is configured with an IPv6 address from prefix P, the  IPv6 address is not on-link and thus the lo interface does not initiate DAD for the address.

However, if an address is configured on the lo interface manually and the address is not using an address from a DHCPv6 PD, what transpires?   The intent of the admin is to configure an address which is not on-link to the directly connected network.   The only other case is if the directly connected network includes a node who manually assigned its IPv6 address (or is broken) and the address happens to match the address on the lo interface - now DAD is needed.   

Hemant

v2.23.0 | Report a Bug | By Email