Re: [homenet] HNCP: Few proposed changes for next draft version

Pierre Pfister <pierre.pfister@darou.fr> Tue, 03 June 2014 08:34 UTC

Return-Path: <SRS0=FXNF=3A=darou.fr=pierre.pfister@bounces.m4x.org>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F2A1A017B for <homenet@ietfa.amsl.com>; Tue, 3 Jun 2014 01:34:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b3yJtw5wa-V for <homenet@ietfa.amsl.com>; Tue, 3 Jun 2014 01:34:34 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2422C1A0162 for <homenet@ietf.org>; Tue, 3 Jun 2014 01:34:33 -0700 (PDT)
Received: from [10.148.10.38] (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 8C8381408EFA2; Tue, 3 Jun 2014 10:34:25 +0200 (CEST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Pierre Pfister <pierre.pfister@darou.fr>
In-Reply-To: <538D828C.1050403@globis.net>
Date: Tue, 03 Jun 2014 10:34:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1CE2243A-6C33-4D59-BF21-9C9A96F70CA4@darou.fr>
References: <538CC608.1010109@openwrt.org> <538D73C7.1090700@globis.net> <538D7607.6030608@openwrt.org> <538D7C07.4060203@globis.net> <538D7F23.1010800@openwrt.org> <538D828C.1050403@globis.net>
To: Ray Hunter <v6ops@globis.net>
X-Mailer: Apple Mail (2.1878.2)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Tue Jun 3 10:34:26 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/l1L3vhgnrIr6eifrZf13S4nI7dg
Cc: Steven Barth <cyrus@openwrt.org>, homenet@ietf.org
Subject: Re: [homenet] HNCP: Few proposed changes for next draft version
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jun 2014 08:35:06 -0000

Hello Ray,


Le 3 juin 2014 à 10:08, Ray Hunter <v6ops@globis.net> a écrit :

>> Steven Barth <mailto:cyrus@openwrt.org>
>> 3 June 2014 09:54
>> 
>> Am 03.06.2014 09:40, schrieb Ray Hunter:
>>>> Steven Barth <mailto:cyrus@openwrt.org>
>>>> 3 June 2014 09:15
>>>> 
>>>> Well maybe it was worded a bit ambiguously. The main idea behind this was that an HNCP router should provide "basic connectivity" in the form of DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should not do anything fancy and just work as legacy devices believing the homenet is their ISP.
>>>> 
>>>> This should not mean you should be able to "tunnel" through 7084 routers or so.
>>>> 
>>>> Does that sound sane? And maybe what would be a better wording for this idea?
>>> 
>>> It is a sane idea, and I applaud any manufacturer that can prevent that a lot of 7084 routers are destined for the landfill sooner than they should be.
>> I guess this would not only apply to 7084 routers but "current IPv6-capable homerouters" in general in the end.
>> 
>>> 
>>> But it's still a can of worms and you should think very carefully whether you want this as a SHOULD in HNCP. I humbly suggest MAY at most.
>> I guess I'm fine with that.
>> 
>>> 
>>> e.g. What about the topology:
>>> 
>>> Homenet router ----- Homenet Router
>>>    |                    |
>>>    |                    |
>>> L2 switch e.g. Powerline Ethernet
>>>          |
>>>          |
>>>     7084 router
>>> 
>>> Which Homenet router acts as the Service Provider Router of 7084?
>> The behavior is essentially the same as with clients right now. One homenet router per link is elected as DHCP / DHCPv6-server. The only addition here is that this elected router now acts as PD-server as well.
>> 
>>> 
>>> That's even before considering the question, what do you do when the 7084 router is inserted between two Homenet routers?
>> This should be same as the current situation: If you are lucky that 7084 router gives you PD then you have essentially two separate homenets, if not that homenet router behind the legacy one gets no (IPv6)-connectivity and probably nasty IPv4 double-NATs.  There is not much you can do though except teach that router to speak homenet.
> 
> 
> 
> Homenet router --->PD--7084 router --> PD---- Homenet Router
>    |                       |                         |
>    |                       v PD                      |
>    |                       |                         |
>     ---L2 switch e.g. Powerline Ethernet ------------
>            |
>            |
>     7084 router
> 
> 
> PD loops? End users are creative.

Sure they are ! The details about DHCP server selection or prefix delegation are in the prefix assignment draft (http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-01), which is part of our implementation.

The proposed solution to this kind of situations is « If a delegated prefix is included in another delegated prefix, it is ignored. ».
Basically, the homenet router on the right will not take into account the delegated prefix it got from the middle 7084 router because it is a sub-prefix from the left homenet router’s delegated prefix.

I think this logic solves most of these problematic topologies. It won’t prevent network split if homenet routers are not layer-2-connected thought. 

In general, I think supporting prefix delegation is important. Even if HNCP is widely deployed, some network devices will make the choice of simplicity by only using DHCPv6-PD (without sub-delegation).

Cheers,

Pierre


>>> 
>>> 
>>> In fairness I should declare that I was extremely skeptical about publishing 7084, and whether it would be harmful for Homenet.
>>> 
>> Well I guess it doesn't really do much in favor of homenet by proclaiming: there is only the ISP on one side and clients on the other side you need to care about. Well at least it defines some sane requirements (and some less sane ones) regarding these 2 issues.
> It was decided that any updates to 6204 for the WAN interface would be out of scope for 7084 and that these would instead be deferred into Homenet.
> 
> -- 
> Regards,
> RayH
> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet