Subject: poposed changes to the scoping architecture draft

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 20 Mar 2002 06:42:05 +0900

We have some updates on the draft
draft-ietf-ipngwg-scoping-arch-03.txt, on which I will make a short
presentation in the Thursday ipv6 wg meeting.

Since we missed the deadline to publish a new ID and since I'm not
sure if I will have an enough slot for the presentation, please let me
post a digest of the changes.  Comments to this message are, of
course, welcome.

There are two changes, both of which were based on inputs after the 03
draft:

1. revise the mobility section to clarify issues about using
   site-local addresses with mobile IPv6:
  + site-local home/care-of addresses can be used when the mobile node
    moves within its home site and communicate with nodes within the site.
  + in general, however, there are several issues.  For example, if
    the care-of address is a site-local address, an off-site mobile
    node cannot communicate with the home agent to register the care-of
    address.  Also, if the home address is a site-local address
    (without route optimization) and a correspondent node (CN) is in a
    different site from the mobile node's home site, the CN cannot send
    packets back to the mobile node unless it can use route
    optimization.
  + to deal with such issues, we'll need an ability for mobile nodes
    to tell whether a correspondent node or the home agent is in the
    same site as the mobile node.  However, there is currently no
    standard way to implement the ability.
  + thus, we recommend to use global home/care-of addresses *whenever
    possible*.  (note, however, this does not mean we prohibit mobile
    nodes from using site-local home/care-of addresses.)

2. revise the textual representation section 
  in the form of <address>%<zone_id>, the <zone_id> part is now
  formatted as follows:
      <scope_type>.<id_in_the_scope>
  where <scope_type> is a decimal number from 0 to 15 to specify a
  scope type, which corresponds to the "scop" field values of multicast
  addresses, and <id_in_the_scope> is a decimal number to identify a
  zone.  "." is a delimiter character to separate <scope_type> from
  <id_in_the_scope>.
  (the reason for the delimiter character "." is because it is used in
   the "normal" address representation so address parser should escape
   the character.  And, "." is more intuitive and more readable than
   other characters (i.e. ":", "a-f0-9").)

  An example: a site-local address fec0::1 on the #2 site can
  represented as fec0::1%5.2 (where 5 means the site scope and 2 means
  the 2nd site)

  The previous "readable" representation like "link2" or "site10" were
  removed accordingly.  The "unreadable" numerical representation like
  1342177281 (= 0x50000001) were also removed.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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: Markku Savela <[email-masked]>
Date: Tue, 19 Mar 2002 23:59:01 +0200

Some quick tiny comments...

> From: JINMEI Tatuya / 神明達哉 <[email-masked]>

