Re: ULA macro in the policy table Re: -06 candidate

Mark Andrews <marka@isc.org> Mon, 23 January 2012 07:10 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 D6E2321F8607 for <ipv6@ietfa.amsl.com>; Sun, 22 Jan 2012 23:10:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level:
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 ol1FJz66lldX for <ipv6@ietfa.amsl.com>; Sun, 22 Jan 2012 23:10:24 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id E8B1421F85BD for <ipv6@ietf.org>; Sun, 22 Jan 2012 23:10:23 -0800 (PST)
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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 2E14DC9465; Mon, 23 Jan 2012 07:09:50 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:f85b:3165:984b:f09b]) (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 8F585216C6B; Mon, 23 Jan 2012 07:09:49 +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 9A8DA1BD391A; Mon, 23 Jan 2012 18:09:47 +1100 (EST)
To: Arifumi Matsumoto <arifumi@nttv6.net>
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> <0D0150C3-9E05-4839-ACF1-0E7196420D2F@ecs.soton.ac.uk> <CAKFn1SFp_r7EJ6CpM8EF2zkcJz1z34CdEcRt2i5xcsrWkCBQwQ@mail.gmail.com> <EMEW3|bd681ced736eee0700e443f9acc256d8nBFAnB03tjc|ecs.soton.ac.uk|0D0150C3-9E05-4839-ACF1-0E7196420D2F@ecs.soton.ac.uk> <CAC1-dtnt+NKnqJaj-osfxwDf=uLpfv62hBBGDzftGL8KA6jdEA@mail.gmail.com> <6DDA8D20-8D10-4B6E-B101-9812FD83B781@nttv6.net> <20120117222653.99F9C1B88A6D@drugs.dv.isc.org> <43F32BAA-C3CB-4214-BCE7-B1CD75EC59FC@nttv6.net>
Subject: Re: ULA macro in the policy table Re: -06 candidate
In-reply-to: Your message of "Mon, 23 Jan 2012 15:33:26 +0900." <43F32BAA-C3CB-4214-BCE7-B1CD75EC59FC@nttv6.net>
Date: Mon, 23 Jan 2012 18:09:47 +1100
Message-Id: <20120123070947.9A8DA1BD391A@drugs.dv.isc.org>
Cc: 6man Mailing List <ipv6@ietf.org>, Tim Chown <tjc@ecs.soton.ac.uk>, draft-ietf-6man-rfc3484-revise@tools.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: Mon, 23 Jan 2012 07:10:25 -0000

In message <43F32BAA-C3CB-4214-BCE7-B1CD75EC59FC@nttv6.net>, Arifumi Matsumoto writes:
> Mark,
> thank you for your comment.
> 
> As you mention it, it should be less harmful to give the whole ULA
> block a lower precedence value, if we assume ULA leakages will happen
> here and there by DNS mis-configurations, address information exchange
> in P2P applications, and so on.
> 
> Regarding communication between ULAs, such a network that really wants
> to make use of multiple ULA blocks should have a way of controlling
> address selection behavior of their hosts, such as policy table
> configuration and DNS configuration.
> 
> The question is whether we can accept the appearance of macro in
> the policy table.
> 
>          Prefix        Precedence Label
>          ::1/128               60     0
>          <YOUR ULA>:/48        50     1

You also want the labels for each ULA/48 to be seperate.

	    <YOUR ULA>:/48        50     #

>          ::/0                  40     2
>          ::ffff:0:0/96         30     3
>          2002::/16             20     4
>          2001::/32             10     5
>          fc00::/7               5     6
>          ::/96                  1    10
>          fec0::/10              1    11
>          3ffe::/16              1    12
> 
>     I assume the line of <YOUR ULA> will be interpreted as a line
>     or lines of ULA prefix(es) that is attached to interface(s).
> 
> Another point is that a host has to maintain the ULA line in responses
> to addition and deletion of the addresses.
> 
> Regards,
> 
> On 2012/01/18, at 7:26, Mark Andrews wrote:
> 
> > 
> > ULA need to be de-preferenced except for the local ULA prefixes.
> > 
> > Below is what I use in FreeBSD 8.  It keeps local traffic using
> > fd92:7065:b8e::/48 rather than using the PA address.  If you learn
> > a ULA destination address that is not local YOU DO NOT WANT TO USE
> > IT by default when you have another choice.
> > 
> > What you do want is for a interface when it learns a ULA address
> > to add the corresponding /48 prefix with a given precedence and a
> > unique label to the table if the prefix does not exist.  And
> > appropriate cleaning be done when no more interfaces exist in the
> > /48.  This may require a manual tag on table entries.
> > 
> > Mark
> > 
> >>  more /etc/ip6addrctl.conf 
> > #Prefix                          Prec Label     
> > ::1/128                           50     0
> > ::/0                              40     1     
> > 2002::/16                         30     2        
> > ::/96                             20     3        
> > ::ffff:0.0.0.0/96                 35     4        
> > fd92:7065:b8e::/48                45     5 
> > fc00::/7                          5      6
> >> ifconfig nfe0 inet6
> > nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> > 	options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>
> > 	inet6 fe80::218:f3ff:feba:9a37%nfe0 prefixlen 64 scopeid 0x5 
> > 	inet6 fd92:7065:b8e:0:218:f3ff:feba:9a37 prefixlen 64 autoconf 
> > 	inet6 2001:470:1f00:820:218:f3ff:feba:9a37 prefixlen 64 autoconf 
> >> 
> > -- 
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> 
> 
> --
> Arifumi Matsumoto
>   NGN System Architecture Project
>   NTT Service Integration Laboratories
>   E-mail: arifumi@nttv6.net
>   TEL +81-422-59-3334 FAX +81-422-59-6364
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org