IETF Logo Mail Archive

Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability

"Templin, Fred L" <Fred.L.Templin@boeing.com> Mon, 27 July 2015 15:13 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 DD8B71B2E6A for <v6ops@ietfa.amsl.com>; Mon, 27 Jul 2015 08:13:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kC-gZe80njKY for <v6ops@ietfa.amsl.com>; Mon, 27 Jul 2015 08:13:13 -0700 (PDT)
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 792CA1B2E65 for <v6ops@ietf.org>; Mon, 27 Jul 2015 08:13:13 -0700 (PDT)
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 t6RFDE9i030512; Mon, 27 Jul 2015 08:13:14 -0700
Received: from XCH-PHX-211.sw.nos.boeing.com (xch-phx-211.sw.nos.boeing.com [130.247.25.140]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t6RFD9b2030430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 27 Jul 2015 08:13:09 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.231]) by XCH-PHX-211.sw.nos.boeing.com ([169.254.11.215]) with mapi id 14.03.0235.001; Mon, 27 Jul 2015 08:13:07 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability
Thread-Index: AdDIdDZdq0uthLAMSeG10ygJ/vZ6/gAButyA
Date: Mon, 27 Jul 2015 15:13:06 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832ECECA5@XCH-BLV-504.nw.nos.boeing.com>
References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <D1D96418.5E52E%wesley.george@twcable.com> <CAO42Z2x5umGi0ra977KpOWwYJ=A0JHDoW8C1g_+vO-zyjpggKg@mail.gmail.com> <D1DB99FA.5E7B0%wesley.george@twcable.com>
In-Reply-To: <D1DB99FA.5E7B0%wesley.george@twcable.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/w2fsjewWyv8tePsQ9GIwwsxMSQA>
Cc: "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" <draft-colitti-v6ops-host-addr-availability@tools.ietf.org>
Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability
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, 27 Jul 2015 15:13:15 -0000

Hi - for a long time now, AERO has been advocating DHCPv6-PD for assigning
a /64 or shorter to a node that can act as either a host or a router. If a router,
the node assigns (portions of) the delegated prefix to one or more downstream
attached links. If a host, the node assigns (portions of) the delegated prefix to a
virtual interface and configures as many addresses from the prefix as it likes on
the virtual interface. The node can then enable host applications that use the
assigned addresses according to the weak end system model. I suppose it is
also possible for the node to act as both a host and a router, if such would
be required according to the use case.

I also agree with what I think I heard Lorenzo saying at the mike, which is that
assigning a /64 or shorter to each node is scalable since even a /32 can support
up to 4B such nodes. That is also consistent with what AERO expects.

Here is a pointer to the AERO draft:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

Thanks in advance for any comments.

Fred
fred.l.templin@boeing.com

v2.23.0 | Report a Bug | By Email