>   represented as fec0::1%5.2 (where 5 means the site scope and 2 means

But "fec0::1%2" is exactly same, the site scope (5) is implicit from
the address?

Can you give an example of case where the scope is not associated with
address? If there is such case, then explicit <scope_type> is useful,
but otherwise always unnecessary?

Or, this allows then to write "fec0::1%2.2". Is this intended to be
allowed or flagged as an error?

Btw. what is the scope level of address "::"?  = 0?

---

From: Francis Dupont <[email-masked]>
Date: Tue, 19 Mar 2002 23:21:27 +0100

In your previous mail you wrote:

=> I disagree with your solution because it takes more than a few line
to describe it (:-).
IMHO site-local addresses in a mobile IPv6 work well if only a
bidirectional tunnel is used between the mobile and its home agent.
Note there should be no penalty because by definition communications
in the same site are local, so the only difference with routing
optimization is the encapsulaion overhead.
Another important point is an equivalent way to describe this solution
is to say the bidirectional tunnel belongs to the home site.

       possible*.

=> I agree because this avoids to have a bi-sited node.
(no further comment about multi-site support in some IPv6 stacks :-).

=> I agree if you still allow names (not ambiguous and mapped to
the pair type/id in a local config file).
   
Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Tue, 19 Mar 2002 23:39:15 +0100

=> it is in all zones so IMHO its scope level is global.
But for its use it must not go through routers so it is link-local.
Note :: is valid only as a source on the wire (*) even if the
source address selection draft is not sound (again) about this topic,
and is always used with a link-local multicast destination.
(*) many kernels map unspecfied destination to an address of the
local node.

Regards

---

From: Ole Troan <[email-masked]>
Date: Tue, 19 Mar 2002 23:23:58 +0000

[...]

>   represented as fec0::1%5.2 (where 5 means the site scope and 2 means

what is the reasoning behind this change? I certainly hope you still
allow for the original <address>%<zone_id> where <zone_id> is one of
number, name or interface.

while we're at it, I would suggest we change the prefix representation
to: <prefix>%<zone_id> e.g fec0:0:0:1::/64%site2 which allows the use
of '/' within the zone_id.

>   1342177281 (= 0x50000001) were also removed.

good. how an implementation represents a zone with a numerical
representation should be implementation specific. should suffice with
a sentence saying that zones can be represented numerically.

/ot

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 20 Mar 2002 09:14:12 +0900

>>>>> On Tue, 19 Mar 2002 23:21:27 +0100, 
>>>>> Francis Dupont <[email-masked]> said:

> is to say the bidirectional tunnel belongs to the home site.

Okay, we'll need some consideration about bidirectional tunneling.

> the pair type/id in a local config file).

We'll still allow (implementation-dependent) names, just like before.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 20 Mar 2002 13:54:38 +0900

>>>>> On Tue, 19 Mar 2002 23:23:58 +0000, 
>>>>> Ole Troan <[email-masked]> said:

> number, name or interface.

I intended to introduce the new format as a replacement of the
previous "readable" format like "site2".  Implementation dependent
zone "names" (including interface names) are still allowed.

As for "numbers", I'm not sure if it makes sense to keep them.  Since
the consensus is zone IDs must contain scope type in its
representation, the form of <scope_type>.<zone_ID> is a kind of
"numeric" representation.  Of course, the internal encoding of the
representation can be a single integer, but it might just be
complicated like 1342177281 (= 0x50000001) because it should contain
both the scope type and the zone ID.  Do we still need the (possibly
complicated) "raw" numbers in the textual representation?

> of '/' within the zone_id.

The motivation of the ordering is described in the 03 draft:

   In this combination, it is important to place the zone index portion 
   before the prefix length, when we consider parsing the format by a 
   name-to-address library function [BASICAPI].  That is, we can first 
   separate the address with the zone index from the prefix length, and 
   just pass the former to the library function. 

Though the API issue might not apply to all platforms, I believe it is
still reasonable enough.

> a sentence saying that zones can be represented numerically.

Okay, if the consensus is to keep the "raw" numeric numbers in the
textual representation, we'll revise the text in a more generic
manner.  (currently I'm planning just to remove this part.)

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 20 Mar 2002 14:04:09 +0900

>>>>> On Tue, 19 Mar 2002 23:59:01 +0200, 
>>>>> Markku Savela <[email-masked]> said:

> But "fec0::1%2" is exactly same, the site scope (5) is implicit from

Yes.

> but otherwise always unnecessary?

As described in the 03 draft, one possibility is a kind of MIB entry
which only specifies a particular zone (of a particular scope type).
Such a possibility is one of the reasons to adopt this type of format
since the 03 version.

> allowed or flagged as an error?

This should be treated as an error, as described in the 03 draft.

> Btw. what is the scope level of address "::"?  = 0?

Hmm, good question.  I personally think "::" can be treated as a
global scope with regards to the scope architecture, because it does
not cause ambiguity about the "zone".  And, in fact, our current
implementation treats "::" as a global address for convenience, and it
works without anomaly.

Can we agree on this?  Then we'll clarify this point in the next
revision of the draft.

					JINMEI, Tatuya

---

From: Markku Savela <[email-masked]>
Date: Wed, 20 Mar 2002 11:17:38 +0200

> Such a possibility is one of the reasons to adopt this type of format

Ahh, a nasty person might then ask: why are we burdening all other
addresses with this <scope_type>

  <address>%<scope_type>.<id_in_the_scope>

when they don't need it, and the only place where it would be needed
(that MIB example), is not actually using address at all!

But, of course I can guess why: the place where such notation occurs,
is usually parsed as address, and it would be truly neat if it could
handle the addressless zone id too.

My proposal for a solution is as follows:

 1) <address>%<zoneid> is the format. scope_type is always known from
    the <address>.

 2) to allow an API to specify an ANY address limited to a specific
    scope, the following specic adresses are assigned for the
    purpose:

     fe80::%<zoneid> - ANY address in specified link local zone
     fec0::%<zoneid> - ANY address in specified site zone
     ::%<zoneid>     - ANY address in specified global zone

   and just to be complete, for zone specific multicasts

     ff01::%<zoneid>
     ff02::%<zoneid>
     ff03::%<zoneid>
     ...
     ff0F::%<zoneid>

