This issue was raised in v6ops, that on comments from Thomas seem better suited for v6man.
Copied here to continue discussion. > From: David Miles <[EMAIL PROTECTED]> > Date: 25 June 2008 10:04:25 AM > To: Thomas Narten <[EMAIL PROTECTED]>, IETF V6OPS WG <[EMAIL PROTECTED] > > > Subject: Re: Neighbor Discovery and on-link determination > > Thanks Thomas, > > I'll move this into v6man if that is the case (and to ensure > everyone is across it). > > So in summary, the definition of on-link is where the uncertainty > arose, because the current definition is: > on-link - an address that is assigned to an interface on a specified > link. A node considers an address to be on- link if: > - it is covered by one of the link's prefixes (e.g., as indicated by > the on-link flag in the Prefix Information option), or > - a neighboring router specifies the address as the target of a > Redirect message, or > - a Neighbor Advertisement message is received for the (target) > address, or > - any Neighbor Discovery message is received from the address. > > > It sounds as though we should remove the last two conditions? > > I'd also suggest that in the Message Validation section we include > the checks you mention (is the source of the ND or target of the NA > an on-link prefix per Prefix List) > > Best Regards, > > -David > > On 25/06/2008, at 1:36 AM, Thomas Narten wrote: > >> David Miles <[EMAIL PROTECTED]> writes: >> >>> I have seen an unusual scenario which I was wanting to run past >>> people to >>> comment on: >> >>> I have routerA and routerB connected to each other via Ethernet. >> >>> RouterA has the following addresses on the interface to RouterB: >>> 2000:100::2/64 >>> 3000:100::2/64 >>> With a default route to 2000:100::1 >> >>> RouterB has the following addresses on the interface to RouterA: >>> 2000:100::1/64 >>> With a route for 3000:100::/64 to 2000:100::2 >> >>> Per RFC4861, RouterA is sending ND as follows (assume it wants to >>> src traffic from 3000:100::2 to a off-link address): >>> 3000:1::2 -> FF02::1:FF00:1 >>> Type: Neighbor Solicitation (135) >>> Code: No Code (0) >>> Tgt Addr: 2000:100::1 >>> Option : Src Link Layer Addr 00:00:00:00:00:01 >> >>> As 7.2.2 says "if the source address of the packet prompting the >>> solicitation is the same as one of the addresses assigned to the >>> outgoing >>> interface, that address SHOULD be placed in the IP Source Address >>> of the >>> outgoing solicitation." >> >>> When RouterB will receive the ND as it is sent to the solicited- >>> node MC >>> address and will check the target address is valid (matches an >>> addresss >>> assigned to the receiving interface). >>> RouterB should then create a Neighbour Cache entry and set its >>> state to >>> STALE using the link-layer address in the ND. It should then send a >>> solicited neighbor advertisement. >> >>> This means that the RouterB will have a single address 3000:1::2 >>> in its >>> Neighbour Cache, but the route will direct traffic to 2000:200::2. >>> Obviously the Neighbour Cache would now contain an entry for an >>> address >>> that does not (appear) to be on-link from a route-table perspective. >> >> Hmm. This would appear to be a bug. >> >> I do not believe it was the intention to have any addresses that >> appear as the source of an NS result in a recipient of the NS >> concluding that the source address is on-link. >> >> That said, if you follow the words in the spec (with the "conceptual >> algorithms"), the result would appear to be a bogus entry in the >> Neighbor Cache, but one that would not get used. I.e., when sending >> to >> that destination, RouterB would first look in its Destination Cache, >> find no entry and then do next-hop determination (i.e., by looking at >> the on-link information. It would NOT look in the Neighbor Cache at >> this point, it only does that after determining if the destination is >> on-link. >> >> In any case, I would have expected that before creating a Neighbor >> Cache Entry for the source address mentioned above, the receiver >> should first verify that the address would be considered on-link per >> the standard checks. >> >>> How should Neighbour Cache and route table interact on a routerB? >>> I had >>> always assumed route table replaces Prefix List on a router, but >>> that >>> would mean Neighbour Cache would always be consulted with the next- >>> hop of >>> the static route (following the sending algorithm in RFC 4861). >> >> That may be the common implementation, but that is not what the >> conceptual sending alogrithm says should happen. >> >>> This seems to directly relate to the definition of on-link as being: >>> - an address covered by on of the link's prefixes, or >>> - an address in the target of a rediect, or >> >> yes >> >>> - an address in the target of a neigbour advertisement, or >> >> There is no definition that I know if that would allow you to draw >> this conclusion. All one can conclude is that the sender of the NS >> believes the target is on-link. They may be right, but they may also >> be wrong. >> >>> - an address in the source of a neighbour discovery message >> >> No, per above. >> >>> Should a router really consider an address on-link just because it >>> received a ND - I can see many potential security concerns if that >>> is the >>> case. >> >> I think not, with security concerns being one reason why not. >> >>> Any clarifications or experiance appreciated. >> >> Good catch! >> >> Thomas >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
