There is some relevant text in RFC 3484: 7. Interactions with Routing
... Implementations may also use the choice of router to influence the choice of source address. For example, suppose a host is on a link with two routers. One router is advertising a global prefix A and the other router is advertising global prefix B. Then when sending via the first router, the host may prefer source addresses with prefix A and when sending via the second router, prefer source addresses with prefix B. This provides guidance in the right direction, but I'm not sure if it is sufficient, or ever implemented. Alper > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Mattias Pettersson > Sent: Tuesday, March 09, 2004 12:06 PM > To: [EMAIL PROTECTED] > Subject: Multiple DRs on a link > > Hi, > > [This issue spans some WGs but it originates from here I believe.] > > We've had a small discussion in NEMO about multiple default routers on a > link, and whether these DRs are allowed to advertise different prefix > sets or not. > > Think of this small network: > > > ISP A ISP B > \ / > Ra Rb > | | > -+-----+-----+- > | > H > > Further assume that Ra advertises prefix Pa and Rb advertises prefix Pb. > Host H will have two DRs, hear two prefixes and build addresses out of > the both. > > What I'm asking for is whether this scenario was ever considered > "broken" unless there is some form of coordination between Ra and Rb. I > seem to recall that there was a discussion on ipng/IPv6 on exactly this > long ago but on the other hand I can't find it. > > The reason for calling this scenario broken is that H must be careful > with what source address to use when sending to either default router > (and that is a requirement we can't put on a legacy IPv6 host). One can > assume that both ISPs perform ingress filtering. If H contructs a packet > with a source address Sa from Pa and: > > - sends it to Ra: > - the packet will be routed successfully > > - but if it was to send it to Rb instead: > - (1) ISP B would drop it due to ingress filtering, or > - (2) Rb would have to forward it to Ra, or > - (3) Rb would have to tunnel it to ISP A, or > - (4) Rb would have to send a redirect to H, or > - (5) Rb or ISP B would generate an ICMP error about bad source address > > Alternatives 2-5 are typically described in draft-huitema-multi6-hosts, > but they either: > - require some form of coordination between the routers and their > ISPs, or they > - require that the host H implement some additional mapping between > prefixes/source addresses and default routers. > > To H there is no difference between Ra and Rb. Both claim that they are > default routers. Now both should be able to forward any traffic from H. > But unless Ra and Rb are coordinated in some of the ways described above > or that host H implement _new_ requirements in > draft-huitema-multi6-hosts (which standard IPv6 hosts do not), then host > H will have to take a chance on what default router to use (last heard? > first heard?). If H happened to select Ra as default router, packets > with source Sa will go through, but no packets with source Sb. And > default router selection will not happen again until Ra becomes > unreachable. > > So the question is: am I correct to regard this scenario as broken and > say it should not be encouraged? I also think that nobody plans to build > fixed networks like this, just for these reasons. However, people may > want to build NEMO-type of networks just like this, as it is convenient > when mobile routers are rather independent, they come and go, and each > connects to one ISP and each only advertises a prefix from its ISP. > Awkwardly, then it is more important than ever that the mobile routers > are cooperating otherwise legacy IPv6 hosts won't be able to get plain > connectivity. > > /Mattias > > > > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution is > prohibited. If you believe this message has been sent to you in error, > please notify the sender by replying to this transmission and delete the > message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any such > corruption, interception, amendment, tampering or viruses or any > consequences thereof. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
