Skip to main content

Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules
RFC 5220

Yes

(Ron Bonica)

No Objection

Lars Eggert
(Dan Romascanu)
(David Ward)
(Lisa Dusseault)
(Ross Callon)
(Russ Housley)
(Tim Polk)

Note: This ballot was opened for revision 09 and is now closed.

Lars Eggert No Objection

(Ron Bonica; former steering group member) Yes

Yes ()

                            

(Chris Newman; former steering group member) No Objection

No Objection (2008-02-06)
Ron,

The document write-up on the ballot is structured oddly and
is missing the document quality section.  Please try to fix this.

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(David Ward; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) (was Discuss) No Objection

No Objection (2008-06-16)
Please run a spell check, e.g., "addtional".

Section 2.1.4 use fd0 and fd00. These are not the same thing. A typo, or an intentional difference?

In Setion 2.1.6 change:
  This case is an example of site-local or global prioritization
to:
  This case is an example of site-local or global unicast prioritization

Bob Hinden's review (remaining parts):

> 2.1.3.  Half-Closed Network Problem
>
>    You can see a second typical source address selection problem in a
>    multihome site with global-closed mixed connectivity like in the
>    figure below.  In this case, Host-A is in a multihomed network and
>    has two IPv6 addresses, one delegated from each of the upstream ISPs.
>    Note that ISP2 is a closed network and does not have connectivity to
>    the Internet.
>
>
>
> Matsumoto, et al.         Expires July 31, 2008                 [Page 5]
> Internet-Draft            Address Selection PS              January 2008
>
>
>                            +--------+
>                            | Host-C | 2001:db8:a000::1
>                            +-----+--+
>                                  |
>                         ==============  +--------+
>                         |  Internet  |  | Host-B | 2001:db8:8000::1
>                         ==============  +--------+
>                              |           |
>            2001:db8:1000:/36 |           | 2001:db8:8000::/36
>                         +----+-+   +-+---++
>                         | ISP1 |   | ISP2 | (Closed Network/VPN tunnel)
>                         +----+-+   +-+----+
>                              |       |
>            2001:db8:1000:/48 |       | 2001:db8:8000::/48
>                             ++-------++
>                             | Gateway |
>                             +----+----+
>                                  |  2001:db8:1000:1::/64
>                                  |  2001:db8:8000:1::/64
>                        ------+---+----------
>                              |
>                           +--+-----+ 2001:db8:1000:1::EUI64
>                           | Host-A | 2001:db8:8000:1::EUI64
>                           +--------+
>
>                                 [Fig. 3]
>
>    You do not need two physical network connections here.  The
>    connection from the Gateway to ISP2 can be a logical link over ISP1
>    and the Internet.
>
>    When Host-A starts the connection to Host-B in ISP2, the source
>    address of a packet that has been sent will be the one delegated from
>    ISP2, that is 2001:db8:8000:1::EUI64, because of rule 8 (longest
>    matching prefix) in RFC 3484.
>
>    Host-C is located somewhere on the Internet and has IPv6 address
>    2001:db8:a000::1.  When Host-A sends a packet to Host-C, the longest
>    matching algorithm chooses 2001:db8:8000:1::EUI64 for the source
>    address.  In this case, the packet goes through ISP1 and may be
>    filtered by ISP1's ingress filter.  Even if the packet is not
>    filtered by ISP1, a return packet from Host-C cannot possibly be
>    delivered to Host-A because the return packet is destined for 2001:
>    db8:8000:1::EUI64, which is closed from the Internet.
>
>    The important point is that each host chooses a correct source
>    address for a given destination address as long as NAT does not exist
>    in the IPv6 world.

While the above is true, it seems to me that the problem described is one of have a set of addresses with different reachability.  I don't think any address selection procedure will solve this class of problems with out additional information (either learned or configured) about the reachability of each prefix.  I think it would be better if the problem statement document discussed this.

(Lisa Dusseault; former steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Tim Polk; former steering group member) (was Discuss) No Objection

No Objection ()