I believe all (?) of above are sort of illegal in normal use, and
could thus be dedicated for the purpose (MIB, limiting a listen socket
to specific scopeid etc.).

How does this kludge sound?

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Mar 2002 17:44:43 +0100

=> agree!

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Mar 2002 17:53:15 +0100

=> as my goal is to always use names I am neutral: to add scope types
is not a real burden and this catches errors.

=> this was the argument for the binary format. IMHO it is sound to
reuse it for the textual format, so I am slightly in favor of initial
Jinmei's proposal.

Regards

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 20 Mar 2002 19:44:07 +0100 (CET)

>     standard way to implement the ability.

I agree that the issues here needs to be pointed out.
I wonder if we can give more explicit advice for the case
when a MN has a global HoA and a site-local CoA .
For instance, in that case it might make sense to only do bidirectional
tunneling.

Does the document look at the different cases here?

  Erik

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 20 Mar 2002 13:56:51 -0600

Jinmei

> Such a possibility is one of the reasons to adopt this type of format

What would this zone mean to the client requesting the info?  The 
zone-id is meaningless without the accompanying address.  It only
has meaning on the node it is defined with the address of given scope.

The whole scope duplication (in zone-id and address) is dubiouse since 
we don't allow any more having scope mismatches between the zone-id and
the address scope.

> implementation treats "::" as a global address for convenience, and it

The scope of the wildcard is wildcard i.e. it belongs to all scopes.
I might be limed by specified a zone-id if we want to allow it (I think
Dave Thaler originally proposed this on the api list).

-vlad

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Thu, 21 Mar 2002 08:17:06 +0900 (JST)

Hi,

From: Francis Dupont <[email-masked]>
> is to say the bidirectional tunnel belongs to the home site.

Are you saying that if we use a bi-directional tunneling, the off-site
MN can comunicate with the CN that is in the home-site of the MN?

If so, I disagree.  Consider the following condition.

site A (fec0:0:0:100::/64): a home site of the MN
site B (fec0:0:0:100::/64): a foreign site.

If the MN moves from the site A to site B, the MN cannot determine the
direction to which it should send a packet destinated to
fec0:0:0:100:1234:5678:9abc:def0.  The destination address can be both
on the site A and the site B.

---
Keiichi SHIMA
IIJ Research Laboratory  <[email-masked]>
KAME Project <[email-masked]>
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Thu, 21 Mar 2002 00:39:13 +0100

=> exactly, this works as soon as the IPv6 stack supports multi-site
as it should.

   
=> please add zone IDs to scoped addresses.

=> Jinmei, can you explain the scoping architecture to your colleague?
It seems I'll be impolite if I try to answer (:-).

Regards

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 21 Mar 2002 12:04:27 +0900

>>>>> On Wed, 20 Mar 2002 17:53:15 +0100, 

   
   
