IETF Logo Mail Archive

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

Gert Doering <gert@space.net> Fri, 13 November 2015 15:43 UTC

Return-Path: <gert@Space.Net>
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 A9F1A1ACE66 for <v6ops@ietfa.amsl.com>; Fri, 13 Nov 2015 07:43:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level:
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 4ZA7zh_7oEtd for <v6ops@ietfa.amsl.com>; Fri, 13 Nov 2015 07:43:22 -0800 (PST)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 D8C5A1ACE5C for <v6ops@ietf.org>; Fri, 13 Nov 2015 07:43:21 -0800 (PST)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id D032162D3E for <v6ops@ietf.org>; Fri, 13 Nov 2015 16:43:19 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 9BAF360788 for <v6ops@ietf.org>; Fri, 13 Nov 2015 16:43:19 +0100 (CET)
Received: (qmail 6184 invoked by uid 1007); 13 Nov 2015 16:43:19 +0100
Date: Fri, 13 Nov 2015 16:43:19 +0100
From: Gert Doering <gert@space.net>
To: "Hemant Singh (shemant)" <shemant@cisco.com>
Message-ID: <20151113154319.GX89490@Space.Net>
References: <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <CAHDzDLBG8xZxUFsAuN-7WuruZcULF1QAS_ch=gD5rGQMZfskow@mail.gmail.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <CAJE_bqd-1x5EJ=rkebiBFdNds6so5+iNGftiUf+MUu9P1up1bA@mail.gmail.com> <CAKD1Yr1X8UzQ58FeG6PYG9L1MyibV0J-JpcS2hxwzCdV=HizXg@mail.gmail.com> <ad0e90cf5f74407fa5338a7b6130bd1a@XCH-RTP-005.cisco.com> <5645DE07.3050605@gmail.com> <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> <20151113140830.GT89490@Space.Net> <e87d1d895a3745a5a0162874a9b341e4@XCH-RTP-005.cisco.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="IWOW6f13lWWiH/hK"
Content-Disposition: inline
In-Reply-To: <e87d1d895a3745a5a0162874a9b341e4@XCH-RTP-005.cisco.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/MilBg6GSz2Sn5nYlAMN0-VbZVbs>
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: Fri, 13 Nov 2015 15:43:23 -0000

Hi,

On Fri, Nov 13, 2015 at 03:34:11PM +0000, Hemant Singh (shemant) wrote:
> >Otherwise, there is no way to ensure uniqueness on non-directly-connected interfaces - think "loopback on a router on the other side of the planet".
> 
> The router on the other side of the planet has a tunnel to the upstream router and thus the two routers are in the same routed domain.  In the same routed domain, an interface on a router responds to ND NS messages for address resolution.  Thus the interface has to also perform DAD for its IPv6 address(es).

Well, if you take an address that belongs to a connected /64 and glue that
to your loopback interface, what you say is true - there will be ND NS
queries for that address, and you better should do DAD.

In the normal case for loopback interfaces, these intentionally are *not*
numbered out of connected networks, but coming out of separately assigned
number space (like, DHCPv6PD, or manually configured).  Why would anyone
send a ND NS for such an address in the first place?  Nobody knows that
it "could be on a link here".

And no, the router on the other side of the planet has no "tunnel" to 
your routing domain.  It's just a router having a loopack address, 
chosen to show that your concerns about loopback address DAD are a bit
unrealistic.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

v2.23.0 | Report a Bug | By Email