Fred Templin writes:
> Mike,
>
> Let me see if I can understand your concerns better. It seems to me
> that your main objection to the hain/templin draft is that you see it
> as implying a particular solution genre, that being a limited range
> addressing scheme to replace site-locals. If this is what you find
> objectionable, then may I assume you are of the opinion that site
> locals don't *need* to be replaced? If so, then it seems you would
> favor an IPv6 addressing architecture that contains only link-local
> and global unicast addresses, i.e., nothing in between?
My inclination is that limited scope (excluding
link local) is extremely problematic, but that's
not really my larger point. The larger point is
that there are a set of requirements that are
driving people to use NAT's in ipv4 today, some of
which are well addressed by ipv6, some of which
are not as well addressed. And suspect that we all
know that ipv6 will get NAT's if those bread and
butter requirements cannot be met easily... NAT is
the devil they know right now, for better or
worse.
However, limited scope addresses are but *one* way
to deal with this set of requirements. What I
think has been getting short-shrift here is that
it seems to be a foregone conclusion amongst many
people -- especially those who were not in favor
of deprecation -- that the set of engineering
tradeoffs amongst the options is well known and
that local scoped addresses are the lesser of
evils. I find that far from clear, and to my
knowledge this working group has never formally
evaluated those options or even enumerated them
for that matter. I think it would be wise to take
on that work, so that we can make an informed
documented decision, and hopefully come to
consensus with our eyes wide open.
> The hain/templin draft discusses requirements for sites that frequently
> change provider points of attachment, sites that are disconnected or
> intermittently-connected to providers, sites that merge with other sites,
> etc.
I think your draft would make a fine starting
point for the work I think needs done if it were
morphed into something that didn't proceed from a
solution and work backward as it seems to do now.
> In these cases, we require local application stability independent of
> any provider-assigned addressing. This requirement is not satisfied by
> link-locals for medium/large sites that comprise multiple links. Thus,
> all we have left are globals and the only way the "active" sites I described
> above could use these would be if the global prefixes could be obtained
> independent of any provider. Fine; so this just means that the sites would
> get their own prefixes and tell providers which prefixes to advertise
> instead of the other way around - right?
>
> This would all be fine were it not for the fact that it would lead to
> immediate global routing table explosion on the order of the number
> of sites that procure their own prefixes which could be quite large.
> I'm willing to suspend disbelief and say that sometime down the
> road we might have a solution for scalable global routing, but in
> what timeframe can we expect to see something like that deployed?
> 1yr? 5yrs? 10yrs? longer?
>
> Scalable global routing in a flat addressing space certainly seems
> like a utopian scenario if it can be achieved. But, if the deployment
> timeframe is looking like mid/long term, then we still need some
> sort of replacement for site-locals in the near term - right?
It's all of these questions and tradeoffs etc,
which I think need to be *documented* and that we
need to get rough consensus about the *problem*
space itself. I don't believe after googlebytes of
email on site locals we even have consensus on
what problems must be solved in order to have a
deployable IPv6 without NAT's being a necessary
evil. Also: I think we are far away from actually
determining that the principle alternatives
(renumbering, PI) are dead letters, or that there
aren't other more creative ways of solving for the
problems/requirements.
Brian thinks this is a waste of time, I respectfully disagree.
Mike
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
