Re: [mif] Route option for DHCPv6 - next steps?

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 24 April 2012 12:20 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 3911121F87A3 for <mif@ietfa.amsl.com>; Tue, 24 Apr 2012 05:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.924
X-Spam-Level:
X-Spam-Status: No, score=-6.924 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 d0JV6NSsuNU0 for <mif@ietfa.amsl.com>; Tue, 24 Apr 2012 05:20:01 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 4654221F87A2 for <mif@ietf.org>; Tue, 24 Apr 2012 05:20:01 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q3OCJxYY032152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Apr 2012 14:19:59 +0200
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q3OCJx9o014052; Tue, 24 Apr 2012 14:19:59 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q3OCJw5v019478; Tue, 24 Apr 2012 14:19:58 +0200
Message-ID: <4F969A70.5090506@gmail.com>
Date: Tue, 24 Apr 2012 14:20:00 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Lorenzo Colitti <lorenzo@google.com>
References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <CAFFjW4hkGMm+mLSzpdWPcFLUcY3Hkyb+BDxh+5910YtfZxGD-A@mail.gmail.com> <CA+H2C9Zu3AS6aTxg1gebe0ZS2LXWmJjOPpbhaUHGZtXvF0UipQ@mail.gmail.com> <17F90720-AA1F-4F74-9598-2E5A5AC813CE@nttv6.net> <CAKD1Yr1s7SARfnowZV1uU=dDPi46-OjRQnM4otKsW3Y-k+84cw@mail.gmail.com> <F4D68CC2-27C5-4FB1-A11F-026E5261DB77@nttv6.net> <765F32AC-FBE3-4E8B-B698-1955C5601C2B@nominum.com> <4F96550E.6020709@gmail.com> <CAKD1Yr0d4ez4dogDk1gRvUHvWpoTBEg_4HatQQoa5oa3Yu9NFw@mail.gmail.com> <4F965BD2.1080906@gmail.com> <CAKD1Yr1=ry45uw=Xy1Gf5t30oC=ugzMGpwz7kbwctgXvg83WLw@mail.gmail.com>
In-Reply-To: <CAKD1Yr1=ry45uw=Xy1Gf5t30oC=ugzMGpwz7kbwctgXvg83WLw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: mif@ietf.org
Subject: Re: [mif] Route option for DHCPv6 - next steps?
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, 24 Apr 2012 12:20:02 -0000

Le 24/04/2012 10:04, Lorenzo Colitti a écrit :
> On Tue, Apr 24, 2012 at 16:52, Alexandru Petrescu
> <alexandru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.com>> wrote:
>
>         Why? The Linux Kernel supports RFC 4191, for example.
>
>
>     Yes, linux kernel would support it, as a Host. The CPE is not a Host.
>     (yes, a flag may exist to force it be a Router _and_ listen to RA - but
>     is that flag standard).
>
>
> For the kernel, I believe all you need to do is enable forwarding
> separately on the upstream and downstream interfaces instead of enabling
> forwarding globally (but I'm not 100% sure so feel free to correct me if
> that's wrong). That said, regardless of how it needs to be implemented,
> Linux-based CPEs have to do it already if they implement RFC 6204.
>
>             If one wants to deliver specific routes to a CPE box one
>             would't use
>             RAs, because routers ignore much of info in them.
>
>
>         RFC 6204 specifies how IPv6 CPEs should listen to default routes in
>         router advertisements. The CPEs could listen to more-specific
>         routes as
>         well.
>
>
>     This may mean one may need to: (1) modify RFC6204 to cover specific
>     routes as well, (2) modify RFC4191 to cover Routers as well, (3)
>     modify RFC6204 to do cellular base stations as well, in addition to
>     CPE of ADSL-type.
>
>
> As for #1 and #2, RFC 6024 doesn't explicitly specify what CPEs should
> listen to in RAs. I mentioned the default route earlier, but it mentions
> lots of other things too (e.g., the prefix information option to do
> SLAAC on the ISP-side interface, the L bit, and so on).

For example, RFC6204 says:
>    W-1:  When the router is attached to the WAN interface link, it MUST
>          act as an IPv6 host for the purposes of stateless [RFC4862] or
>          stateful [RFC3315] interface address assignment.

That is not enough for specific routes.  Ok it covers the default 
routes, but not specific routes such as rfc4191.

> If the CPE
> doesn't already support RFC 4191 (which is possible, if it's just using
> the standard Linux code), then it needs a code change regardless of
> whether you want to use DHCPv6 or RFC 4194.
>
> As for #3: RFC 6204 doesn't specify any specific technology, and it's
> certainly not limited to ADSL. Much of the behaviour it specifies is
> equally applicable to CPEs whose uplink is a cellular link.

?

'CPE' is not a term used for the cellular links, I think. RFC6204 says
'residential or small-office router'. I think it is a stretch to claim
that RFC6204 applies to cellular links. E.g. few if any cellular
terminals use DHCP as of today, whereas RFC6204 would require them all
to. Also, RFC6204 requires all cellular terminals to use Ethernet
encapsulation on their WAN interface whereas none actually does.

There is another RFC - 3316 - "IPv6 for some 2G and 3G Cellular Hosts"
which relates more to cellular.

Alex