RE: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]

Anders Brandt <Anders_Brandt@sigmadesigns.com> Wed, 21 March 2012 12:13 UTC

Return-Path: <Anders_Brandt@sigmadesigns.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0B921F86A5; Wed, 21 Mar 2012 05:13:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
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 3z5kHnEx8PP3; Wed, 21 Mar 2012 05:13:28 -0700 (PDT)
Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id D0DD321F86A1; Wed, 21 Mar 2012 05:13:27 -0700 (PDT)
From: Anders Brandt <Anders_Brandt@sigmadesigns.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: RE: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
Thread-Topic: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
Thread-Index: AQHNBF/JLon5l3+WvUuFCR1klHlwqJZy4dkAgADEt4CAAQHN4A==
Date: Wed, 21 Mar 2012 12:13:19 +0000
Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC1B71@cph-ex1>
References: <4EB3F3D6.4090302@innovationslab.net> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <E6E7EE34-8244-40B6-84C1-C79E8BDE7921@nttv6.net> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <C8827D58-5C69-4A44-B9CE-86791466814E@nttv6.net> <4F63896E.10607@gmail.com> <CAFtBC=8=__8GdtExB8oYgA7pOfjxNfXCLzuOXz7_UKCPhwjenw@mail.gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <CABOxzu0kXRg=xdeq143+FWBTFc=+dbJD4LdpOGPi1KmyJ9YmEA@mail.gmail.com> <CABOxzu0x97UmA+Fq9d3e-Wp_ruT0gUni0UxnzgvtzDddjceg-A@mail.gmail.com> <03F31C213F2C6941BFDDBB4336E9E6CD0ABC058C@cph-e x1> <4F68F5E5.7060901@gmail.com>
In-Reply-To: <4F68F5E5.7060901@gmail.com>
Accept-Language: en-US, da-DK
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.10.120]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com
X-Mailman-Approved-At: Wed, 21 Mar 2012 05:41:43 -0700
Cc: 6man <ipv6@ietf.org>, "homenet@ietf.org Group" <homenet@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 21 Mar 2012 12:13:28 -0000

Brian Carpenter writes:
> On 2012-03-20 21:51, Anders Brandt wrote:
> > Kerry Lynn writes:
> >
> >> On Sat, Mar 17, 2012 at 2:22 AM, Dave Thaler <dthaler@microsoft.com>
> >> wrote:
> >>> Brian Carpenter writes:
> >>> [...]
> >
> > It is a surprise to me that ULA addresses are not by default routable within
> the site.
> > I can easily imagine a number of LLN border routers which autonomously
> > allocate different ULA prefixes for use within their individual LLN subnets.
> 
> IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if
> they cover an entire enterprise or home network, but not if they cover a
> subset.

I would like to see some arguments for that opinion?

To me subnet ULAs make a lot sense to me in environments where
100% autoconfiguration is required while remaining robust towards
changing ISP prefixes and backbone topologies.

The basic premise for the average homenet user is that he/she has
absolutely no clue what goes on in the network. And should not have.
 
> > Meeting a ULA address outside the local prefix will cause the LLN node
> > to forward its IP packets to the default gateway (border router) of
> > the LLN subnet. This way packets can travel between LLN subnets using
> > normal routing with long-term stable ULA addresses. We need the stable
> addresses for control-style applications in LLNs.
> >
> > Obviously it requires a routing protocol in the (homenet) LAN but are
> there other issues?
> 
> It doesn't just require a routing protocol; it also requires a routing policy
> that knows which routers have to block the ULAs (plural). That seems a lot
> more complex that a rule that says only a border router originates and
> delegates a ULA prefix, because that border router would also know to block
> the prefix across the border.

This "master" router may be added to the homenet at a later stage - e.g. when
changing ISP. My lightswitch-to-lamp address associations between two subnets
have to survive such changes.
I cannot rely on any prefix delegated from an unreliable source such as an ISP router.

I cannot rely on my user hand-carrying a ULA prefix delegated by the old ISP
router into the new ISP router. This ISP router may even be blocked for user
manipulation. And again, my user has no qualifications for doing this.

My understanding of the homenet CER is that it by default will filter any
ULA addressed traffic (?). Thus, no ULAs leave or enter into the Internet.

> Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis
> and discuss it over on v6ops.

I am familiar with Bing Liu's draft. Actually I see no objections against
multiple ULA prefixes in homenets in this draft.
Contrary, the draft says 

<quote>hosts assigned with ULA may occasionally be merged into one
  network</quote>....
<quote>make merging of networks simple and
  without the need to renumbering overlapping IP address space. </quote>

I agree in this text.

I agree that the discussion is also interesting to v6ops but I would like to
converge on the applicability within homenets before "taking it to the next level".

Anders
 
>     Brian
> 
> >
> > Thanks,
> >   Anders
> >>> You'll find the above logic in the current 3484bis draft.
> >>>
> >>> -Dave
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >> _______________________________________________
> >> homenet mailing list
> >> homenet@ietf.org
> >> https://www.ietf.org/mailman/listinfo/homenet
> > _______________________________________________
> > homenet mailing list
> > homenet@ietf.org
> > https://www.ietf.org/mailman/listinfo/homenet
> >