Chris, > Consider the topology below. See > https://www.ietf.org/mail-archive/web/rtgwg/current/msg05472.html for a more > detailed description of the topology. For H31 to send a packet to > destination B3, H31 must choose a source address from within subnet A3x.
[very nice ASCII art ruined by my stupid MUA] > For this example, we assume that the R1-R4 originate the following (D,S) > routes in the IGP. > R1 originates a route for (D=::/0, S=A1). > R2 originates a route for (D=B2, S=A2). > R3 originates routes for (D=::/0, S=A3) and (D=B3, S=A3). > R4 originates routes for (D=::/0, S=A4) and (D=B4, S=A4). > > R7 and R8 receive these routes via the IGP. With the existing mechanisms in > Neighbor Discovery Router Advertisements, R7 and R8 can advertise the > following PIOs and RIOs. > PIOs = A4x, A2x, A1x, A3x > RIOs = B2, B3, B4, B1 > > I have intentionally changed the order of the prefixes in the set of PIOs and > RIOs to emphasize that there is no required ordering or relationship between > prefixes in PIOs and RIOs. > > With only this information, I do not see how H31 can correctly choose a > source address in A3x when it needs to send a packet with destination address > B3. If this analysis is correct, then it seems like a mechanism like > draft-sarikaya-6man-sadr-ra-03 is needed. I take it B1, B2, B3 and B4 are walled gardens. What I think you are suggesting is that the host could use a S,D FIB for source address selection. At least type D hosts could. https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-01 RFC7078 is meant to solve this case though. Best regards, Ole
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
