Hi Jari, > > 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. > > > > => The problem is when you have 2 MRs, each advertising a different > > prefix (i.e. different home prefix). > > They are advertising a different prefix on the _ingress_ interface, > and the two MRs both use the _same_ ingress interface?
=> Correct. Is it the > same because it was configured to do so, as in somehow load- => "same" above refers to the link I guess. > balancing/fault-tolerant MR configuration? Or because their > ingress links happened to randomly merge, or the incapability > of the link layer to keep the two MRs on different links? => There are many different reasons. I sent a verly long email about this to nemo (monet back then). One simple scenario is that you might be walking around with a PAN that happens to have 2 MRs on a single link (e.g. a laptop and a mobile phone). The two MRs could share the same ingress link and have different egress links. For instance your laptop might have a WLAN card and your mobile might have a cellular interface. Once you walk into an airport lounge or starbucks you'll suddenly have a multihomed PAN. By definition, each MR must have a separate home prefix. So each will advertise a different prefix on the ingress side. Other uses my include redundancy (e.g. a train company providing WLAN access on the train). In this case two MRs may be used and they have to advertise different home prefixes. Of course you can imagine other scenarios but this is the basic idea. Hesham > > --Jari > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
