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

Mark Andrews <marka@isc.org> Sat, 17 March 2012 00:13 UTC

Return-Path: <marka@isc.org>
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 9B92321E807B for <ipv6@ietfa.amsl.com>; Fri, 16 Mar 2012 17:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.544
X-Spam-Level:
X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599]
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 JVe3i-JTPpwE for <ipv6@ietfa.amsl.com>; Fri, 16 Mar 2012 17:13:19 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBAF21E8042 for <ipv6@ietf.org>; Fri, 16 Mar 2012 17:13:18 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id C8A215F98AF; Sat, 17 Mar 2012 00:12:58 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:d1fb:f2c0:5ce0:8d7d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CA992216C33; Sat, 17 Mar 2012 00:12:56 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D5A711E9FC42; Sat, 17 Mar 2012 11:12:52 +1100 (EST)
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
From: Mark Andrews <marka@isc.org>
References: <4EB3F3D6.4090302@innovationslab.net> <CAC1-dtnas++ahkBmpdyq7DbyAEg0W6bZY16qGzKmsP10vC39FQ@mail.gmail.com> <4EEA3D20.7020603@innovationslab.net> <CAKFn1SFvs0PzBXtEWWo814Oe5TJmbQEJBm5FeYJY5xzrr=KFSw@mail.gmail.com> <4EEA5793.8080800@gmail.com> <CAKFn1SHA-=cQ_=5rJVLVMvQYXoTL_D1dCR=uWZK-qFrcGp6P-w@mail.gmail.com> <4EEA7AF8.2090508@gmail.com> <CAC1-dtn9M8-9cPAmkhCiGV0Gi5+Gfs8GAssTOaA-ZFhyUY3feg@mail.gmail.com> <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>
Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
In-reply-to: Your message of "Sat, 17 Mar 2012 07:41:50 +1300." <4F63896E.10607@gmail.com>
Date: Sat, 17 Mar 2012 11:12:52 +1100
Message-Id: <20120317001252.D5A711E9FC42@drugs.dv.isc.org>
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, Brian Haberman <brian@innovationslab.net>, Bob Hinden <bob.hinden@gmail.com>, Dave Thaler <dthaler@microsoft.com>
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: Sat, 17 Mar 2012 00:13:19 -0000

In message <4F63896E.10607@gmail.com>, Brian E Carpenter writes:
> On 2012-03-16 23:30, Arifumi Matsumoto wrote:
> ...
> > Rather, my question was about the design choice.
> > 
> > Regarding the design of ULA and how to use the ULA, can we agree that 
> > ULA-to-ULA communication within the same /48 prefix is not always preferred
> > over other communications using IPv4 or IPv6 global addresses ?
> 
> I would expect it to be preferred as a result of longest match; I would
> not expect it to be a special case in the default policy for global
> scope addresses, if that is the question.
> 
> >>> Second,
> >>> when a user configures his policy table, the configured table is overwrit
> ten by
> >>> this implementation dependent policy injection behavior ?
> >>> Can the user suppress this behavior of policy injection ?
> >>> This issue should arise also when a policy distributing mechanism is read
> y.
> >> Good questions.  Do you have suggested answers to those questions?
> >> I might throw out a strawman of:
> >>
> >> Any automatic rows added by the implementation as a result of address
> >> acquisition MUST NOT override a row for the same prefix configured
> >> via other means.   That is, rows can be added but never updated
> >> automatically.   An implementation SHOULD provide a means for
> >> an administrator to disable automatic row additions.
> > 
> > 
> > My suggested answer for this was to use macros, which can be
> > added/deleted by a user, and interpreted as the actual prefix
> > attached to the hosts.
> 
> That's an implementation method. I think Dave's proposed rule is
> correct.
> 
>     Brian

What I see missing is a way for a node to know what the site boundaries
are with respect to address selection.   Adding a site prefix length
to RA Prefix Information would provide a 99.99% solution to this.  If
the Site Prefix field is non-zero it is valid.

e.g.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     | Prefix Length |L|A| Reserved1 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Valid Lifetime                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Preferred Lifetime                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Site Prefix  |           Reserved2                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                            Prefix                             +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org