Subject: Re: Multiple DRs on a link

From: Mohacsi Janos <[email-masked]>
Date: Wed, 10 Mar 2004 09:47:20 +0100 (CET)

On Tue, 9 Mar 2004, Mattias Pettersson wrote:

> 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.

I think this is not broken at all. The host should select the correct
prefix according to the source address selection rules. I tried this
scenario approximately 3 years ago on a KAME stack and it was working
correctly.

Best Regards,
	Janos Mohacsi

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Tim Chown <[email-masked]>
Date: Wed, 10 Mar 2004 13:46:03 +0000

On Wed, Mar 10, 2004 at 01:34:41PM +0000, Tim Chown wrote:
> 
> For the multihoming side, look at 
> http://www.ietf.org/internet-drafts/draft-huitema-multi6-hosts-03.txt
> where issues like in/egress filtering are discussed.

[Sorry - I just realised I answered part of your question with your 
 question :) but the discussion on multi6 on whether source address selection
 is enough is relevant if you haven't seen it...]

I agree the issue spans multiple WGs and it would be good to ensure that
there is agreement/convergence between thinking in those WGs (at least nemo,
multi6 and ipv6).

Tim

---

From: Mattias Pettersson <[email-masked]>
Date: Wed, 10 Mar 2004 16:09:49 +0100

Hi Janos,

> scenario approximately 3 years ago on a KAME stack and it was working

But what source address selection rules do you refer to? I saw Alper's
response and I'm happy he pointed it out because I haven't been aware of
it, but the wording there is really weak.

Other than that I don't understand what rules in 3484 help here. I got
rather familiar with the KAME stack during 1999-2001 and to my knowledge
the default router selection is made once and the host sticks to that
router as long as it is considered reachable. What source address being
used doesn't matter to what next-hop is used.

/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.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Mar 2004 08:51:28 +0200

> there is agreement/convergence between thinking in those WGs (at least nemo,

Right. In addition, the SEND WG had an issue about this as well, when
they debated the semantics of prefixes in router certificates. (They
decided to stick with the IPv6 RA semantics. That is, SEND hopes
someone else, maybe multi6, will make it clearer what the rules are.)

I have also seen the RFC 3484 rules, and I agree with others that
they are somewhat vague. In any case, multi6 is already discussing
this so eventually there will be a spec that will guide us. However,
in any case when there are multiple routers with different prefixes
on the same link, currently implemented IPv6 hosts may make the
wrong decision. Certainly at least those nodes that predate RFC 3484.

But I have a question about the NEMO case. I had assumed that mobile
routers move around and attach their egress interface to various
place in the internet. And that their ingress interface serves
a number of hosts, unaware of the movements. I don't see the
default router selection as an issue in this scenario, as the
hosts will stick to the same mobile router all the time, and
the mobile router acts like a host on its egress interface. So
if the visited link works for hosts, it should work for mobile
routers.

But perhaps you are considering a situation where the ingress
interface of two mobile routers may be shared, or that a mobile
router's ingress interface may suddenly appear on some stationary
network. If we allow this, there could be problems. Do we really
need it?

--Jari

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 11 Mar 2004 16:27:58 -0800 (PST)

> There is some relevant text in RFC 3484:
>
>    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.

As others have said the above language is really weak.
But even if the language was a MUST and it was universally implemented I don't
think it would help; other issues would have to be resolved.

For instance, what should the host do when it suspects that the 1st hop
router is down? (e.g. due to NUD failing)
In the model that all routers on the link are assumed equal, the host,
as is specified in RFC 2461, can switch to using a different 1st hop router.
But in what I would call the source based routing model (where the
source address determines which 1st hop router is used), switching
to a different 1st hop router might be a bad idea (ingress filtering above
that router might discard all such packets); continuing to send
packets to the 1st hop router that advertised the prefix might actually
be better - in case the router receives the packets they will make it
to the destination.

Thus I thing there is a rather large architectural question lurking in
this issue.

*If* we want to pursue this path at a minimum the host needs to know
whether using the original 1st hop router is better or not.
One way to do this is to require that routers on the same link
must advertise the same set of prefixes (and make the router advertisement
consistency in RFC 2461 check this?).
If we did that then the hosts could assume that when different routers
advertise different sets, the routers are not managed by the same
entity and the host should use a 1st hop router that is consistent with
the source address. But the host could switch 1st hop routers among the
set of routers that advertise the same set of prefixes.

I don't know whether we could make the operational requirement that the routers
on the same link (that don't want source-based routing) must advertise the
same set of prefixes stick. Depends on what the current operational practices
I guess.

  Erik

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 15 Mar 2004 00:01:24 +0900

>>>>> On Wed, 10 Mar 2004 16:09:49 +0100, 
>>>>> Mattias Pettersson <[email-masked]> said:

> used doesn't matter to what next-hop is used.

Just to clarify a few things about a particular implementation,

KAME implemented most part of RFC3484 (in 2001), but does not support
the capability cited in this thread.

As far as I can see, the source address selection algorithm (based on
RFC3484) implemented in KAME can only solve some part of the problem.
For example, if longest matching against the destination address
suggests the correct source address, it will work fine.  In general,
however, the implementation can choose an undesirable source address
that can be filtered in an ISP (or can cause other unpleasant
problems).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Alper Yegin <[email-masked]>
Date: Tue, 09 Mar 2004 23:04:16 -0800

7. Interactions with Routing

...

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mattias Pettersson
> Sent: Tuesday, March 09, 2004 12:06 PM
> To: [email-masked]
> Subject: Multiple DRs on a link
> 
> Hi,
> 
> 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.
> 
>

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 09 Mar 2004 21:05:53 +0100

Hi,

   ISP A        ISP B
     \            /
     Ra          Rb
      |           |
     -+-----+-----+-
            |
            H

- sends it to Ra:

/Mattias

---

From: Tim Chown <[email-masked]>
Date: Wed, 10 Mar 2004 13:34:41 +0000

> scenario approximately 3 years ago on a KAME stack and it was working

While mobile routers on a (wireless) link are one example of this scenario,
a multihomed link or a renumbering link are others, whether there is one
router or two the host still needs to make the RFC3484 decisions.

There has also been a long thread on source address selection on the multi6
WG list recently, which you could read back through.

Tim