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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Mon, 16 November 2015 16:42 UTC

Return-Path: <Fred.L.Templin@boeing.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 59E0C1A6F61 for <v6ops@ietfa.amsl.com>; Mon, 16 Nov 2015 08:42:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.887
X-Spam-Level:
X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=unavailable
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 6_ZsDJxHCIAD for <v6ops@ietfa.amsl.com>; Mon, 16 Nov 2015 08:41:48 -0800 (PST)
Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA28D1A6F58 for <v6ops@ietf.org>; Mon, 16 Nov 2015 08:41:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id tAGGfgsx015331; Mon, 16 Nov 2015 10:41:42 -0600
Received: from XCH-PHX-210.sw.nos.boeing.com (xch-phx-210.sw.nos.boeing.com [130.247.25.65]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tAGGfWlX015261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 16 Nov 2015 10:41:33 -0600
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.189]) by XCH-PHX-210.sw.nos.boeing.com ([169.254.10.114]) with mapi id 14.03.0235.001; Mon, 16 Nov 2015 08:41:30 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "Hemant Singh (shemant)" <shemant@cisco.com>, "Mukom Akong T." <mukom.tamon@gmail.com>
Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
Thread-Index: AQHRFogofPNeczqv2U2vJopouDkBSJ6LeFYwgAa8AYCAAeLTIIAJg1aAgAFM4PA=
Date: Mon, 16 Nov 2015 16:41:30 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F4CE72@XCH-BLV-504.nw.nos.boeing.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> <831e60e2122547bc8bdf167e76f664c9@XCH-RTP-005.cisco.com>
In-Reply-To: <831e60e2122547bc8bdf167e76f664c9@XCH-RTP-005.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/4kHxL03vUx6OEKyPccAE3Zz-Upg>
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: Mon, 16 Nov 2015 16:42:00 -0000

Hi Hemant,

> -----Original Message-----
> From: Hemant Singh (shemant) [mailto:shemant@cisco.com]
> Sent: Sunday, November 15, 2015 4:26 AM
> To: Templin, Fred L; Mukom Akong T.
> Cc: v6ops@ietf.org
> Subject: RE: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
> 
> Fred,
> 
> Sorry for the delay.  I am catching up with the original thread.   Please see below.

OK.

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

Correct; that is exactly why I said "MUST NOT".

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

This is starting to diverge from the case I originally intended this discussion to
examine. The case I am interested in is as follows:

- Node N receives a /64 prefix delegation for prefix P over interface eth0.
- N assigns P to the lo interface as a /64 route. This is done to black-hole
   unused portions of P.
- N configures address A from prefix P, and assigns it to eth0.
- N need not perform DAD for A over eth0, because the delegating router
   has made sure that the routing system will route all packets with a
   destination address from P to node N, and not to any other node.

In this way, N can function as an ordinary host according to the strong end
system model even though it acted as a "requesting router" in procuring a
prefix from the delegating router. No other node X on the same link as
N can therefore configure an address from P and have the routing system
return packets to X. In fact, any node X that configures an address from P
can be considered an "attacker", and the use or non-use of DAD has no
way of preventing that. In fact, the use of DAD could give X a clue as to
which addresses from P are ripe for attacking. So, it is in fact better to
NOT do DAD.

Thanks - Fred
fred.l.templin@boeing.com

> Hemant
> 
> 
>