RE: Liaison from BBF

"Manfredi, Albert E" <albert.e.manfredi@boeing.com> Mon, 09 November 2009 22:18 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 4B61D3A6991 for <ipv6@core3.amsl.com>; Mon, 9 Nov 2009 14:18:27 -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 3iuAbXtvNkkE for <ipv6@core3.amsl.com>; Mon, 9 Nov 2009 14:18:26 -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 394393A68C1 for <ipv6@ietf.org>; Mon, 9 Nov 2009 14:18:26 -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 nA9MInIY003310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2009 16:18:49 -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 nA9MIn2k012308; Mon, 9 Nov 2009 16:18:49 -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 nA9MInoV012302 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 9 Nov 2009 16:18:49 -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 16:18:49 -0600
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: "Wes Beebee (wbeebee)" <wbeebee@cisco.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Date: Mon, 09 Nov 2009 16:18:46 -0600
Subject: RE: Liaison from BBF
Thread-Topic: Liaison from BBF
Thread-Index: AcphY8coU7aPyIcHSiOYCtrn5ondFQAIY5agAAB+qzA=
Message-ID: <B0147C3DD45E42478038FC347CCB65FE16EDA3C6@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><B0147C3DD45E42478038FC347CCB65F E16EDA143@XCH-MW-08V.mw.nos.boeing.com><alpine.DEB.1.10.0911091739460.22728 @uplift.swm.pp.se><B0147C3DD45E42478038FC347CCB65FE16EDA1DD@XCH-MW-08V.mw.n os.boeing.com><alpine.DEB.1.10.0911091833170.22728@uplift.swm.pp.se> <BB56240F3A190F469C52A57138047A03037B0B9C@xmb-rtp-211.amer.cisco.com>
In-Reply-To: <BB56240F3A190F469C52A57138047A03037B0B9C@xmb-rtp-211.amer.cisco.com>
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
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 22:18:27 -0000

That seems a little more complicated than it needs to be, but assuming that PCs are designed by people who know about uniqueness of MAC addresses, that solution should also work with IPv6 too, no?

Another possibility is that ISPs need to allow DAD to be run by residential gateways on the WAN side. Sort of similar to what you had to do for IP over ATM, the "broadband network gateway" (router port where the broadcast Ethernet domain comes together upstream of the residential gateways) needs to reflect back downstream all NS and NA messages from the WAN side of residential gateways.

Of course, this assumes that these off-the-shelf residential gateways know enough to perform DAD. But such a solution would only make the ISP's "broadband network gateway" unique. The residential gateways would just do NS and NA as if connected to a regular Ethernet.

(Or maybe all of this has been said but I didn't get it.)

Bert 

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Wes Beebee (wbeebee)
Sent: Monday, November 09, 2009 4:50 PM
To: Mikael Abrahamsson; ipv6@ietf.org
Subject: RE: Liaison from BBF

One common way of setting up a residential gateway is to first set up a
PC connected to the ISP, let it get an IPv4 address through DHCPv4, tell
the ISP about it and get the MAC address and DHCPv4 lease recorded (and
reserved) in the ISP servers (to get it online).  Then, the customer
hangs up the phone from the ISP and transfers the connection to the PC
from behind the modem to behind the residential gateway (on the LAN
side).  The WAN side of the residential gateway is then connected to the
modem of the ISP.  However, since the residential gateway no longer has
a MAC address that matches the lease recorded in the ISP DHCPv4 server,
the user simply clones the MAC address of the PC onto the WAN side of
the CPE Router.  The residential gateway completes DHCPv4, and
everything works fine.  The MAC address of the PC and the MAC address of
the WAN side interface of the residential gateway are the same.
However, this is not a problem as long as the residential gateway either
routes traffic or is a NAT box.  If the residential gateway is a bridge,
this causes all sorts of problems (including the problems listed in the
BBF liason).  However, if it were a bridge, then you wouldn't have to
clone the MAC address in the first place!

- Wes

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
Mikael Abrahamsson
Sent: Monday, November 09, 2009 12:40 PM
To: ipv6@ietf.org
Subject: RE: Liaison from BBF

On Mon, 9 Nov 2009, Manfredi, Albert E wrote:

> Does not the ISP control, own, and distribute the "residential
gateway"?

Not in my market anyway (some have this service of course, but it's
definitely not mandatory).

> Why would ISP not own and control the residential gateway?

Because it's cheaper to have the customer walk into their electronics
store and buy any CPE they fancy, than to have the ISP handle it. It
also gives customers more choice. In some markets, people like to have
the choice between ISP provided CPE and one they run themselves.

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

As far as I can discern, it's standard in the US but not in the rest of
the world. Generally, the more competition in the market, the less
likely it is that the ISP provides the end user CPE. If customers switch
ISPs every year or so, they want to be able to re-use their CPE.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------