IETF Logo Mail Archive

Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt

Ted Lemon <Ted.Lemon@nominum.com> Tue, 25 September 2012 14:18 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55F221F8557 for <dhcwg@ietfa.amsl.com>; Tue, 25 Sep 2012 07:18:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.381
X-Spam-Level:
X-Spam-Status: No, score=-106.381 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvJhIq0KZQYC for <dhcwg@ietfa.amsl.com>; Tue, 25 Sep 2012 07:17:59 -0700 (PDT)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4A12F21F8570 for <dhcwg@ietf.org>; Tue, 25 Sep 2012 07:17:59 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUGG9Fle2iO0VHtYj299b0XL3RvOqnOnt@postini.com; Tue, 25 Sep 2012 07:17:59 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7B0671B8301 for <dhcwg@ietf.org>; Tue, 25 Sep 2012 07:17:58 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6E75219005C; Tue, 25 Sep 2012 07:17:58 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 25 Sep 2012 07:17:58 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Ole Trøan <otroan@employees.org>
Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt
Thread-Index: AQHNeWDyHUsxdHhkUUml/eENyUzBb5dt5P4AgCx5BwCAASw+gIAASXKA
Date: Tue, 25 Sep 2012 14:17:57 +0000
Message-ID: <C53F80F0-F243-4A0D-B03D-BDEE4B4246BC@nominum.com>
References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C4668ED@SZXEML510-MBS.china.huawei.com> <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com> <D4AB11DA-0815-4E79-A097-F9B408210D81@employees.org>
In-Reply-To: <D4AB11DA-0815-4E79-A097-F9B408210D81@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <8BB5EC10418F74418F67594D584ABF81@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: dhc WG <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Sep 2012 14:18:00 -0000

On Sep 25, 2012, at 5:55 AM, Ole Trøan <otroan@employees.org> wrote:
> the use of a relay message is purely to get around the 3315 restriction of using a link-local address.
> the client is local to the node. assume for arguments sake that in the implementation the client is acting also as the relay.

I suspected as much.   IMHO, this is the wrong thing to do.   Just use the tunnel endpoint address instead of the link-local address in the case where there is no link-local address.   You'd have to make this standards-track and update RFC3315, but I think that's okay.   There's no magic to using the link-local address on broadcast interfaces—it's just the one address we can always count on the client having.   Of course, in this case we can't count on that, and if you look at section 1.1 of RFC3315 and section 11, you can see that the standard already accounts for cases where the link-local address is not used.   Actually, it looks like the spec may have a bug with respect to unicast that needs to be fixed.

v2.23.0 | Report a Bug | By Email