Elliot,
> Given that if the mechanism exists we know people will develop NAT
> functionality in order to isolate enterprises from IP address changes,
> what is the benefit of going forward at all with IP version 6? A large
> address space is useless if you only need a small one. We already ha
On Wed, Apr 02, 2003 at 09:32:42PM -0800, Eliot Lear wrote:
> For those of you who are voting "no" on the question of deprecation...
*waves*
> Given that if the mechanism exists we know people will develop NAT
> functionality in order to isolate enterprises from IP address changes,
I would que
On Thu, 3 Apr 2003 [EMAIL PROTECTED] wrote:
> What is the amount of work to depreciate site locals - how many RFCs need
> to be updated? I'm not convinced that deprecating site locals really solves
> anything.
The number of RFC's (basically address architecture, which is going
revision anyway) is
Hi John,
What is the amount of work to depreciate site locals - how many RFCs need
to be updated? I'm not convinced that deprecating site locals really solves
anything.
The work to keep, and finish, site-locals is much greater than
the work to deprecate them.
To deprecate them, I think that the ad
Margaret Wasserman wrote:
To keep them, we need to document and resolve the issues that
they cause, update all of the IPv6 routing protocols to
document how site-boundaries are maintained, and document
how address selection will be performed in several upper
layer protocols (at least SCTP, SIP a
> So, getting rid of site locals doesn't remove much of the motivation, and
> there are no ready solutions to fulfill some real needs; which worries me.
> Is it possible that by killing site locals, we set the stage for people to
> do something worse? Will people still use FE0C, even if it is depre
Hi Margaret,
> >What is the amount of work to depreciate site locals - how
> many RFCs need
> >to be updated? I'm not convinced that deprecating site
> locals really solves
> >anything.
>
> The work to keep, and finish, site-locals is much greater than
> the work to deprecate them.
>
> To depr
[EMAIL PROTECTED] wrote:
Good point, I stand corrected on this point. You might be interested
in this draft, the SCTP folks made a proposal how to handle IPv6
address scoping and SCTP - its only 3 pages, so its a quick read:
http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-sctpipv6-01.txt
Nick,
I would question your assumptions:
a) That the existence of site locals will cause people to use NAT
b) That the deprecation of site locals will prevent people from
using NAT.
I think we have to turn this around- I view NATs as a bad thing for all
the reasons you've heard time and time ag
Margaret,
>> john loughney wrote:
>> What is the amount of work to depreciate site locals - how
>> many RFCs need to be updated? I'm not convinced that
>> deprecating site locals really solves anything.
> Margaret Wasserman wrote:
> The work to keep, and finish, site-locals is much greater
> than
Erik Nordmark wrote:
> ...
> I think #4 (which I didn't talk about at the mike) is a red
> herring. Perhaps the issue is a restatement of #1 (due to the
> ISP implicitly forcing a
> renumbering each time the site connects) in which case the
> points about #1 applies. And note that making site-l
Margaret Wasserman wrote:
> ...
> The work to keep, and finish, site-locals is much greater
> than the work to deprecate them.
Wishful thinking...
>
> To deprecate them, I think that the addressing architecture
> and the default address selection rules would be the only
> RFCs (both at PS) tha
While I think it would be great to design a mechanism that would
allow smooth operation of intermittently connected nodes whose
global addressing potentially changes at each re-connect, I do
not believe that we want to impose a costly and complex solution
on _all_ IPv6 nodes so that a few of them c
--On Thursday, April 03, 2003 10:04:37 -0800 Tony Hain <[EMAIL PROTECTED]>
wrote:
> This whole deprecate effort is about making it someone else's problem.
It is less of a problem to do the right thing, as Elliot wrote. Less pain
now, less pain in the future.
> The IETF has successfully driven
> It is not a red herring. Input sent to me for the requirements doc:
But this case is exactly the same as what I categorized as #1 in my list -
isolating communication local to the site from site renumbering. The only added
twist is that site renumber occurs when the site attaches and detaches f
On Fri, Apr 04, 2003 at 01:38:28PM +0200, Erik Nordmark wrote:
> > Research ships at sea intermittently connect via INMARSAT, or when in
> > port, the shipboard network is connected to shore via Ethernet.
>
> Looking at your resarch ship case a bit more in detail it occurs
> to me that even using
> I think site-locals could be used here, with a single rule that they're
> simply the least preffered prefix used in address selection.
>
> Whilst the boat is in a port, it receives a global prefix which is
> advertised on appropriate subnets. Before leaving port the prefix
> is deprecated (but
Måns Nilsson wrote:
> ...
> So, I'm glad that you call on the operator community, but I
> think you will be surprised at what they say.
I am not surprised because ISPs have a different perspective on this
issue (and many others) than enterprise network managers. The network
managers that will pr
I tend to agree with Erik on the research ship case; since the ship is
a rather large and coherent entity (most likley owned by an even larger
organization) it makes sense for it to have one or several globally
unique prefix assignments that can be used whether/not the ship has a
connection to the
Erik Nordmark <[EMAIL PROTECTED]> wrote:
|Looking at your resarch ship case a bit more in detail it occurs
|to me that even using site-locals plus globals while connected doesn't
|necessarily protect the local communication. The introduction of the
|global prefix/addresses when the ship is connec
On Thu, 3 Apr 2003, Michel Py wrote:
> IMHO, the compromise approach such as the exclusive model Bob and you
> came up with has more chances of success and a good starting point. If
> the WG can't agree on such a thing I doubt it could agree on a solution
> started from scratch.
Exclusive model is
On Thu, Apr 03, 2003 at 08:48:19AM -0800, Eliot Lear wrote:
> Nick,
>
> >I would question your assumptions:
> >a) That the existence of site locals will cause people to use NAT
> >b) That the deprecation of site locals will prevent people from
> > using NAT.
>
> I think we have to turn this
Title: Site Locals and the DFZ
> Glenn Morrow wrote:
> Another question would be is the DFZ
a site?
No, it is not; and I don’t think it
will ever be. If there is a place where you would find disparate routing policies,
that is the DFZ.
Michel.
Title: RE: Site Locals and the DFZ
Michel,
While I definitely agree with the statement, "If there is a place where you would find disparate routing policies, that is the DFZ.", I'm not sure if this should be used to conclude that there is no use of thinking of the DFZ
Glenn,
> While I definitely agree with the statement, "If there is a place
> where you would find disparate routing policies, that is the DFZ.",
> I'm not sure if this should be used to conclude that there is no
> use of thinking of the DFZ as some sort of logical site with a site
> local address
Summary: a provider independent addressing solution is proposed so that
site-locals are not necessary.
One of the chief reasons proposed for the use of site-locals is for stable
addressing (especially if you need to change ISP's). A nicer solution, that
has so far proven unimplementable is prov
Pekka,
> Pekka Savola wrote:
> but it depends on certain things (like site-border routers)
> that are unacceptable. The proposal doesn't seem to be be
> workable in practise, IMHO.
This is speculation, also called FUD and does not lead to making
progress.
> I'm not personally that much opposed
> Pekka Savola wrote:
> Exclusive model creates certain very disturbing problems in
> hosts (wrt. oscillation between global and site-local) which
> might be fixable, and ones even more so in the routers
> (requiring quite extensive site-local implementation) which
> is unlikely to go away.
Maybe,
On Thu, 3 Apr 2003, Michel Py wrote:
> > Pekka Savola wrote:
> > but it depends on certain things (like site-border routers)
> > that are unacceptable. The proposal doesn't seem to be be
> > workable in practise, IMHO.
>
> This is speculation, also called FUD and does not lead to making
> progres
Hi,
Join the multi6 list and check the archives.
Brian
Shannon -jj Behrens wrote:
>
> Summary: a provider independent addressing solution is proposed so that
> site-locals are not necessary.
>
> One of the chief reasons proposed for the use of site-locals is for stable
> addressing (espec
On Fri, 4 Apr 2003, Måns Nilsson wrote:
> > The IETF has successfully driven out most of the network managers, and
> > now the remaining developers are trying to dictate how networks get run
> > by removing the tools that people really use.
[...]
> I am talking to a lot of friends in the operation
--On Friday, April 04, 2003 10:26:50 +0300 Pekka Savola <[EMAIL PROTECTED]>
wrote:
> So, in a sense it would also be good to get feedback from ops folk of the
> latter categories. Those do exist, but I assume *they* are ones that are
> more rarely seen at the IETF (but also probably those who
> Once we start handing out addresses whose practical scope is less than
> global, we either need proxies (eg NAT) or multi-homing.
I disagree.
One reason I disagree is that when we make global addresses unreachable,
this is usually done because policy dictates that those hosts not be
reac
33 matches
Mail list logo
