the addresses proposed in draft-hinden appear to be strictl

1
Unique Local Addresses

• IETF58 Minneapolis
• November 2003
• Bob Hinden

2
STATUS

• Current draft is ltdraft-ietf-ipv6-unique-local-
  addr-01.txtgt
• Working group last call started on 22 Oct 2003
• Active discussion on mailing list
• Note
• Hinden is taking on role of active author on
  draft
• Haberman is shepherding chair role

3
ISSUES RAISED

• Are these needed at all?
• Do these addresses need to be treated specially
  by applications?
• Leakage into global routing
• Charging for centrally assigned prefix
  instructions to IANA
• Filtering rules need to be improved
• Provide alternative suggested random algorithms
• Best name for these addresses
• Editorial (not discussed here)

4
NEED FOR ULAs

• Are these really needed?
• Can RIR provide additional allocations from RIR
  address space?
• Use 6to4 prefix instead
• Roll your own
• Yes, still needed
• Suggested alternatives dont provide for local
  disconnected/intermittent allocation
• Significant community wants of this type of
  address
• ULAs better than other known alternatives

5
SUMMARY OF TRADEOFFS
Let's assume that the need won't go away. We have
de facto three local addressing proposals use the
existing site local prefix, hijack a prefix in
the 2000/3 space, or draft-hinden. Site
administrators who perceive this need will pick
one of these three proposal. How do they compare
from a "leak" point of view? My take is as
follow - using site local is roughly equivalent
to using net 10 in IPv4. The address range can be
filtered in routers, but it is ambiguous.
Ambiguity prevents tracing the source of the
leaks. - hijack a prefix is roughly equivalent
to the pre-RFC-1958 situation in IPv4, e.g.
alumni reusing the MIT address space. The address
range can be filtered in some routers, but not in
all of them. Leaks are difficult to even notice,
and result in misdirection of traffic to an
unsuspecting party. Leaks in the routing
protocols result in routing disruption. - the
addresses proposed in draft-hinden appear to be
strictly better than either the existing
site-local or hijacked addresses. They can
be filtered in routers. Attempts at uniqueness
give us a reasonable hope of tracing the source
of leaks. They don't conflict with
existing addresses, so the leaks don't affect the
connectivity or the traffic load of third
parties. In short, the proposed addresses cannot
eliminate application level leaks, but they can
definitely reduce their consequences, and do a
much better job at that than the alternatives.
Christian Huitema
6
APPLICATION HANDLING?

• Issue
• Do applications need special knowledge about
  these addresses?
• Issue is not introduced by ULA addresses
• Applies to other types of routing limitations
• Firewalls, egress filtering, etc.
• Useful to to investigate general solutions to
  this class of problems
• Impact to source/destination address selection?
• Will longest match rules just work?
• Provide more feedback via ICMP errors

7
LEAKAGE

• Issue
• These addresses will be leaked into global
  internet
• Leaking is bad
• Document provides for reasonable measures to
  prevent most leakage
• Uniqueness reduces impact of accidental leakage
• Leakage problem affects all non-routable
  addresses
• Even PA addresses that are filtered are leaked
• ULA is good tradeoff between alternative
  approaches

8
CHARGING, IANA INSTRUCTIONS

• Issues
• IETF documents cant specify a specific charge
  and use of revenue
• Need IANA guidelines that fit within current
  environment
• Resolution
• Remove mention of 10 euro and change text to
  clarify the requirement for low cost and need to
  prevent hoarding.

9
PROPOSED TEXT
3.2.1 Centrally Assigned Global IDs The
requirements for centrally assigned global ID
allocations are - Available to anyone in an
unbiased manner. - Permanent with no
periodic fees. - One time non-refundable
allocation fee per allocation that is
affordable by a broad spectrum of end users when
considered globally. - Provide mechanisms
that prevent hoarding of these allocations.
- The ownership of each individual allocation
should be private, but should be
escrowed. ... The reason for the use of an
allocation fee for each prefix is to allow
this service function to operate on a cost
recovery basis. An acknowledged side-effect of
such a mechanism is that it provides some
impediment to any hoarding of the these
allocations. The consideration of
affordability is intended to keep the cost low
enough so as not create a barrier to anyone
needing one. The charge is one time to
eliminate the need for an ongoing relationship
with the allocation authority, while
acknowledging the service costs for both the
registration function and the enduring escrow
service. The charge is non-refundable in
order to keep overhead low. 13.0 IANA
Considerations ... document, including in
particular the charging of a modest one-time
fee that is to be aligned with service costs
associated with the allocation function and
enduring escrow of the allocation data.
10
FILTERING

• Issue
• Filtering rules need to be improved.
• Specifically, black holing has bad side effects
• Starts TCP timeouts
• Agreed
• Improve text on filtering
• Add MAY respond with ICMP Administratively
  Prohibited

11
PROVIDE ALTERNATIVE ALG

• Issue
• Provide alternative random algorithms for prefix
  generation
• Would make clearer what is required
• Action
• Check text to insure other sufficiently random
  algorithms are allowed

12
BEST NAME FOR ADDRESSES

• Issue
• Unique Local Addresses isnt ideal
• Suggested Alternatives
• Organizational addresses
• Entity local IPv6 unicast addresses
• Globally Unique Non Normally Routable Address
  Class
• NOT Hinden/Haberman
• Thoughts?

13
RELATIONSHIP TO S-L DEPRECATION

• Two parts to complete deprecating Site-Local
  addresses
• Deprecation document, update Address
  Architecture, etc.
• Provide something better
• Providing a standard alternative is KEY to
  eliminate usage of Site-Local
• Non-standard local addresses solutions are even
  worse than Site-Local

14
NEXT STEPS

• Important to move this forward
• Author thinks with changes outlined here,
  document is ready to advance
• Is there a consensus to move this forward?
• (when new draft is available)