ietf
[Top] [All Lists]

RE: Removing features

2003-10-13 10:07:20
John,


John C Klensin wrote:
(1) A set of semantics and expectations about,
e.g., applications behavior, otherwise known
as "the feature".
(2) An address range.
Is that correct, or is that controversial too?

It looks correct to me although I will detail the feature part below.


Now part of the justification for IPv6 is to
have "enough" address space.  We may be moving
toward that being the only justification, but
that is another discussion. "Enough" presumably
includes sufficient headroom that we can make a
mistake about allocation strategies and deal
with it by simply retiring the block. One would
not want to do that often, especially with large
blocks, but we ought to be able to survive more
than "never".

Correct. There are 1,024 possible /10s, for example. Screwing up with
three or four is not such a big deal. I'm not saying it's good, but if
the resolution of the issue is that we have to iterate three times on a
solution and end up wasting three times a /10, be it.


But an enterprise that thought it needed local
space could presumably use that range, with
appropriate filters, etc., but without assuming
that, e.g., applications would treat it in a
special way.
I don't expect this suggestion to make anyone
on either side happy, but is it possibly a way
out of the "you can't really deprecate that
without causing worse damage" part of this mess?

The feedback I am getting from enterprise operators is that they
generally don't care about any special application behavior. At the
application level, for all practical purposes there is no need to
differentiate site-locals from other addresses.

The arguments I have heard from app developers indicate that there are
trying to fix issues that are none of their concern. If I design a
network that makes apps break, it's my problem, not theirs.
Specifically, enterprise operators generally:

- Are inclined not to use the multi-address capability of IPv6. Inside
  the enterprise network, it brings complications that are not worth
  the advantages, _especially_ for parts of the network that are
  earmarked as private.

- Do not flood root servers with reverse lookup queries for private
  addresses (I want my traceroutes to work on the inside of the network
  too, so I long ago configured reverse lookup for private addresses on
  my internal DNS servers).

- Deal with ambiguity when there is a collision like when sites merge.
  Besides, IPv6 ambiguity for private addresses could be resolved.

What enterprise operators care about is router behavior, so something
along the lines of scoping will have to be delivered at some point. This
point does not need to be right away as it could be accommodated with
manual filters that will remain in place anyway for defense in depth
considerations.

Michel.




<Prev in Thread] Current Thread [Next in Thread>