IETF Logo Mail Archive

RE: Liaison from BBF

"Manfredi, Albert E" <albert.e.manfredi@boeing.com> Mon, 09 November 2009 17:09 UTC

Return-Path: <albert.e.manfredi@boeing.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D52C28C168 for <ipv6@core3.amsl.com>; Mon, 9 Nov 2009 09:09:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuqYirUG+MIw for <ipv6@core3.amsl.com>; Mon, 9 Nov 2009 09:09:34 -0800 (PST)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 77F2D3A67B2 for <ipv6@ietf.org>; Mon, 9 Nov 2009 09:09:34 -0800 (PST)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nA9H9rte018670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2009 11:09:54 -0600 (CST)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nA9H9rP4012112; Mon, 9 Nov 2009 11:09:53 -0600 (CST)
Received: from XCH-MWHT-03.mw.nos.boeing.com (xch-mwht-03.mw.nos.boeing.com [134.57.119.161]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nA9H9r9t012109 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 9 Nov 2009 11:09:53 -0600 (CST)
Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.118.180]) by XCH-MWHT-03.mw.nos.boeing.com ([134.57.119.161]) with mapi; Mon, 9 Nov 2009 11:09:53 -0600
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Date: Mon, 09 Nov 2009 11:09:51 -0600
Subject: RE: Liaison from BBF
Thread-Topic: Liaison from BBF
Thread-Index: AcphW6XlYiZ9jMeZSzSiHHvX2u8UrgAAbw7w
Message-ID: <B0147C3DD45E42478038FC347CCB65FE16EDA1DD@XCH-MW-08V.mw.nos.boeing.com>
References: <60C093A41B5E45409A19D42CF7786DFD4DEDE9BC10@EUSAACMS0703.eamcs.e ricsson.se><200911091500.nA9F0PSm002116@cichlid.raleigh.ibm.com> <alpine.DEB.1.10.0911091623150.22728@uplift.swm.pp.se><B0147C3DD45E42478038 FC347CCB65FE16EDA143@XCH-MW-08V.mw.nos.boeing.com> <alpine.DEB.1.10.0911091739460.22728@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.1.10.0911091739460.22728@uplift.swm.pp.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2009 17:09:35 -0000

> -----Original Message-----
> From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] 

Here is the crux of my not understanding the problem:

> And no, I haven't seen any residential rollout 
> plan where 
> IPv6 would be provisioned in the static way you describe, 
> DHCPv6-PD seems 
> to be the most popular method seen in discussion.

Does not the ISP control, own, and distribute the "residential gateway"? If yes, then the DHCP conducted within the broadcast domain part of the network, i.e. the "last mile" part *outside* customer premises, should be able to ensure uniqueness of the EUI and consequently the IPv6 address of each residential gateway WAN side, no? So that DHCP or whatever method of assigning IPv6 WAN side addresses should be safe.

For that matter, one could use the client identifier option, and the ISP could hard-code the client ID in each of their residential gateways, before distributing these to customer premises.

Why would ISP not own and control the residential gateway?

We received our ADSL "modem" in the mail, from Verizon. It is a NAT, and the WAN side is under their control entirely. Is this not standard practice among ISPs?

Bert

v2.23.0 | Report a Bug | By Email