Chris, > So here is my summary of the situation. > > 1) If DHCPv6 with extensions in RFC7078 is used to help the host to select > the correct source address, then we could handle even walled garden use cases > with default-only SADR. See details for how this works in > http://www.ietf.org/mail-archive/web/rtgwg/current/msg05472.html . Another > assumption would be that DHCP relay could be used so we wouldn't need the > (D!=::/0 , S) routes in to reach R7 and R8. > > 2) However, if we don't use DHCPv6 with RFC7078 for host source address > selection, then Neighbor Discover Router Advertisements need to be extended > using a new mechanism like draft-sarikaya-6man-sadr-ra-03 or > draft-pfister-6man-sadr-ra-01. In this case, default-only SADR is not > sufficient to support walled gardens because we are relying on the (D!=::/0 , > S) routes to be carried in the IGP so that R7 and R8 can then put the > (D!=::/0 , S) information into the new ND Router Advertisements. > > Is this more or less accurate?
Yes, that's reasonably accurate. Although of course not the full picture since we have decades of innovation in this space. - You also have ICMPv6 Destination Unreachable, Source address failed ingress/egress policy that could be used as a trigger by the host to try a different source, independent of what the network signals. - Or MP-TCP which presumably would also try some subset of all combinations. - Or draft-baker-happier-eyeballs-00 which throws spaghetti on the wall to see what sticks. Cheers, Ole > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Tuesday, April 12, 2016 2:37 PM > To: Chris Bowers <[email protected]> > Cc: David Lamparter <[email protected]>; [email protected] > Subject: Re: Implications of default-only SADR (was: Re: multi-homing for > provider-assigned IPv6 addresses) > > 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
