Subject: [mobile-ip] Mipv6 issue #162: Site-locals & Mipv6

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Nov 2002 23:27:02 +0200

It seems like we can develop a site-local for disconnected domains,
but the details are consuming time and we seem to hit complications
every time we come up with a text that we initially believed to be
right. Hence, I'd like to take the management viewpoint here and
propose that we deal with site-locals only in the absolute minimal
manner in the base specification. (Note that future documents might
provide extended information about the use of site-locals.) This
approach also seems wise given the unclarity around the direction
of the site-local addresses in the IPv6 WG.

Still with me? Here's what I'd like to do in more detail:

1) Say that site-local addresses SHOULD NOT be used as home
    or care-of addresses.

2) List a number of issues that may result when site-locals are
    used against the above advice. Indicate that site-local addresses
    may be usable on disconnected sites, but that this specification
    does not guarantee such usage is free of problems.

3) In Section 11.3.1 we still need to have some updated text
    about site-local and link-local addresses. Basically, we
    need to avoid the use of the home address when communicating
    with anything else than a global address. This is because
    we can't guarantee that the link-local or the site-local addresses
    of a visited link have any meaning to our home site.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 27 Nov 2002 09:25:34 +0200

Text proposal:

1) Keep the current "unicast routable address" term and
    the MUST conditions about addresses in BUs, HAOs, RHs,
    etc having to be such addresses.

    We could also replace the term with simply global
    unicast address; but then we'd be disabling site-local
    usage for sure, when the intention was to just make it
    a SHOULD NOT.

2) Replace contents of Section 4.6. Site-Local Addressability
    with the following text:

      This specification requires that home and care-of addresses
      MUST be unicast routable addresses. Site-local addresses
      may be usable on networks that are not connected to the
      Internet, but this specification does not define when
      such usage is safe and when not. Mobile nodes may not be
      aware of which site they are currently on, it is hard to
      prevent accidental attachment to other sites, and ambiguity
      of site-local addresses can cause problems the home and
      visited networks use the same addresses. Therefore, site-local
      addresses SHOULD NOT be used as home or care-of addresses.

3) In Section 11.3.1 replace the current site-local special
    case text with the following new text:

      While not at its home link, the mobile node MUST NOT use the
      home address destination option when communicating
      with link-local or site-local peers, if the scope of the home
      address is larger than the scope of the peer's address.

    The rationale for this is that a link-local/site-local address
    might not be routable from the home network, and the use of
    the home address requires always routing from the home address
    to the peer in question when the binding was established through RR.

    If the home address is a site-local address against our earlier
    SHOULD NOT, this rule still allows mobile nodes to communicate
    with all peers, because of the "larger scope" condition above.
    If the home address is a global address, then we simply avoid
    its usage for any site-local or link-local peer. Still, if we
    use a link-local or site-local topologically correct address
    we can communicate with anyone.

Jari

---

From: Michael Thomas <[email-masked]>
Date: Wed, 27 Nov 2002 02:57:11 -0800 (PST)

>     usage for sure, when the intention was to just make it

Given the clear lack of consensus in NG, would
that be such a bad thing? It would be pretty
awkward if the final outcome of NG contradicted
MIPv6. Issue avoidance is probably our friend.

	     Mike

---

From: Jari Arkko <[email-masked]>
Date: Wed, 27 Nov 2002 13:08:24 +0200

> MIPv6. Issue avoidance is probably our friend.

No, it would not be that bad either. I guess its a judgement call
whether to use SHOULD NOT or MUST NOT. I'm willing to accept
either one, but initially I felt that the the definition of SHOULD
NOT is the most suitable here: we don't need to prohibit this for
interoperability reasons, there are good reasons why it shouldn't
be done but folks who really know what they are doing could still
go ahead past the warning sign ;-)

Jari

---

From: Michael Thomas <[email-masked]>
Date: Wed, 27 Nov 2002 08:05:16 -0800 (PST)

> go ahead past the warning sign ;-)

I guess what I was after is whether it could be
finessed to just sort of avoid direct mention. If
it's felt that an explict mention is needed, I'm
OK with either strength.

	Mike