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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 03 November 2015 02:35 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 74A071ACE54 for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2015 18:35:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 c_Ni1G-Oh4Ui for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2015 18:35:08 -0800 (PST)
Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (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 7DBF11ACE53 for <v6ops@ietf.org>; Mon, 2 Nov 2015 18:35:08 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id tA32ZAwf017389; Mon, 2 Nov 2015 18:35:10 -0800
Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA32Z6wh017370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 2 Nov 2015 18:35:06 -0800
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-112.sw.nos.boeing.com ([169.254.12.102]) with mapi id 14.03.0235.001; Mon, 2 Nov 2015 18:35:03 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Lorenzo Colitti <lorenzo@google.com>
Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
Thread-Index: AQHRFS2IJ4h76jRqCkuPztS49pNk7Z6JZjuggACchgD//3qXcIAABmrAgACKz4D//3oXYIAAB83AgACJrgD//3rpYA==
Date: Tue, 3 Nov 2015 02:35:03 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F395B5@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> <2134F8430051B64F815C691A62D9831832F3957A@XCH-BLV-504.nw.nos.boeing.com> <CAKD1Yr0p2mD2v3XuCTMMXLKKWiE3P1+8fKc+NcmFzgi5s_u_RQ@mail.gmail.com>
In-Reply-To: <CAKD1Yr0p2mD2v3XuCTMMXLKKWiE3P1+8fKc+NcmFzgi5s_u_RQ@mail.gmail.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: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832F395B5XCHBLV504nwnosb_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/KHplztfhFjjYVSiPKg9qDV97yUc>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] 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: Tue, 03 Nov 2015 02:35:12 -0000

Hi Lorenzo,

The client assigns the addresses to interface “A” instead of the loopback interface
because otherwise it would have no way of knowing that packets with a source
address taken from the prefix need to go out interface “A”. That is because the
prefix itself is assigned to the loopback interface so addresses need to be
assigned to interface “A” to disassociate them from the loopback interface.

Fred

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Monday, November 02, 2015 6:28 PM
To: Templin, Fred L
Cc: Brian E Carpenter; v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion

On Tue, Nov 3, 2015 at 11:19 AM, Templin, Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote:
Bumping up again, here is a valid and useful instance of multiaddressing:

1) Client gets a /64 prefix delegation from a DHCPv6 server over interface "A"
2) Client assigns the /64 to a loopback interface
3) Client assigns as many addresses from the /64 as it likes to
    interface "A" (could be millions or more)
4) Client is a pure host (IP forwarding turned off)
5) No DAD needed on any interface

Why is the client assigning the addresses to interface A instead of loopback? There is no need for the client to respond to ND to those addresses.