Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 13 September 2011 20:42 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C4321F8C8F for <mif@ietfa.amsl.com>; Tue, 13 Sep 2011 13:42:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.191
X-Spam-Level:
X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=1.408, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOHvWn02aBGW for <mif@ietfa.amsl.com>; Tue, 13 Sep 2011 13:42:34 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 054AB21F8C8E for <mif@ietf.org>; Tue, 13 Sep 2011 13:42:33 -0700 (PDT)
Received: by fxd18 with SMTP id 18so1020011fxd.31 for <mif@ietf.org>; Tue, 13 Sep 2011 13:44:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qsNBOBH38y/Lcuxw0UVAuXhXyw9XgKckpaUlD+fRyjs=; b=A4ndFcyWkpi63KkYotILoXEeEGISePJTye7UUf++GBZuRrRiaeV/Xrn0FEqXpvnc1j RDgQ2MrwI6Q/l/QHD5s/pHetV3bk7qYOQBwnhLjv/fW1x9uMh/tIvZDLrJ0p+5PXp3ag e6WGDZzDRa3lTTRMz0gPLiV1QH50flZuVb450=
Received: by 10.223.91.75 with SMTP id l11mr547169fam.66.1315946680444; Tue, 13 Sep 2011 13:44:40 -0700 (PDT)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id s13sm1373876fad.18.2011.09.13.13.44.36 (version=SSLv3 cipher=OTHER); Tue, 13 Sep 2011 13:44:36 -0700 (PDT)
Message-ID: <4E6FC0AE.5000108@gmail.com>
Date: Tue, 13 Sep 2011 22:44:30 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: mif@ietf.org
References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <CFDF82EE-052B-4A61-AE1B-152337822B6E@nominum.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <B987CA14-569C-428C-8D8A-C97A0E42EF48@nominum.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca>
In-Reply-To: <4E6FACF6.5000007@viagenie.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Sep 2011 20:42:34 -0000

Le 13/09/2011 21:20, Simon Perreault a écrit :
> Ted Lemon wrote, on 09/13/2011 03:15 PM:
>> Also, I'm a bit confused by the idea of an interface route with no
>> router address in IPv6.   I will admit to being something of a tyro
>> when it comes to these things, but I don't understand how that
>> would work.   Does the client simply multicast every packet?   Is
>> there an RFC or draft that documents how this works?
>
> I'm guessing that's a point-to-point interface. So you don't need the
> next hop's L2 address. You just send it down the tube and it gets at
> the other end. The classic example is PPP.

YEs, it is a "no ARP" interface, but in some 3G+ it is not PPP.

Yes, the client just sends it down the tube.

But no, the Client can't set up that default route when all is being
given is "0.0.0.0".  It must tell the interface name.  The Client by
itself is not capable to decide how to insert that default router entry
in its routing table, it just can't solve "0.0.0.0" on some interface
name so it must be told the interface name by some spec or mechanism.

Alex

>
> Simon