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

RE: A suggestion around address selection behaviour



Hans Kruse wrote:
> ...
> and in draft-hain-templin-ipv6-limitedrange-00.txt
>    In the simple case, hosts that are allowed external access have a
>    policy that allows them to configure both global and limited range
>    prefixes, while those that are not allowed global access have a
>    policy that only allows limited range. ***Address 
> selection rules will
>    prefer the smallest range***, so internal communications 
> are forced to
>    stay internal by the hard filter at the border.
> 
>    (Emphasis added by me).
> 
> draft-hain-templin-ipv6-limitedrange-00 does a good job 
> outlining scenarios 
> that may  require the use of local addressing, but I think it 
> errs in the 
> statement above.  The  local addressing requirement is real 
> enough, but 
> these are still corner cases.  Aside  from ambiguity, 
> enforcing the concept 
> of scope or range _in every application_ seems  to be one 
> that folks really 
> want to get rid of.
> 
> Hence, lets revisit the question of _default_ address 
> selection.  What if:
> 
> "Unless an application explicitly requests otherwise, an IPv6 
> node must use 
> its  unique, globally routable address if one is configured.  
> If no such 
> address is  configured, the node shall use its limited range 
> local address, 
> if configured."
> 
> Along with:
> 
> "An IPv6 node must allow an application to explicitly request 
> the use of 
> the limited  range local address, if such an address has been 
> configured, 
> even if a unique globally  routable address is available."
> 
> What I am trying to get to is:
> 
> - Application designers who want to work in the "end-to-end 
> clean" Internet 
> and who do  not care to support the corner cases should be 
> able to do so.
> 
> - The default address selection rules should favor solutions based on 
> global  addressing, I think we all agree that if such a solution is 
> reasonably possible, it  should be used.  

No, we do not all agree. See below.

> With the defaults above, the 
> "path of least resistance" is not to use  limited range, 
> which is good.

While I appreciate your goal of compromise here, the insistance of avoiding
the local prefix is short-sighted. In particular it overlooks the point that
during an ISP prefix change local application stability is only possible
using the local prefix. If the default is to avoid the local prefix, every
local app will break on a prefix change, which is directly contradictory to
the goal of a smooth transition between ISPs. 

I think we should explicitly disallow a mismatch between local & global. In
addition, to achieve the use of globally routed in the non-local cases the
name resolution system needs to provide contextually appropriate answers.


> 
> - Finally, if a solution requires local addressing, and 
> application writers 
> want to  support it, there needs to be a standardized way to 
> do this (which 
> is why local  addresses must be defined and recognizable).

I agree there should be a way for apps to specify a preference for one or
the other. 

> 
> In draft-hain-templin-ipv6-limitedrange-00, scenarios where 
> all machines 
> either have  only local addresses, or where all of them (albeit 
> intermittently) acquire global  addresses along with the 
> local ones, will 
> work with the default behaviour suggested  above.

No, if applications in an intermittently connected network selected the
non-local prefix, and it went away or changed, they would need to drop and
reestablish the connection. Yes they could keep using the prefix as long as
it was still valid, but from a diagnostics and management perspective you
don't want a bunch of deprecated-but-still-valid prefixes running around for
communications that should always stay internal to this network. Also, in
some cases the application will want to run for longer than the valid time,
so even if that approach is taken local apps will break for no good reason.

> 
> Cases where networks contain a mixture of nodes (some local 
> only, some 
> local and  global), and very long-lived connections in intermittently 
> connected networks, need  special handling.  In both cases it seems 
> reasonable that applications will be written  or at least 
> configured to be 
> aware of the local/global address issue.

Why? Are you suggesting that a ship can't run a stock database
implementation? Yes specialty applications should be aware, but there is no
reason to preclude use of off-the-shelf configurations.

> 
> Along with safeguards against address translation in the 
> nodes requirement, 
> and  routing restrictions in the address format document, 
> this should work.
> 
> I know I left out plenty of detail, but I hope the general 
> idea is clear 
> enough.   Comment/Flame away.....
> 

Not a flame, but one other issue; there is a security argument to be made
for defaulting to limited range addresses. If the default stance is limited
range, people would not be automatically exposing their system just by
installing an app. Of course the counter argument to security is
configuration simplicity, and making Joe-sixpack explicitly select the
exposure range is not particularly viable either. Getting back to your point
about api selection, should the default api be don't-care, or limited-only?
Using the current address selection rules for the don't-care case, the
behavior would be more stable for local apps but still exposed for global
reachability. If the default were local-only, the app, or sys-admin would
have to explicitly select when exposure happens. 

This is really a question about how much we really want to see hosts and
applications protect themselves ...

Tony


> 
> 
> 
> Hans Kruse, Associate Professor
> J. Warren McClure School of Communication Systems Management 
> Adjunct Associate Professor of Electrical Engineering and 
> Computer Science Ohio University, Athens, OH, 45701 
> 740-593-4891 voice, 740-593-4889 fax
> 
> --------------------------------------------------------------------
> 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
> --------------------------------------------------------------------
> 


--------------------------------------------------------------------
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
--------------------------------------------------------------------