[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Status of <draft-hinden-ipv6-global-local-addr-00.txt>

    Date:        Tue, 3 Jun 2003 10:29:14 +0300 (EEST)
    From:        Pekka Savola <pekkas@netcore.fi>
    Message-ID:  <Pine.LNX.4.44.0306031018090.9971-100000@netcore.fi>

  | Yes, applications should of course be *able* to influence these, if they 
  | desire so, provided that:
  |  - they don't need to if they don't want to (including multi-party apps)

I doubt that the latter (parenthetical requirement) is possible.

  |  - the API is de-facto standardized so every app doesn't have to reinvent 
  | the wheel for 10 different operating systems

That would indeed be nice.

  | This also begs the question whether local-scoped addresses would be
  | deployed without global addresses or not (as some have required).

Pekka, there's no way to stop it.   Regardless of what address forms
are created, or not created, this is going to happen, however dumb we
see it as being.   What we need to do is minimise the harm, we cannot
prevent it.

  | If there are local-only nodes, the reason to deploy local-scoped addresses
  | could be simply to use them when needed, no more no less -- without 
  | disturbing the global communication of nodes with global addresses!

There are also those who will always prefer to use local addresses over
global, regardless of what is available.   I'd have global addresses
available everywhere, and use them only when that's the only thing that
works (when routing cannot get other addresses to work).

None of us can impose our model of how any of this should work on the
world at large - we have to be able to cope with different methods of
building networks.   And yes, that means that applications either have
to be able to cope as well, or they need to simply admit that they're
not going to work (or not work well) in all environments.

  | That's "multi-addressing".  (Note that there's a significant overlap with 
  | the two definitions above.)

The difference doesn't matter here.   All that matters at this level is
that a node has two different addresses, which don't work the same from
all different possible peers - from some one works better, from others the
other does, to the extent sometimes that one of them won't work at all
(and that one can be either address, of any scope).

Bob, in the next version of your draft, could you include some mention of
how this change (from FEC0::/10 to FC00::/7) is planned to affect Node
Information Queries (from Matt Crawford's draft) ?


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 majordomo@sunroof.eng.sun.com