[Tools-discuss] Re: idnits in draft-ietf-v6ops-addr-select-ps

[Fred Baker <[e-mail]>]

Input to the next rev of idnits whenever it comes...

I posted the idnits output to a team doing a job in v6ops. The fault  
in part complained about the use of ULA addresses, which one has to  
consider correct in the context. We need one of two things: a  
documented set of ULAs that the tool will accept, or that the tool  
will accept any ULA.


On Mar 20, 2007, at 9:08 AM, Arifumi Matsumoto wrote:
> Good Morning Fred.
>
> About addresses like 3ffe:1800::.. and 192.47.., I can change
> them to documentation address. However, about ULA addresses like
> fd01:..., how I can change them ?
>
> Fred Baker wrote:
>> I'll need an updated draft addressing this:
>> idnits 2.04.01
>> tmp/draft-ietf-v6ops-addr-select-ps-00.txt:
>> tmp/draft-ietf-v6ops-addr-select-ps-00.txt(243): Found possible  
>> IPv6 address '3ffe:1800:a:1::' in position 37; this doesn't match  
>> RFC3848's suggested 2001:DB8::/32 address range.
>>   -->                                  |  3ffe:1800:a:1::/64
>>                                           ^
>> tmp/draft-ietf-v6ops-addr-select-ps-00.txt(297): Found possible  
>> IPv6 address '3ffe:1800::E' in position 52; this doesn't match  
>> RFC3848's suggested 2001:DB8::/32 address range.
>>   -->                         |  Internet  |  | Host-B | 3ffe: 
>> 1800::EUI64
>>                                                          ^
>> tmp/draft-ietf-v6ops-addr-select-ps-00.txt(310): Found possible  
>> IPv6 address '3ffe:1800:a:1::' in position 37; this doesn't match  
>> RFC3848's suggested 2001:DB8::/32 address range.
>>   -->                                  |  3ffe:1800:a:1::/64
>>                                           ^
>> tmp/draft-ietf-v6ops-addr-select-ps-00.txt(521): Found possible  
>> IPv4 address '192.47.163.1' in position 46; this doesn't match  
>> RFC3330's suggested 192.0.2.0/24 address range.
>>   -->                            +-----+--+ A    = 192.47.163.1
>>                                                    ^
>> tmp/draft-ietf-v6ops-addr-select-ps-00.txt(531): Found possible  
>> IPv6 address 'fd01:2:3::' in position 32; this doesn't match  
>> RFC3848's suggested 2001:DB8::/32 address range.
>>   -->                              | fd01:2:3::/48 (ULA)
>>                                      ^
>> tmp/draft-ietf-v6ops-addr-select-ps-00.txt(536): Found possible  
>> IPv6 address 'fd01:2:3:4::' in position 37; this doesn't match  
>> RFC3848's suggested 2001:DB8::/32 address range.
>>   -->                                  |  fd01:2:3:4::/64 (ULA)
>>                                           ^
>> tmp/draft-ietf-v6ops-addr-select-ps-00.txt(540): Found possible  
>> IPv6 address 'fd01:2:3:4::100' in position 37; this doesn't match  
>> RFC3848's suggested 2001:DB8::/32 address range.
>>   -->                            +-+----+ fd01:2:3:4::100 (ULA)
>>                                           ^
>> tmp/draft-ietf-v6ops-addr-select-ps-00.txt(578): Found possible  
>> IPv6 address 'fc12:3456:789a::80' in position 47; this doesn't  
>> match RFC3848's suggested 2001:DB8::/32 address range.
>>   -->                        +----+-+  +-->+------+  
>> fc12:3456:789a::80
>>                                                     ^
>> tmp/draft-ietf-v6ops-addr-select-ps-00.txt(581): Found possible  
>> IPv6 address 'fc12:3456:789a::' in position 9; this doesn't match  
>> RFC3848's suggested 2001:DB8::/32 address range.
>>   -->         fc12:3456:789a::/48 |    |
>>               ^
>> tmp/draft-ietf-v6ops-addr-select-ps-00.txt(710): Appendix start:  
>> Appendix A.  Appendix. Revision History.
>>     Appendix start: Appendix A.  Appendix. Revision History
>>   Checking boilerplate required by RFC 3978 and 3979, updated by  
>> RFC 4748:
>>   * This document has an original RFC 3978 Section 5.4 Copyright  
>> Line,
>>     instead of the newer IETF Trust Copyright according to RFC 4748.
>>   * This document has an original RFC 3978 Section 5.5 Disclaimer,  
>> instead of
>>     the newer disclaimer which includes the IETF Trust according  
>> to RFC 4748.
>>   Checking nits according to http://www.ietf.org/ietf/1id- 
>> guidelines.txt:
>>     No issues found here.
>>   Checking nits according to http://www.ietf.org/ID-Checklist.html:
>>   * There are 1 instance of lines with non-RFC3330-compliant IPv4  
>> addresses
>>     in the document.  If these are example addresses, they should  
>> be changed.
>>   * There are 8 instances of lines with non-RFC3849-compliant IPv6  
>> addresses
>>     in the document.  If these are example addresses, they should  
>> be changed.
>>   Miscellaneous warnings:
>>   - The copyright year in the RFC 3978 Section 5.4 Copyright Line  
>> does not
>>     match the current year
>>   Checking references for intended status: Proposed Standard
>>   - Outdated reference: A later version (-03) exists of
>>     draft-fujisaki-dhc-addr-select-opt-02
>>   - Outdated reference: A later version (-06) exists of
>>     draft-ietf-v6ops-nap-04
>>     Summary: 4 errors, 3 warnings
>> --------------------------------------------------------------------- 
>> ----------- 2    IPv6 Operations Working  
>> Group                               A. Matsumoto
>> 3    Internet-Draft                                                
>> T. Fujisaki
>> 4    Intended status: Standards  
>> Track                                     NTT
>> 5    Expires: May 14,  
>> 2007                                          R. Hiromi
>> 6                                                                  
>> K. Kanayama
>> 7                                                                
>> Intec Netcore
>> 8                                                            
>> November 10, 2006
>> 10         Problem Statement of Default Address Selection in Multi- 
>> prefix
>> 11            Environment: Operational Issues of RFC3484 Default  
>> Rules
>> 12                     draft-ietf-v6ops-addr-select-ps-00.txt
>> 14    Status of this Memo
>> 16       By submitting this Internet-Draft, each author represents  
>> that any
>> 17       applicable patent or other IPR claims of which he or she  
>> is aware
>> 18       have been or will be disclosed, and any of which he or  
>> she becomes
>> 19       aware will be disclosed, in accordance with Section 6 of  
>> BCP 79.
>> 21       Internet-Drafts are working documents of the Internet  
>> Engineering
>> 22       Task Force (IETF), its areas, and its working groups.   
>> Note that
>> 23       other groups may also distribute working documents as  
>> Internet-
>> 24       Drafts.
>> 26       Internet-Drafts are draft documents valid for a maximum  
>> of six months
>> 27       and may be updated, replaced, or obsoleted by other  
>> documents at any
>> 28       time.  It is inappropriate to use Internet-Drafts as  
>> reference
>> 29       material or to cite them other than as "work in progress."
>> 31       The list of current Internet-Drafts can be accessed at
>> 32       http://www.ietf.org/ietf/1id-abstracts.txt.
>> 34       The list of Internet-Draft Shadow Directories can be  
>> accessed at
>> 35       http://www.ietf.org/shadow.html.
>> 37       This Internet-Draft will expire on May 14, 2007.
>> 39    Copyright Notice
>> 41       Copyright (C) The Internet Society (2006).
>> 43    Abstract
>> 45       One physical network can carry multiple logical  
>> networks.  Moreover,
>> 46       we can use multiple physical networks at the same time in  
>> a host.  In
>> 47       that environment, end-hosts might have multiple IP  
>> addresses and be
>> 48       required to use them selectively.  Without an appropriate  
>> source/
>> 49       destination address selection mechanism, the host will  
>> experience
>> 50       some trouble in the communication.  RFC 3484 defines both  
>> the source
>> 51       and destination address selection algorithms, but the  
>> multi-prefix
>> 52       environment considered here needs additional rules beyond  
>> the default
>> 53       operation.  This document describes the possible problems  
>> that end-
>> 54       hosts could encounter in an environment with multiple  
>> logical
>> 55       networks.
>> 57    Table of Contents
>> 59       1.   
>> Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
>> 60         1.1.  Scope of this  
>> document . . . . . . . . . . . . . . . . . .  3
>> 61       2.  Problem  
>> Statement  . . . . . . . . . . . . . . . . . . . . . .  3
>> 62         2.1.  Source Address  
>> Selection . . . . . . . . . . . . . . . . .  3
>> 63           2.1.1.  Multiple Routers on Single  
>> Interface . . . . . . . . .  4
>> 64           2.1.2.  Ingress Filtering  
>> Problem  . . . . . . . . . . . . . .  5
>> 65           2.1.3.  Half-Closed Network  
>> Problem  . . . . . . . . . . . . .  6
>> 66           2.1.4.  Combined Use of Global and  
>> ULA . . . . . . . . . . . .  7
>> 67           2.1.5.  Site  
>> Renumbering . . . . . . . . . . . . . . . . . . .  8
>> 68           2.1.6.  Multicast Source Address  
>> Selection . . . . . . . . . .  8
>> 69           2.1.7.  Temporary Address  
>> Selection  . . . . . . . . . . . . .  8
>> 70         2.2.  Destination Address  
>> Selection  . . . . . . . . . . . . . .  9
>> 71           2.2.1.  IPv4 or IPv6  
>> prioritization  . . . . . . . . . . . . .  9
>> 72           2.2.2.  ULA and IPv4 dual-stack  
>> environment  . . . . . . . . . 10
>> 73           2.2.3.  ULA or Global  
>> Prioritization . . . . . . . . . . . . . 10
>> 74       3.   
>> Solutions  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
>> 75         3.1.  More Specific Routes (RFC  
>> 4191)  . . . . . . . . . . . . . 11
>> 76         3.2.  Policy Table  
>> Manipulation  . . . . . . . . . . . . . . . . 11
>> 77         3.3.  Revising RFC  
>> 3484  . . . . . . . . . . . . . . . . . . . . 12
>> 78       4.   
>> Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
>> 79       5.  Security  
>> Considerations  . . . . . . . . . . . . . . . . . . . 12
>> 80       6.  IANA  
>> Considerations  . . . . . . . . . . . . . . . . . . . . . 12
>> 81       7.   
>> References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
>> 82         7.1.  Normative  
>> References . . . . . . . . . . . . . . . . . . . 12
>> 83         7.2.  Informative  
>> References . . . . . . . . . . . . . . . . . . 13
>> 84       Appendix A.  Appendix. Revision  
>> History  . . . . . . . . . . . . . 13
>> 85       Authors'  
>> Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
>> 86       Intellectual Property and Copyright  
>> Statements . . . . . . . . . . 15
>> 88    1.  Introduction
>> 90       One physical network can carry multiple logical  
>> networks.  In that
>> 91       case, an end-host has multiple IP addresses.  In the IPv4- 
>> IPv6 dual
>> 92       stack environment or in a site connected to both ULA  
>> [RFC4193] and
>> 93       Global scope networks, an end-host has multiple IP  
>> addresses.  These
>> 94       are examples of the networks that we focus on in this  
>> document.  In
>> 95       such an environment, an end-host will encounter some  
>> communication
>> 96       trouble.
>> 98       Inappropriate source address selection at the end-host  
>> causes
>> 99       unexpected asymmetric routing or filtering by a router on  
>> the way
>> 100       back or discard due to there being no route to the host.
>> 102       Considering a multi-prefix environment, the destination  
>> address
>> 103       selection is also important for correct communication  
>> establishment.
>> 104       The key to the appropriate process will come from the  
>> way to
>> 105       configure the source address and destination address to the
>> 106       interfaces at the end-hosts by the network policy of the  
>> site.
>> 108       RFC 3484 [RFC3484] defines both source and destination  
>> address
>> 109       selection algorithms.  In most cases, the host will be  
>> able to
>> 110       communicate with the targeted host using the  
>> algorithms.  But there
>> 111       are still problematic cases such as when multiple  
>> default routes are
>> 112       supplied.  This document describes such possibilities of  
>> false
>> 113       dropping during address selection.
>> 115       In addition, the provision of an address policy table is  
>> an important
>> 116       matter.  RFC 3484 describes all the algorithms for  
>> setting the
>> 117       address policy table but it makes no mention of the  
>> provisions of
>> 118       address policy and does not define how to set it except  
>> manually.
>> 120    1.1.  Scope of this document
>> 122       There has been a lot of discussion about "multiple  
>> addresses/
>> 123       prefixes" but the multi-homing issues for redundancy are  
>> out of our
>> 124       scope.  Cooperation with a mechanism like shim6 is  
>> rather desirable.
>> 125       We focus on an end-site network environment.  The scope  
>> of this
>> 126       document is to sort out problematic cases of false  
>> dropping of the
>> 127       address selection within a multi-prefix environment.
>> 129    2.  Problem Statement
>> 131    2.1.  Source Address Selection
>> 132    2.1.1.  Multiple Routers on Single Interface
>> 134                              ==================
>> 135                              |    Internet    |
>> 136                              ==================
>> 137                                 |          |
>> 138                   2001:db8::/32 |          | 3ffe:1800::/32
>> 139                            +----+-+      +-+----+
>> 140                            | ISP1 |      | ISP2 |
>> 141                            +----+-+      +-+----+
>> 142                                 |          |
>> 143                 2001:db8:a::/48 |          | 3ffe:1800:a::/48
>> 144                          +------+---+ +----+-----+
>> 145                          | Gateway1 | | Gateway2 |
>> 146                          +--------+-+ +-+--------+
>> 147                                   |     |
>> 148                 2001:db8:a:1::/64 |     | 3ffe:1800:a:1::/64
>> 149                                   |     |
>> 150                            -----+-+-----+------
>> 151                                 |
>> 152                               +-+----+ 2001:db8:a:1:EUI64
>> 153                               | Host | 3ffe:1800:a:1:EUI64
>> 154                               +------+
>> 156                                    [Fig. 1]
>> 158       Generally speaking, there is no interaction between next- 
>> hop
>> 159       determination and address selection.  In this example,  
>> when Host
>> 160       sends a packet via Gateway1, the Host does not  
>> necessarily choose the
>> 161       address 2001:db8:a:1::EUI64 given by Gateway1 as the  
>> source address.
>> 162       This causes the same problem as described in the next  
>> section
>> 163       'Ingress Filtering Problem'.
>> 165       To solve this case, one approach is to configure  
>> correctly both the
>> 166       routing configuration and address selection policy at  
>> Host.  You can
>> 167       use RFC 4191 [RFC4191] to deliver routing information to  
>> hosts.
>> 168       Another approach is to configure the gateways to make  
>> use of packet
>> 169       redirection between the gateways.
>> 171    2.1.2.  Ingress Filtering Problem
>> 173                            ==================
>> 174                            |    Internet    |
>> 175                            ==================
>> 176                                 |       |
>> 177                   2001:db8::/32 |       | 3ffe:1800::/32
>> 178                            +----+-+   +-+----+
>> 179                            | ISP1 |   | ISP2 |
>> 180                            +----+-+   +-+----+
>> 181                                 |       |
>> 182                 2001:db8:a::/48 |       | 3ffe:1800:a::/48
>> 183                                ++-------++
>> 184                                | Gateway |
>> 185                                +----+----+
>> 186                                     |  2001:db8:a:1::/64
>> 187                                     |  3ffe:1800:a:1::/64
>> 188                           ------+---+----------
>> 189                                 |
>> 190                               +-+----+ 2001:db8:a:1:EUI64
>> 191                               | Host | 3ffe:1800:a:1:EUI64
>> 192                               +------+
>> 194                                    [Fig. 2]
>> 196       When a relatively small site, which we call a "customer  
>> network", is
>> 197       attached to two upstream ISPs, each ISP delegates a  
>> network address
>> 198       block, which is usually /48, and a host has multiple  
>> IPv6 addresses.
>> 200       When the source address of an outgoing packet is not the  
>> one that is
>> 201       delegated by an upstream ISP, there is a possibility  
>> that the packet
>> 202       will be dropped at the ISP by its Ingress Filter.  Ingress
>> 203       filtering(uRPF: unicast Reverse Path Forwarding) is  
>> becoming more and
>> 204       more popular among ISPs in order to mitigate the damage  
>> of DoS
>> 205       attacks.
>> 207       In this example, when the Gateway chooses the default  
>> route to ISP2
>> 208       and the Host chooses 2001:db8:a:1::EUI64 as the source  
>> address for
>> 209       packets sent to a host(2001:fa8::1) somewhere in the  
>> Internet, the
>> 210       packets may be dropped at ISP2 because of Ingress  
>> Filtering.
>> 212       One possible solution for this problem is to adopt  
>> source-address-
>> 213       based routing at the customer site's gateway, but this  
>> manner of
>> 214       routing is not very popular at the moment.
>> 216    2.1.3.  Half-Closed Network Problem
>> 218       You can see a second typical source address selection  
>> problem in a
>> 219       multihome site with global-closed mixed connectivity  
>> like the figure
>> 220       below.  In this case, Host-A is in a multihomed network  
>> and has two
>> 221       IPv6 addresses, one delegated from each of the upstream  
>> ISPs.  Note
>> 222       that ISP2 is a closed network and does not have  
>> connectivity to the
>> 223       Internet.
>> 225                               +--------+
>> 226                               | Host-C | 3ffe:503:c:1:EUI64
>> 227                               +-----+--+
>> 228                                     |
>> 229                            ==============  +--------+
>> 230                            |  Internet  |  | Host-B | 3ffe: 
>> 1800::EUI64
>> 231                            ==============  +--------+
>> 232                                 |           |
>> 233                   2001:db8::/32 |           | 3ffe:1800::/32
>> 234                            +----+-+   +-+---++
>> 235                            | ISP1 |   | ISP2 | (Closed Network/ 
>> VPN tunnel)
>> 236                            +----+-+   +-+----+
>> 237                                 |       |
>> 238                 2001:db8:a::/48 |       | 3ffe:1800:a::/48
>> 239                                ++-------++
>> 240                                | Gateway |
>> 241                                +----+----+
>> 242                                     |  2001:db8:a:1::/64
>> 243                                     |  3ffe:1800:a:1::/64
>> 244                           ------+---+----------
>> 245                                 |
>> 246                              +--+-----+ 2001:db8:a:1:EUI64
>> 247                              | Host-A | 3ffe:1800:a:1:EUI64
>> 248                              +--------+
>> 250                                    [Fig. 3]
>> 252       You don't need two physical network connection here.   
>> The connection
>> 253       from Gateway to ISP2 can be a logical link over ISP1 and  
>> the
>> 254       Internet.
>> 256       When Host-A starts the connection to Host-B in ISP2, the  
>> source
>> 257       address of a sending packet will be the one delegated  
>> from ISP2, that
>> 258       is 3ffe:1800:a:1:EUI64, because of rule 8 (longest  
>> matching prefix)
>> 259       in RFC 3484.
>> 261       Host-C is located somewhere in the Internet and has an  
>> IPv6 address
>> 262       3ffe:503:c:1:EUI64.  When Host-A sends a packet to Host- 
>> C, the
>> 263       longest matching algorithm chooses 3ffe:1800:a:1:EUI64  
>> for the source
>> 264       address.  In this case, the packet goes through ISP1 and  
>> may be
>> 265       filtered by ISP1's ingress filter.  Even if the packet  
>> is fortunately
>> 266       not filtered by ISP1, a return packet from Host-C cannot  
>> possibly be
>> 267       delivered to Host-A because the return packet is  
>> destined for 3ffe:
>> 268       1800:a:1:EUI64, which is closed from the Internet.
>> 270       In this case, source-address-based routing alone  
>> described in the
>> 271       previous section does not solve the problem.  What is  
>> important is
>> 272       that each host chooses a correct source address for a given
>> 273       destination address as far as NAT does not exist in the  
>> IPv6 world.
>> 275    2.1.4.  Combined Use of Global and ULA
>> 277                            ============
>> 278                            | Internet |
>> 279                            ============
>> 280                                  |
>> 281                                  |
>> 282                             +----+----+
>> 283                             |   ISP   |
>> 284                             +----+----+
>> 285                                  |
>> 286                  2001:db8:a::/48 |
>> 287                             +----+----+
>> 288                             | Gateway |
>> 289                             +-+-----+-+
>> 290                               |     | 2001:db8:a:100::/64
>> 291              fd01:2:3:200:/64 |     | fd01:2:3:100:/64
>> 292                       -----+--+-   -+--+----
>> 293                            |           |
>> 294         fd01:2:3:200:EUI64 |           |      2001:db8:a: 
>> 100:EUI64
>> 295                       +----+----+    +-+----+ fd01:2:3:100:EUI64
>> 296                       | Printer |    | Host |
>> 297                       +---------+    +------+
>> 299                                    [Fig. 4]
>> 301       As NAP [I-D.ietf-v6ops-nap] describes, using ULA may be  
>> beneficial in
>> 302       some scenarios.  If ULA is used for internal  
>> communication, packets
>> 303       with ULA addresses need to be filtered at Gateway.
>> 305       There is no serious problem related to address selection  
>> in this
>> 306       case, thanks to the unlikeness of ULA and Global Unicast  
>> Address for
>> 307       now.  RFC 3484's longest matching rule chooses the  
>> correct address
>> 308       for both intra-site and extra-site communication.
>> 310       In a few years, however, the longest matching rule will  
>> not be able
>> 311       to choose the correct address anymore: the moment the  
>> assignment of
>> 312       those Global Unicast Addresses whose beginning bit is 1  
>> starts.  In
>> 313       RFC 4291 [RFC4291], almost all the space of IPv6,  
>> including those
>> 314       with beginning bit 1, is assigned as Global Unicast  
>> Addresses.
>> 316    2.1.5.  Site Renumbering
>> 318       RFC 4192 [RFC4192] describes a recommended procedure for  
>> renumbering
>> 319       a network from one prefix to another.  An auto- 
>> configured address has
>> 320       a lifetime, so by stopping advertisement of the old  
>> prefix it is
>> 321       eventually invalidated.
>> 323       However, it takes a long time to invalidate the old  
>> prefix.  You
>> 324       cannot stop routing to the old prefix as long as the old  
>> prefix is
>> 325       not deprecated.  This issue can be a tough issue for ISP  
>> network
>> 326       administrator.
>> 328                                  +-----+---+
>> 329                                  | Gateway |
>> 330                                  +----+----+
>> 331                                       |  2001:db8:b::/64  (new)
>> 332                                       |  2001:db8:a::/64 (old)
>> 333                             ------+---+----------
>> 334                                   |
>> 335                                +--+-----+ 2001:db8:b::EUI64   
>> (new)
>> 336                                | Host-A | 2001:db8:a::EUI64 (old)
>> 337                                +--------+
>> 339                                    [Fig. 5]
>> 341    2.1.6.  Multicast Source Address Selection
>> 343       This case is an example of Site-local or Global  
>> prioritization.  When
>> 344       you send a multicast packet across site-borders, the  
>> source address
>> 345       of the multicast packet must be a global scope address.   
>> The longest
>> 346       matching algorithm, however, selects a ULA address if  
>> the sending
>> 347       host has both a ULA and a global address.
>> 349    2.1.7.  Temporary Address Selection
>> 351       RFC 3041 [RFC3041] defines a Temporary Address.  The  
>> usage of
>> 352       Temporary Address has both pros and cons.  It is good  
>> for viewing
>> 353       web-pages or communicating with the general public, but  
>> it is bad for
>> 354       a service that uses address-based authentication and for  
>> logging
>> 355       purpose.
>> 357       It would be better if you could turn the temporary  
>> address on and
>> 358       off.  It would also be better if you could switch its  
>> usage per
>> 359       service(destination address).  The same situation can be  
>> found when
>> 360       using HA and CoA in MobileIP network.
>> 362    2.2.  Destination Address Selection
>> 364    2.2.1.  IPv4 or IPv6 prioritization
>> 366       The default policy table gives IPv6 addresses higher  
>> precedence than
>> 367       IPv4 addresses.  There seem to be many cases, however,  
>> where network
>> 368       administrators want to control the address selection  
>> policy of end-
>> 369       hosts the other way around.
>> 371                                +---------+
>> 372                                | Tunnel  |
>> 373                                | Service |
>> 374                                +--+---++-+
>> 375                                   |   ||
>> 376                                   |   ||
>> 377                            ===========||==
>> 378                            | Internet || |
>> 379                            ===========||==
>> 380                                 |     ||
>> 381                    192.0.2.0/24 |     ||
>> 382                            +----+-+   ||
>> 383                            | ISP  |   ||
>> 384                            +----+-+   ||
>> 385                                 |     ||
>> 386                   IPv4 (Native) |     || IPv6 (Tunnel)
>> 387                    192.0.2.0/26 |     ||
>> 388                                ++-----++-+
>> 389                                | Gateway |
>> 390                                +----+----+
>> 391                                     |  2001:db8:a:1::/64
>> 392                                     |  192.0.2.0/28
>> 393                                     |
>> 394                           ------+---+----------
>> 395                                 |
>> 396                               +-+----+ 2001:db8:a:1:EUI64
>> 397                               | Host | 192.0.2.2
>> 398                               +------+
>> 400                                    [Fig. 6]
>> 402       In the figure above, a site has native IPv4 and tunneled  
>> IPv6
>> 403       connectivity.  Therefore, the administrator may want to  
>> set a higher
>> 404       priority for using IPv4 than using IPv6 because the  
>> quality of the
>> 405       tunnel network seems to be worse than that of the native  
>> transport.
>> 407    2.2.2.  ULA and IPv4 dual-stack environment
>> 409       This is a special form of IPv4 and IPv6 prioritization.   
>> When an
>> 410       enterprise has IPv4 Internet connectivity but does not  
>> yet have IPv6
>> 411       Internet connectivity, and the enterprise wants to  
>> provide site-local
>> 412       IPv6 connectivity, ULA is the best choice for site-local  
>> IPv6
>> 413       connectivity.  Each employee host will have both an IPv4  
>> global or
>> 414       private address and a ULA.  Here, when this host tries  
>> to connect to
>> 415       Host-C that has registered both A and AAAA records in  
>> the DNS, the
>> 416       host will choose AAAA as the destination address and ULA  
>> for the
>> 417       source address.  This will clearly result in a  
>> connection failure.
>> 419                               +--------+
>> 420                               | Host-C | AAAA = 2001:db8::80
>> 421                               +-----+--+ A    = 192.47.163.1
>> 422                                     |
>> 423                            ============
>> 424                            | Internet |
>> 425                            ============
>> 426                                 |  no IPv6 connectivity
>> 427                            +----+----+
>> 428                            | Gateway |
>> 429                            +----+----+
>> 430                                 |
>> 431                                 | fd01:2:3::/48 (ULA)
>> 432                                 | 192.0.2.0/24
>> 433                                ++--------+
>> 434                                | Router  |
>> 435                                +----+----+
>> 436                                     |  fd01:2:3:4::/64 (ULA)
>> 437                                     |  192.0.2.240/28
>> 438                           ------+---+----------
>> 439                                 |
>> 440                               +-+----+ fd01:2:3:4::100 (ULA)
>> 441                               | Host | 192.0.2.245
>> 442                               +------+
>> 444                                    [Fig. 7]
>> 446    2.2.3.  ULA or Global Prioritization
>> 448       It is very common to differentiate services by the  
>> client's source
>> 449       address.  IP-address-based authentication is an extreme  
>> example of
>> 450       this.  Another typical example is a web service that has  
>> pages for
>> 451       the public and internal pages for employees or involved  
>> parties.  Yet
>> 452       another example is DNS zone splitting.
>> 454       However, ULA and IPv6 global address both have global  
>> scope, and RFC
>> 455       3484 default rules do not specify which address should  
>> be given
>> 456       priority.  This point makes IPv6 implementation of  
>> address-based
>> 457       service differentiation a bit harder.
>> 459                                +------+
>> 460                                | Host |
>> 461                                +-+--|-+
>> 462                                  |  |
>> 463                          ===========|==
>> 464                          | Internet | |
>> 465                          ===========|==
>> 466                                |    |
>> 467                                |    |
>> 468                           +----+-+  +-->+------+
>> 469                           | ISP  +------+  DNS | 2001:db8:a::80
>> 470                           +----+-+  +-->+------+  
>> fc12:3456:789a::80
>> 471                                |    |
>> 472                2001:db8:a::/48 |    |
>> 473            fc12:3456:789a::/48 |    |
>> 474                           +----+----|+
>> 475                           | Gateway ||
>> 476                           +---+-----|+
>> 477                               |     |    2001:db8:a:100::/64
>> 478                               |     |    fc12:3456:789a:100:/64
>> 479                             --+-+---|-----
>> 480                                 |   |
>> 481                               +-+---|+ 2001:db8:a:100:EUI64
>> 482                               | Host | fc12:3456:789a:100:EUI64
>> 483                               +------+
>> 485                                    [Fig. 7]
>> 487    3.  Solutions
>> 489    3.1.  More Specific Routes (RFC 4191)
>> 491       This method enables network administrator to distribute  
>> routing
>> 492       information to end-hosts.  It can solve only two  
>> problems in this
>> 493       document, that is 2.1.1, 2.2.2.  Routing information  
>> doesn't
>> 494       determine the source address when multiple addresses are  
>> attached to
>> 495       the outgoing network interface.  So, it cannot be used  
>> for every
>> 496       cases here.
>> 498    3.2.  Policy Table Manipulation
>> 500       Almost all the problem cases raised in this document can  
>> be solved by
>> 501       configuring the policy table at end-hosts.  The problem  
>> for a site-
>> 502       administrator is that he does not have the means to  
>> deliver policies
>> 503       to end-hosts.  Therefore, we proposed a method for policy
>> 504       distribution in the form of DHCPv6 option
>> 505       [I-D.fujisaki-dhc-addr-select-opt].  The usage of this  
>> mechanisim is
>> 506       illustrated in another I-D [I-D.arifumi-ipv6-policy-dist].
>> 508    3.3.  Revising RFC 3484
>> 510       Revising address selection rules defined in RFC 3484 in  
>> another idea.
>> 511       These problems are, however, too network-environment- 
>> specific, so
>> 512       it's not easy to have all-purpose rule set.
>> 514    4.  Conclusion
>> 516       We have covered problems related to destination or  
>> source address
>> 517       selection.  These problems have their roots in the  
>> situation where
>> 518       end-hosts have multiple IP addresses.  In this  
>> situation, every end-
>> 519       host must choose an appropriate destination and source  
>> address, which
>> 520       cannot be achieved only by routers.
>> 522       It should be noted that end-hosts must be informed about  
>> routing
>> 523       policies of their upstream networks for appropriate address
>> 524       selection.  A site administrator must consider every  
>> possible address
>> 525       false-selection problem and take countermeasures  
>> beforehand.
>> 527    5.  Security Considerations
>> 529       Address false-selection can lead to serious security  
>> problem, such as
>> 530       session hijack.  However, it should be noted that  
>> address selection
>> 531       is eventually up to end-hosts.  We have no means to  
>> enforce one
>> 532       specific address selection policy to every end-host.   
>> So, a network
>> 533       administrator has to take countermeasures for unexpected  
>> address
>> 534       selection.
>> 536    6.  IANA Considerations
>> 538       This document has no actions for IANA.
>> 540    7.  References
>> 542    7.1.  Normative References
>> 544       [RFC3484]  Draves, R., "Default Address Selection for  
>> Internet
>> 545                  Protocol version 6 (IPv6)", RFC 3484,  
>> February 2003.
>> 547       [RFC4193]  Hinden, R. and B. Haberman, "Unique Local  
>> IPv6 Unicast
>> 548                  Addresses", RFC 4193, October 2005.
>> 550    7.2.  Informative References
>> 552       [I-D.arifumi-ipv6-policy-dist]
>> 553                  Matsumoto, A., "Practical Usages of Address  
>> Selection
>> 554                  Policy Distribution", draft-arifumi-ipv6- 
>> policy-dist-01
>> 555                  (work in progress), June 2006.
>> 557       [I-D.fujisaki-dhc-addr-select-opt]
>> 558                  Fujisaki, T., "Distributing Default Address  
>> Selection
>> 559                  Policy using DHCPv6",
>> 560                  draft-fujisaki-dhc-addr-select-opt-02 (work  
>> in progress),
>> 561                  June 2006.
>> 563       [I-D.ietf-v6ops-nap]
>> 564                  Velde, G., "Network Architecture Protection  
>> for IPv6",
>> 565                  draft-ietf-v6ops-nap-04 (work in progress),  
>> October 2006.
>> 567       [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions  
>> for
>> 568                  Stateless Address Autoconfiguration in IPv6",  
>> RFC 3041,
>> 569                  January 2001.
>> 571       [RFC4191]  Draves, R. and D. Thaler, "Default Router  
>> Preferences and
>> 572                  More-Specific Routes", RFC 4191, November 2005.
>> 574       [RFC4192]  Baker, F., Lear, E., and R. Droms,  
>> "Procedures for
>> 575                  Renumbering an IPv6 Network without a Flag  
>> Day", RFC 4192,
>> 576                  September 2005.
>> 578       [RFC4291]  Hinden, R. and S. Deering, "IP Version 6  
>> Addressing
>> 579                  Architecture", RFC 4291, February 2006.
>> 581    Appendix A.  Appendix. Revision History
>> 583       01:
>> 584          Authors' addresses corrected.
>> 585          Solutions section added.
>> 586          Security Considerations section fully rewritten.
>> 587          Some editorial changes.
>> 589    Authors' Addresses
>> 591       Arifumi Matsumoto
>> 592       NTT PF Lab
>> 593       Midori-Cho 3-9-11
>> 594       Musashino-shi, Tokyo  180-8585
>> 595       Japan
>> 597       Phone: [phone]
>> 598       Email: [e-mail]
>> 600       Tomohiro Fujisaki
>> 601       NTT PF Lab
>> 602       Midori-Cho 3-9-11
>> 603       Musashino-shi, Tokyo  180-8585
>> 604       Japan
>> 606       Phone: [phone]
>> 607       Email: [e-mail]
>> 609       Ruri Hiromi
>> 610       Intec Netcore, Inc.
>> 611       Shinsuna 1-3-3
>> 612       Koto-ku, Tokyo  136-0075
>> 613       Japan
>> 615       Phone: [phone]
>> 616       Email: [e-mail]
>> 618       Ken-ichi Kanayama
>> 619       Intec Netcore, Inc.
>> 620       Shinsuna 1-3-3
>> 621       Koto-ku, Tokyo  136-0075
>> 622       Japan
>> 624       Phone: [phone]
>> 625       Email: [e-mail]
>> 627    Full Copyright Statement
>> 629       Copyright (C) The Internet Society (2006).
>> 631       This document is subject to the rights, licenses and  
>> restrictions
>> 632       contained in BCP 78, and except as set forth therein,  
>> the authors
>> 633       retain all their rights.
>> 635       This document and the information contained herein are  
>> provided on an
>> 636       "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/ 
>> SHE REPRESENTS
>> 637       OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND  
>> THE INTERNET
>> 638       ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS  
>> OR IMPLIED,
>> 639       INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE  
>> OF THE
>> 640       INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY  
>> IMPLIED
>> 641       WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A  
>> PARTICULAR PURPOSE.
>> 643    Intellectual Property
>> 645       The IETF takes no position regarding the validity or  
>> scope of any
>> 646       Intellectual Property Rights or other rights that might  
>> be claimed to
>> 647       pertain to the implementation or use of the technology  
>> described in
>> 648       this document or the extent to which any license under  
>> such rights
>> 649       might or might not be available; nor does it represent  
>> that it has
>> 650       made any independent effort to identify any such  
>> rights.  Information
>> 651       on the procedures with respect to rights in RFC  
>> documents can be
>> 652       found in BCP 78 and BCP 79.
>> 654       Copies of IPR disclosures made to the IETF Secretariat  
>> and any
>> 655       assurances of licenses to be made available, or the  
>> result of an
>> 656       attempt made to obtain a general license or permission  
>> for the use of
>> 657       such proprietary rights by implementers or users of this
>> 658       specification can be obtained from the IETF on-line IPR  
>> repository at
>> 659       http://www.ietf.org/ipr.
>> 661       The IETF invites any interested party to bring to its  
>> attention any
>> 662       copyrights, patents or patent applications, or other  
>> proprietary
>> 663       rights that may cover technology that may be required to  
>> implement
>> 664       this standard.  Please address the information to the  
>> IETF at
>> 665       [e-mail].
>> 667    Acknowledgment
>> 669       Funding for the RFC Editor function is provided by the IETF
>> 670       Administrative Support Activity (IASA).

_______________________________________________
Tools-discuss mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tools-discuss