Hi James, > -----Original Message----- > From: Int-area [mailto:[email protected]] On Behalf Of james woodyatt > Sent: Tuesday, January 17, 2017 5:19 PM > To: 6man WG <[email protected]>; INT Area <[email protected]> > Subject: Re: [Int-area] Route Information Options in Redirect Messages > > On Jan 9, 2017, at 11:53, Templin, Fred L <[email protected]> wrote: > > On Monday, January 09, 2017 11:02 AM, james woodyatt <[email protected]> > > wrote: > >> > >> p2. Section 3.3, Host Specification says this: > >> > >>>> In light of these considerations, a "Type C" host that receives a > >>>> Redirect message containing RIOs adopts the combined behaviors of > >>>> both of these specifications. Namely, the host updates its neighbor > >>>> cache entry for the Target and updates its routing table per the > >>>> included RIOs. If the Destination address is not the unspecified > >>>> address, the host further updates its destination cache. > >>>> > >>>> Note that "Type A'" and "Type B" hosts ignore any RIOs and process > >>>> the Redirect message according to Section 8.3 of [RFC4861]. > >> > >> And I wonder if you have considered the possibility of a “Type D” host, > >> which in my conception would be capable of *only* > processing > >> RIO options that appear in ND Redirect messages and *not* in RA messages. > > > > Had not considered that, but I don't see a problem with it. FWIW, the 'Type > > A/B/C' comes from RFC4191 in case others are > wondering. > > > >> I’m not sure that’s a type of host we want to encourage, > >> but the idea of its possibility was one of the first things that sprang to > >> mind when I contemplated the reasons why so few Type C > hosts > >> are currently deployed in the wild after more than a decade since RFC 4191 > >> was published. > > > > I am interested in usage inside of a managed network, and not so much about > > deployment in the wild. Inside of a managed network, the network > > administrators > > could enable this function among the deployed hosts to provide the network > > with > > a means to manage routing information for more-specific routes. > > Yes, well, as you might imagine, I’m interested in behavior of commodity > hosts on unmanaged networks.
OK, no problem. I agree this document should keep an open mind in terms of potential use cases. > As far as I know, the most common types of commodity host implementations are > Type B at this point. Yes, I know at least one has a > configurable option to enable Type C behavior, but Type B is the default, and > it’s also rarely changed in managed host configurations > for mobile workstations and personal devices. > > I believe host implementations have not adopted Type C default behavior > because of security concerns on unmanaged networks like > public Wi-Fi hotspots, where the damage potentially caused by so-called > “rogue routers” is already perceived to be unacceptably high. > The theory being that adding support for processing RIO options would further > lower the network costs of mounting such attacks, in > exchange for a questionably valuable route optimization from hosts to > possibly illegitimate routers. I’m not a big fan of this line of > reasoning, but I’ve often seen it used to counter arguments that adding > default Type C behavior would be a good idea. For RIOs in RA messages, I don't think this would result in a route optimization. In that case, the RA messages simply provide more-specific routes. But, the next hop will always be the router that sent the RA, i.e., and not a different router. > A better argument against RIO options in RA Messages, as far as I’m > concerned, is that RA Guard [RFC6105] functions are often > deployed in L2 switching fabrics, and they’ll drop all the RA Messages from > most routers other than the protected default routers, > which are likely to be the ones advertising more specific routes. With ND > Redirect Messages, network operators can still have a > reasonable assurance that hosts never update their routing tables except at > the initiation of one of the legitimate default routers, > which are protected by RA Guard. > > In light of that, I would suggest defining two new types of behavior, which > would permit implementers to continue resisting the > adoption of Type C by default, yet would allow them to add support for > processing RIO options just in ND Redirect messages and not > RA messages. Call that a Type D host, and call the functional combination > Type C+D or something. OK, that makes sense to me. > Here is my proposed text for Section 3.3 Host Specification. > > >>> The Host Specification follows Section 8.3 of Neighbor Discovery for IP > >>> version 6 (IPv6) [RFC4861], Section 3 of Default Router > Preferences and More-Specific Routes [RFC4191], and Section 3 of First-Hop > Router Selection by Hosts in a Multi-Prefix Network > [RFC8028]. According to [RFC4861], a host that receives a valid ND Redirect > message updates its destination cache per the Destination > information and its neighbor cache per the Target information. According to > [RFC4191], a “Type C” host that receives a valid RA > message updates its routing table per the RIO elements included in the > message. Finally, according to [RFC8028], a “Type C” host > operating on a Multi-Prefix Network with multiple default routes can make > source address selection decisions based on information in > its route table decorated with information derived from the source of the RIO > element. All sounds good, but use of the word "decorated" seems strange in this context. I don't have a better suggestion at the moment, though. > >>> In light of these considerations, this document introduces a new “Type D” > >>> behavior for hosts with the same kind of routing table > as a “Type C” host, but which processes RIO elements in ND Redirect Messages > according to this specification instead of RA Messages > as in RFC 4191. Hosts that process RIO elements in both RA messages and ND > Redirect Messages are said to have “Type C+D” > behavior. Sounds good. > >>> In both the “Type D” and “Type C+D” cases, hosts process ND Redirect > >>> Messages by updating 1) their neighbor cache per the > Target information, 2) their destination cache per the Destination > information when the Destination Address field is not the > unspecified address, and 3) their routing tables per any RIO elements present. Sounds good. > >>> RIO elements in RA Messages are processed by “Type D” hosts in the same > >>> way that “Type B” hosts process them, i.e. by ignoring > them. In “Type C+D” hosts, RIO elements in RA messages are processed in the > same way that “Type C” hosts process them. > >>> > >>> In the all the cases where hosts process RIO elements, i.e. in RA > >>> Messages or in ND Redirect Messages or in both, hosts MAY > make source address selection decisions, as in [RFC8028], based on their > route tables decorated with information derived from the > sources of received RIO elements. > >>> > >>> The behaviors of “Type A,” “Type B” and “Type C” hosts are not changed by > >>> this specification. In particular, they all process ND > Redirect Messages according to Section 8.3 of [RFC4861]. This all sounds good. How would you feel about having this text show up in the next draft version (and be included as a co-author)? Second question - should the next draft version be called: "*-intarea*" or "*-6man*"? I am leaning toward the latter because the interest seems to be coming from this WG. Thanks - Fred [email protected] > --james woodyatt <[email protected]> > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