> is not a real burden and this catches errors.

I agree.  We'll basically use the format with readable "names" or in a
copy-and-paste manner, so this is not a real burden.

> reuse it for the textual format, so I am slightly in favor of initial

I (of course) agree.  However, I admit that the question that Markku
raised can be an FAQ.  So I'd propose to add a note in this section
that

- though it seems redundant to add scope type in <zone_id> when it is
  used with an <address>, it does practically not matter.
- thus, we use the unified (generic) format everywhere rather than to
  allow "optimized" notation.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 21 Mar 2002 12:26:01 +0900

>>>>> On Wed, 20 Mar 2002 19:44:07 +0100 (CET), 
>>>>> Erik Nordmark <[email-masked]> said:

> Does the document look at the different cases here?

(I'm not sure if I understood the question correctly, but anyway...)
My intention in this proposed change is to point out some issues when
using site-local addresses with MIP6 and to recommend to use global
addresses for safety.

We can add some more issues to this section, but I don't think it
possible to cover all such issues.  Also, with the fact that MIP6
itself is a moving target, making too specific advises would not make
much sense.

We'll consider the bidirectional tunneling case anyway, but IMO the
text will still follow the intention above (that is, describing some
issues with a simple recommendation).

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 21 Mar 2002 13:03:07 +0900

>>>>> On Thu, 21 Mar 2002 08:17:06 +0900 (JST), 
>>>>> Keiichi SHIMA <[email-masked]> said:

> If the MN moves from the site A to site B,

In this case, the mobile node is multi-sited.  The following figure
would depict the situation.

   +----------------------------------------+
   | +=====tunnel link====================+ |
   + |  +--------------------------------+| |
    \| /                                 || |
     I1                         +--------+| +--home site-----+
---- MN  ---foreign site--+     |         HA                 |
     I2                   |     |                            |

The MN has (conceptually) at least two interfaces; I1 and I2.  The
former (conceptually) belongs to the home site, and the latter of
course belongs to the foreign site.  The site-local home address
belongs to I1 (or perhaps a different interface, but it should belong
to the home site).

Just like other (normal) multi-sited nodes, the MN should always
disambiguate the site zone when sending a packet.  This applies
when the mobile node sends a packet to a node in the home site.

So,

> the MN cannot determine the

this is true, but cannot be a counter argument to what Francis said.
We should (and can) just disambiguate the site zone when sending.

BTW: It's still true that this type of situation is problematic.
For example,

- there is no way for the mobile to detect if the site A and the site
  B are same or different site (as I said in my first message in this
  thread).
- if the site A and the site B are different sites, the mobile node
  cannot communicate with a node in the site B using mobile IPv6.

					JINMEI, Tatuya

---

From: Markku Savela <[email-masked]>
Date: Thu, 21 Mar 2002 10:54:25 +0200

The

just does not feel right to me. I don't like notations which allow
writing erroneous expressions, whenever it can be avoided. And, I'm
not yet quite convinced, that this case needs such "error-allowing"
notation.

Thus I prefer

      <address>%<id_in_the_scope>

and scope type is from address. And, then make sure every address has
a definite scope designated (the ones for which scope is a bit unclear
are/were :: and "::/3" (eg. those pesky IPv4 mappen and kind
addresses).

 [note, currently I plan to use scope=16 internally for those IPv4
 addresses, that is outside and above IPv6 scopes. One major use for
 this is to distinguish between different 10/8 networks, if they are
 connected to node at same time, directly or tunnels]

I thought my proposal was nice for listen sockets, you don't need a
special separate socket option to set the scope, if you want to limit
your listen to any address of specificic scope. With definitions

and normal bind as before, the process seems very simple (how this is
reflected in internal data structures of listen socket is different,
implementation matter).

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 21 Mar 2002 08:13:44 -0500

>and scope type is from address. 

I also prefer this notation.  It removes any ambiguity about
what a node is supposed to do if the address and the scope
number don't match.

>And, then make sure every address has

Every address has to have a scope, anyway, because routers need to know
when/if a packets should be forwarded.  If an address should not be
forwarded at all, it is link-local.  If it should be constrained 
within a site, it is site-local.  If it can be forwarded anywhere, it
is global.  If this information is undefined for one or more types
of addresses, we need to define it.

If an address is never meant to be used on the wire, it is effectively 
node-local. For a unicast addresses, I think that we should consider
these addresses link-local. That way, mistakes won't be propagated 
across the network.

Margaret

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Thu, 21 Mar 2002 23:56:37 +0900 (JST)

Hi Francis,

> It seems I'll be impolite if I try to answer (:-).

I have read a reply from jinmei-san.  I understand my previous mail is
not true.  I should learn more about the scoped-architecture :-), and
I should make my MIP6 implementation as multi-sited.

---
Keiichi SHIMA

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 22 Mar 2002 07:47:30 +0900

>>>>> On Thu, 21 Mar 2002 08:13:44 -0500, 
>>>>> Margaret Wasserman <[email-masked]> said:

> what a node is supposed to do if the address and the scope

Then, does the following plan make sense?

- in the definition of zone indices (Section 6 in the 03 draft),
  specify that a zone ID includes its scope type and an ID in the
  scope when an implementation handles the zone IDs.
- in the textual representation, only define the form of
  <address>%<id_in_the_scope>
  and specify that <id_in_the_scope> will be translated into an
  (implementation-dependent) internal form containing both scope type
  and the zone in the scope.

> of addresses, we need to define it.

It's true that a packet with link-local src or dst should not be
forwarded across a link border.  However, I do not think it is always
true that "if an address should not be forwarded at all, it is
link-local."  For example, a packet with a multicast source address
should not be forwarded, even if the address has a global scope.
We'll have to specify how a packet with bogus addresses should be
treated, and it may not always be a scoping issue.  I think the
unspecified address falls into this type of bogus address, and makes
much sense to treat it as "no scope" than link-local.

> these addresses link-local. That way, mistakes won't be propagated 

(an additional note which is not related to this discussion) the
notion of "node-local" has been deprecated.  It has been replaced with
the notion of "interface-local".

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 22 Mar 2002 07:56:41 +0900

>>>>> On Thu, 21 Mar 2002 10:54:25 +0200, 

>       <address>%<id_in_the_scope>

As for this, I made another proposal in a reply to Margaret.

> are/were :: and "::/3" (eg. those pesky IPv4 mappen and kind

I think ::/3 (except ::/128) should be treated as global, in terms of
*IPv6* scoping architecture.  

(The address selection draft (by Rich Draves) treats (e.g.)
::ffff:10.1.1.1 as site-local, but, in my understanding, the main
purpose of this is to compare IPv4 addresses and IPv6 addresses in the
destination address ordering in terms of scoping.  Thus, I don't think
the definition in the scoping arch draft contradicts with the
definition in the address selection draft.)

> reflected in internal data structures of listen socket is different,

Honestly, I'm not so fascinated by this trick in API, but anyway, this
kind of API extension is out of scope of the architecture draft.

					JINMEI, Tatuya

---

From: Markku Savela <[email-masked]>
Date: Fri, 22 Mar 2002 01:15:36 +0200

>   and the zone in the scope.

Sounds ok to me!

Although, I wonder, why is it a REQUIREMENT that system MUST encode
into format that that contains both type and zone id? Are there some
RFC API's that assume/require such? [aside from this wordage in
draft?]

If implementation is such that it never needs isolated zone id
(without address), why should it encode the type in?

[Just curious, I probably end up encoding them together also :]

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Mar 2002 00:31:53 +0100

Although, I wonder, why is it a REQUIREMENT that system MUST encode
   into format that that contains both type and zone id?

=> oh god! Look for the discussion in the mailing-list archive and
please don't reopen it.

Regards