Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules
RFC 5220
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
Lars Eggert No Objection
(Ron Bonica; former steering group member) Yes
(Chris Newman; former steering group member) No Objection
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
(David Ward; former steering group member) No Objection
(Jari Arkko; former steering group member) (was Discuss) No Objection
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
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Tim Polk; former steering group member) (was Discuss) No Objection