Subject: RE: Scope ID secret Cabal (minutes)

From: Richard Draves <[email-masked]>
Date: Mon, 13 Dec 1999 22:03:38 -0800

> Sure. But I though the Mobile Ipv6 spec states that link local packets
> should/must not be tunneled to/from the mobile node when it is away
> from home.

Well, sure enough it does:

   However, packets addressed to the mobile node's link-local address
   MUST NOT be tunneled to the mobile node.  Instead, such a packet MUST
   be discarded, and the home agent SHOULD return an ICMP Destination
   Unreachable, Code 3, message to the packet's Source Address (unless
   this Source Address is a multicast address).  Packets addressed to
   the mobile node's site-local address SHOULD be tunneled to the mobile
   node by default, but this behavior MUST be configurable to disable
   it; currently, the exact definition and semantics of a "site" and a
   site-local address are undefined in IPv6, and this default behavior
   might change at some point in the future.

I think it could work; there are certainly tricky aspects but it is quite
similar to the site-local case.

Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 14 Dec 1999 09:40:43 -0800 (PST)

>    MUST NOT be tunneled to the mobile node.  [...]
> 

Yes, I think it could be made to work.
But that would raise some security issues as well as traffic issues.

For instance, if you tunnel the router advertisements (which are sent
to link-local addresses) does that mean
that the mobile host away from home should trust the unauthenticated 
router advertisement just because it has an encapsulating IP header?

The current scheme in the mobile ipv6 spec is to explicitly relay important
changes in router advertisements but those packets must be authenticated.

Also, folks have raised the issues that when away from home
you probably don't want to receive every link-local packet
(like the "beacon" router advertisements which are sent every second or so,
and presumably the random DAD packets etc) when you are far away on a 
potentially slow link. Instead the home agent will proxy for the mobile.

   Erik

---

From: Francis Dupont <[email-masked]>
Date: Thu, 16 Dec 1999 10:04:37 +0100

=> I don't believe it is reasonnable because this will make mobility and
ND interaction very hairy, for instance when the mobile comes back at home
it needs to send a home deregistration to the home agent which is a
neighbor but doesn't know this fact. In current specs the simplest way
to solve this issue is to send the home deregistration packet from a
link-local source with a CoA extension.

   
   
=> I agree, the issue is attacks can come from everywhere, not only from
a node connected directly on the link (ie. mobility can defeat the
protection from 255 hop limit and forwarding rules).

=> I think most of us would like to restrict link-local addresses to
special usages like ND and there is not proposal to add a trick in the API
in order to implement the draft-ietf-ipngwg-site-prefixes ideas for
link-locals then I can't see a good reason to change the current "MUST NOT"
in the mobility draft.

Thanks

[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Dec 1999 10:16:52 -0800 (PST)

> => I don't believe it is reasonnable because this will make mobility and

I don't think it is reasonable either for the security reasons if nothing
else.

   Erik