Subject: RE: Scoping Scoped Addresses

From: "Richard Draves" <[email-masked]>
Date: Fri, 15 Nov 2002 14:53:25 -0800

I support Bob Hinden's email, quoted below.

I don't understand why we are spending so much time on this issue. I get
this impression that the folks who haven't yet implemented support for
site-local addresses are worried that they will suddenly be stuck
implementing and testing a bunch of code they don't want. That's really
not the case.

I do not advocate requiring every host and router implementation to have
multi-site support. I think all that's required for host implementations
is the default address selection rules, and all that's required for
router implementations is to have two modes (either all interfaces are
in the same site so site-locals are treated like globals, or all
interfaces are in different sites so site-locals are filtered). This is
really very little burden for host and router implementations.

I do not advocate requiring applications to work well on multi-sited
hosts. Some developers will want to support this, some will not and
that's OK.

For distributed applications that do referrals, a simple policy is to
run in either "global mode" (only using global addresses) or "site mode"
(only using site-local addresses). This takes very little code to
implement. Anything more sophisticated should be at the discretion of
the developer.

Rich

> -----Original Message-----
> From: Michel Py [mailto:[email-masked]] 
> Sent: Thursday, November 14, 2002 7:56 AM
> To: Bob Hinden; [email-masked]
> Subject: RE: Scoping Scoped Addresses
> 
> 
> Ipv6 folk,
> 
> I think there are some of you that need to re-read what Bob 
> Hinden post here ten days and several hundreds email ago.
> 
> I support Bob in the statement he made as chair and I will 
> continue to work within the framework outlined below.
> 
> Michel
> 
> > Bob Hinden wrote:
> [Working group chair hat on]
> 
> I have been trying to make some sense of this discussion.  
> The only obvious 
> conclusion is that there is not a consensus in the working 
> group on how 
> site-local addresses should be used.
> 
> Some people think that site-local is an important feature 
> with many uses, 
> others think they are bad and should not be used.  Some think 
> they provide 
> security, some do not.  Some thing they help with 
> renumbering, some do 
> not.  Some thing they help avoid IPv6 NAT's, some think they 
> encourage IPv6 
> NAT's. Etc., etc.  The only thing that is clear is there are 
> a significant 
> number of people who have different views on this topic.  
> It's doubtful 
> that one group will convince the other group.  One positive 
> result of the 
> discussion was that the issues and benefits are better 
> understood.  The 
> real question for the working group is what to do next.
> 
> Now that the IPv6 Address Architecture was approved as a 
> Draft Standard and 
> the Default Address Selection document was previously 
> approved, we have 
> site-local addresses in IPv6 and a set of default rules for how an 
> implementation selects them.  What we don't have is how they 
> should be used 
> or not-used.
> 
> Even though there is no consensus on how site-local addresses 
> should be 
> used, I think there is enough people who want to use 
> site-local that it is 
> reasonable that the w.g. should continue trying to flesh out 
> site-local 
> usage as well as pitfalls of usage.
> 
> Here is a proposal for how to proceed from here that tries to 
> take into 
> account both sides of the discussion.
> 
> 1) Node Requirements should not require any multi-site 
> implementations.  The only site-local requirement should be 
> limited to what 
> is currently in the address selection rules and for routers 
> to configure
> 
> site-locals just like any other unicast prefix.  Vendors are 
> free to go 
> beyond this in their products, but the IETF won't require it.
> 
> 2) People who think the usage of site-local is harmful should 
> write a draft 
> titled something like "Use of Site-local Addresses Considered 
> Harmful".  The people in the other camp can comment to make sure the 
> arguments are accurate.
> 
> 3) People who want to use site-local addresses should work on 
> completing
> 
> the "IPv6 Scoped Address Architecture" document (and other docs if 
> needed).  I think a good focus for this would be to focus on 
> the simplest 
> cases.  Topics to cover need to include site border routers, adding 
> site-local addresses in the DNS, routing protocols, the use 
> of firewalls to 
> enforce site boundaries, and guidelines on how applications 
> might want to 
> select between global and site-local addresses.  The people 
> in the other
> 
> camp can review this work and make sure the technical content 
> is accurate.
> 
> I believe this approach should help provide the larger 
> community (e.g., 
> vendors, ISP's, enterprise operators, etc.) the information 
> they need to
> 
> make an informed decision on the usage of site-locals.
> 
> Bob
> 
> p.s. I will also send out a few personal comments on site-locals in a 
> separate email.
> 
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Fri, 15 Nov 2002 18:22:29 -0500

My view is that in the absence of strong discouragement of SL addresses
(with a few clearly valid use cases as exceptions), applications will be 
expected to work well with a mixture of SL and global addresses - 
even if IETF doesn't expect that.  So I don't think it's sufficient to 
simply say "folks can use SLs if they want to", or even "site mode
apps don't have to talk to global mode apps"  - the former will create
a support burden for apps and the latter won't match with user expectations.

I doubt there are many inherently "site mode" apps.
I'm sure there are some, but offhand I can't think of any.

The trick is to provide recommendations that make it simple to do 
the right thing.  A general discouragment of SLs would accomplish this.
Trying to outline all (and have applications detect and handle) of the 
specific cases where SLs *could* be used is very difficult.

Keith

---

From: Markku Savela <[email-masked]>
Date: Sat, 16 Nov 2002 02:19:27 +0200

> From: Keith Moore <[email-masked]>

> specific cases where SLs *could* be used is very difficult.

I cannot figure out where this comes from. Most applications don't
need to do anything different for SL than they are doing for
globals. If your node belongs to only one site, SL's behave exactly
like global addresses inside the node.

A client application establishing a connection would just get the
address from DNS (or whatever source), and use it as is, wether SL or
not.

The only cases, that might require additional work, are applications
that pass own address inside the protocol. I can think one example of
such: IRC and activating client-to-client connection.

  When doing so, an IRC client sends an IRC private message
  containing it's own address and port over the IRC network.

A careful client, which is prepared to work in multihomed host,
would extract own address from the connection that is being used
for the server.

- however, the server might be on SL address, but connected to outside
  world. Then this strategy would fail. The minor additional work in
  this case in IPv6 world, would be to ask highest scope address that
  is available (although things get a bit fuzzy, if node is truly
  multihomed with multiple global addresses on different interfaces..)

- above is no way different situation that currently exists, if your
  IRC server is on 10.x.x.x address. If you have both 10.x.x.x and
  some global address, client should send the global address, and not
  the address used to talk with the IRC server.

- if you don't have global address (either IPv6 global or IPv4
  global), you are hosed any way (unless the other client is also same
  site, in which case all works just fine again).