What I raised my hand for in San Francisco was to deprecate SL
addresses as currently defined in draft-ietf-ipngwg-addr-arch-v3-11.txt
(and in RFC 2373).
I don't find this question ambiguous. It's true that we would
have to revise the addressing architecture again as a result
(probably simply by r
"YES -- Deprecate site-local unicast addressing".
--
Fredrik Nyman
PacketFront Sweden AB
http://www.packetfront.com/
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
F
As I already said under another subject line,
what I understood we were deprecating is SL as defined
in the current address architecture, i.e. FEC0::/10.
That's the only formal definition of SL, so I don't see
what else we could be referring to.
Brian
Steven Blake wrote:
>
> On Tue, 2003-04-
> According to the draft minutes, someone mentioned we can use arbitrary
> prefixes for those purposes. That's true, but we cannot assure the
> uniqueness of the arbitrary-chosen prefixes, so I don't see any
> essential advantage over the existing fec0::/10 (with eliminating the
> "full" usage).
>
[EMAIL PROTECTED] wrote:
> NO - Do NOT Deprecate Site-Local Addressing.
>
> There are reason to use site-locals, and reason NOT to use them. But
> "FORBIDDING" people will only alienate them and lead them to
> find ways to do it anyway.
>
> Perfect example, when (or should I say IF) my home ISP
Brian McGehee write:
> NO -- Do not deprecate site-local unicast addressing
>
> - Site-locals should be retained for disconnected sites. If
> not SL, then
> a mechanism needs to be adopted that can provide a private means of
> selecting from a private address space that is "reserved" for this
[EMAIL PROTECTED] wrote:
> > Hiroki Ishibashi wrote:
> > > There are plenty of potential ways to achieve this some of
> > > which include:
> > > * get a prefix for disconnected access from a ISP.
> > > * set up registries.
> >
> > These will definitely increase the cost of owning even
"YES -- Deprecate site-local unicast addressing".
But, some mechanisms (or manner) for disconnected sites should be
invented.
---
Keiichi SHIMA
IIJ Research Laboratory <[EMAIL PROTECTED]>
KAME Project <[EMAIL PROTECTED]>
IETF I
> From: "Jeroen Massar" <[EMAIL PROTECTED]>
>
> If someone doesn't want/like this they can pick a random number
> and use that, they still have to renumber when they interconnect
> to another site or the internet.
No, when you interconnect, you just keep using your global addresses
in parallel w
Brian McGehee [mailto:[EMAIL PROTECTED] wrote:
> *Notes below
>
> * I agree "NAT != SL"! Except in the case that hosts need "global"
> connectivity and they ONLY have a SL address will require
> NAT. Or they should have a second IPv6 globally unique unicast
address
> (which isn't that hard
Markku Savela [mailto:[EMAIL PROTECTED] wrote:
> > From: "Jeroen Massar" <[EMAIL PROTECTED]>
> >
> > If someone doesn't want/like this they can pick a random number
> > and use that, they still have to renumber when they interconnect
> > to another site or the internet.
>
> No, when you intercon
Brian E Carpenter wrote:
If IPv6 has a better anonymity solution, can someone point me
to it? Or do I have to start working on NATv6? (See, this is
why I don't always want to identify myself! :-)
See RFC 3041 - It does exactly what you want without the
drawbacks of NAT.
Actually not, if you ha
Michel Py wrote:
>
> Brian,
>
> > Brian E Carpenter wrote:
> > IMHO it doesn't make a case for SLs in their present
> > incarnation (i.e. ambiguous address space).
>
> Note that if the present state is still ambiguous, it's largely due to
> the fact that authors of drafts to make them unique (no
YES -- Deprecate site-local unicast addressing
... as presently defined.
The ambiguity of the current site-local addresses will impact applications.
We still need to solve the other problems (renumbering and disconnected
sites) but we should do this using an addressing format which can be made
> From: "Jeroen Massar" <[EMAIL PROTECTED]>
> Markku Savela [mailto:[EMAIL PROTECTED] wrote:
> > Despite claims of opposite, this combination works just fine.
>
> Example.com: fec0::/10
> Example.org: fec0::/10
>
> Good luck in tossing the bits around to routers in between those sites
> :)
That
Markku Savela [mailto:[EMAIL PROTECTED] wrote:
> > From: "Jeroen Massar" <[EMAIL PROTECTED]>
> > Markku Savela [mailto:[EMAIL PROTECTED] wrote:
> > > Despite claims of opposite, this combination works just fine.
> >
> > Example.com: fec0::/10
> > Example.org: fec0::/10
> >
> > Good luck in tossi
YES -- Deprecate site-local unicast addressing
- kurtis -
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ip
> From: "Jeroen Massar" <[EMAIL PROTECTED]>
>
> Global addresses, good, and where did you need a SL for again?
Well, just for fun, I keep using SL for internal connections. One
never knows when my global connection may break or change prefix, at a
whim of ISP. Or maybe I have two ISP connections,
> [EMAIL PROTECTED] wrote:
>
> > > Hiroki Ishibashi wrote:
>
>
>
> > > > There are plenty of potential ways to achieve this some of
> > > > which include:
> > > > * get a prefix for disconnected access from a ISP.
> > > > * set up registries.
> > >
> > > These will definitely increase the cos
On Wed, Apr 02, 2003 at 03:37:25PM +0200, Jeroen Massar wrote:
> Indeed 'just pick some random address' if you don't want to
> be connected to the rest of the world. No need for SL.
> Also E20 or a similar amount is peanuts compared to what it
> would cost if you need to renumber your complete site
Alexandru Petrescu wrote:
Brian E Carpenter wrote:
If IPv6 has a better anonymity solution, can someone point me
to it? Or do I have to start working on NATv6? (See, this is
why I don't always want to identify myself! :-)
See RFC 3041 - It does exactly what you want without the
drawbacks of NAT
Markku Savela [mailto:[EMAIL PROTECTED] wrote:
> > From: "Jeroen Massar" <[EMAIL PROTECTED]>
> >
> > Global addresses, good, and where did you need a SL for again?
>
> Well, just for fun, I keep using SL for internal connections. One
> never knows when my global connection may break or change pr
Dear colleage;
Notice: I'm posting here, to say comments, as merely one user
of IPv6.
--
Currently, ``NO - Do NOT Deprecate Site-Local Addressing.''
--
Just my feelings follows;
--
Site-Local address seems to be the nearest candidate to be used
as ``local'' (locally used without interconnect
Mike Saywell wrote:
> On Wed, Apr 02, 2003 at 03:37:25PM +0200, Jeroen Massar wrote:
> > Indeed 'just pick some random address' if you don't want to
> > be connected to the rest of the world. No need for SL.
> > Also E20 or a similar amount is peanuts compared to what it
> > would cost if you need
"YES -- Deprecate site-local unicast addressing".
from: Chris Fischer
Lucent Technologies
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive:
On Wed, 2003-04-02 at 03:41, Brian E Carpenter wrote:
> As I already said under another subject line,
> what I understood we were deprecating is SL as defined
> in the current address architecture, i.e. FEC0::/10.
Do you mean the e-mail where you said the following?
--> I prefer to think about t
> "YES -- Deprecate site-local unicast addressing".
Ambiguous addresses are a nightmare...
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive:
> Brian E Carpenter wrote:
> What I raised my hand for in San Francisco was to
> deprecate SL addresses as currently defined in
> draft-ietf-ipngwg-addr-arch-v3-11.txt (and in RFC 2373).
This has never been stated and you can expect appeals all the way to the
supreme court and I'll be supporting t
On Wed, Apr 02, 2003 at 04:59:06PM +0200, Jeroen Massar wrote:
> Mike Saywell wrote:
> > I setup an ad-hoc network using my laptop, wireless is 1 network and
> > wired is a second, my laptop routes between them. There is
> > no external connectivity and site-locals are deprecated so I pick
> > a
> Brian E Carpenter wrote:
> Exactly. It was the present incarnation, not some
> possible future incarnation, that I raised my hand
> against.
Really? By trying to sneak a major architectural change into a last 24
hour "editorial" change? I am going to file an appeal about how this
entire situatio
> Brian E Carpenter wrote:
> Exactly. It was the present incarnation, not some
> possible future incarnation, that I raised my hand
> against.
I would like to hear what Steve Deering, as author, has to say about all
of this too.
Michel.
--
YES -- Deprecate site-local unicast addressing.
--
Stanislav Shalunov http://www.internet2.edu/~shalunov/
Most people can do nothing at all well. -- G. H. Hardy
IETF IPng Working Group Mailing List
IPn
Brian E Carpenter wrote:
> >
> > What was the consensus, if any, on alternatives to
> site-locals when SL
> > is deprecated?
>
> As I've already said, I think that is the wrong order of discussion.
>
> I think we should clear the desktop first, by getting rid of
> ambiguous site-local address
Jeroen Massar wrote:
> ...
> If someone doesn't want/like this they can pick a random
> number and use that, they still have to renumber when they
> interconnect to another site or the internet.
Renumbering in an IPv6 context means adding a prefix. Unlike IPv4 it
does not mean removing the exist
Jeroen Massar wrote:
> Brian McGehee [mailto:[EMAIL PROTECTED] wrote:
>
> > *Notes below
> >
> > * I agree "NAT != SL"! Except in the case that hosts need "global"
> > connectivity and they ONLY have a SL address will require
> > NAT. Or they should have a second IPv6 globally unique unicast
Tony Hain [mailto:[EMAIL PROTECTED] wrote:
> Jeroen Massar wrote:
> > Brian McGehee [mailto:[EMAIL PROTECTED] wrote:
> >
> > > *Notes below
> > >
> > > * I agree "NAT != SL"! Except in the case that hosts
> need "global"
> > > connectivity and they ONLY have a SL address will require
> > > N
Tony Hain [mailto:[EMAIL PROTECTED] wrote:
> Jeroen Massar wrote:
> > ...
> > If someone doesn't want/like this they can pick a random
> > number and use that, they still have to renumber when they
> > interconnect to another site or the internet.
>
> Renumbering in an IPv6 context means adding
Jeroen Massar wrote:
> > > ...
> > > Then don't route a certain prefix.
> >
> > Using filtering on a single global prefix does not work when
> > nodes that
> > need external access are on the same segment with those
> that shouldn't
> > have it. Prefix filtering is the answer, but the prefix to f
Tony Hain [mailto:[EMAIL PROTECTED] wrote:
> Jeroen Massar wrote:
> > > > ...
> > > > Then don't route a certain prefix.
> > >
> > > Using filtering on a single global prefix does not work when
> > > nodes that
> > > need external access are on the same segment with those
> > that shouldn't
> >
"NO -- Do not deprecate site-local unicast addressing".
- Site-locals should be retained for disconnected sites.
- Site-locals should be retained for intermittently connected sites.
- Site-locals should be retained for their access control benefits.
- Site-locals should be retained as a means for
Dan Lanciani writes:
> MUST NOTs in RFCs are not going to stop NAT.
>
> Eliminating NAT is actually very simple. All you have to do is give users
> that which by its lack drove them to use NAT in the first place: plentiful,
> free, stable address space. I conclude from the effort that folk
Mike Saywell wrote:
>
> How about using fec0:::/64? That gives a (probably) private
> network per interface, the only issue is that you wouldn't be able to
> aggregate them in a sizeable network - however I agree that site-locals
> shouldn't be used in such a scenario. :)
There are currently two
Michael Thomas wrote:
> ... Scoped addresses as have been pretty well
> demonstrated take us down some pretty scary paths.
This sums up the whole anti-SL campain, which is spread FUD based on one
technically valid point; applications can't arbitrarily pass around
topology information. Applications
Tony Hain writes:
> Michael Thomas wrote:
> > ... Scoped addresses as have been pretty well
> > demonstrated take us down some pretty scary paths.
>
> This sums up the whole anti-SL campain, which is spread FUD [...]
*plonk*
Mike
--
Andrew White wrote:
> Mike Saywell wrote:
> >
> > How about using fec0:::/64? That gives a
> (probably) private
> > network per interface, the only issue is that you wouldn't
> be able to
> > aggregate them in a sizeable network - however I agree that
> site-locals
> > shouldn't be used in su
If IPv6 has a better anonymity solution, can someone point me
to it? Or do I have to start working on NATv6? (See, this is
why I don't always want to identify myself! :-)
>>>
>>> See RFC 3041 - It does exactly what you want without the
>>> drawbacks of NAT.
>>
>>
>> Actually not,
"NO -- Do not deprecate site-local unicast addressing".
- Site-locals should be retained for disconnected sites.
- Site-locals should be retained for intermittently
connected sites.
Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems
Jeroen Massar wrote:
> ...
> Talking about that, maybe a clause in some document should
> hint ISP's to start billing based on traffic consumption and
> not on IP usage. "IP usage" is a unmeasurable thing when the
> endsite gets a /48 unless the ISP is going to sniff all the
> packets and accou
Brian E Carpenter <[EMAIL PROTECTED]> wrote:
|I think we should clear the desktop first, by getting rid of ambiguous
|site-local address space, and then discuss possible new solutions.
Could you explain why you think this is the correct order? To me it seems
completely wrong. Eliminating site-l
Jeroen Massar wrote:
> ...
> Did you even _read_ the two drafts? one even has the
> word 'auto' in it. There will be no registry involved here,
> except for the one registering MAC/EUI64 or other unique
> addresses from which the automatic unique address is derived.
> No money involved there, ju
"Jeroen Massar" <[EMAIL PROTECTED]> wrote:
|[EMAIL PROTECTED] wrote:
|
|> NO - Do NOT Deprecate Site-Local Addressing.
|>
|> There are reason to use site-locals, and reason NOT to use them. But
|> "FORBIDDING" people will only alienate them and lead them to
|> find ways to do it anyway.
|>
|> P
The "anti-SL" arguments are primarily arguments aainst using ambiguous addresses.
Ambiguous addresses are a royal pain in hosts that connect to multiple sites, either
simultaneously or over time -- the applications need extra logic, and that creates
bugs. But we clearly have an issue in the case
This proposal is essentially what
draft-hinden-ipv6-global-site-local-00.txt does. I have no problem with
carving off a chunk of FEC0::/10 space for something like this, but that
approach does not solve all problems. In particular it creates an
unroutable mess for sites with a large number of subne
I agree with Michel, and hence in a way I guess I object to the
wording of the question.
Per Margaret's clarification
> People who spoke at the mike, but did not express
> an opinion during the show of hands, may express their YES/NO opinion
now
> on the list.
I'm still entitled to give a respons
Hi Alexandru,
A quick HMIPv6 comment below.
Alexandru Petrescu wrote:
Brian E Carpenter wrote:
If IPv6 has a better anonymity solution, can someone point me to it?
Or do I have to start working on NATv6? (See, this is why I don't
always want to identify myself! :-)
See RFC 3041 - It does exa
>> Michel Py wrote:
>> Yep. As I have said before, as long as CNN, Google, eBay,
>> eTrade, Yahoo and consorts are not IPv6 enabled (which
>> also means multihomed for these guys) IPv6 does not exist
>> for the general public.
> Not quite: I disagree with your last statement.
> Nothing stipulates
> Is anyone interested in pursuing this design?
Well, I have an implementation.
If Bob is happy, I'd like to grab most of his text (since it's better
written than mine) and wrap it around my bit-ordering proposal.
> - If the /16 is well known, it can be plugged as "least preferred" in
> the add
- Original Message -
From: "Christian Huitema" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Jeroen Massar" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, April 02, 2003 2:14 PM
Subject: Globally unique link prefix alternative to site-locals
> The "anti-
NO -- Do not deprecate site-local unicast addressing.
- Site-locals should be retained for disconnected sites.
- Site-locals should be retained for intermittently
connected sites.
- Site-locals should be retained as a means for internal
con
NO -- Do not deprecate site-local unicast addressing
... until such time as we have a proposed provider-independent,
administration-free allocation method for 'disconnected'
networks, perhaps GUPIs or similar.
... at which time we can do a consensus call of: "Should we
deprecate SLAs as per RFC X
From: "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]>
> status, a site-edge machine can easily tell if an
> address is 'in' or 'out' at the Application Layer.
The a PeaceKeeper (PK) by definition has a connection to both the IPv8 transport and
the IPv16 transport.
Applications know why they are u
NO -- Do not deprecate site-local unicast addressing
- Site-locals should be retained for disconnected sites.
- Site-locals should be retained for intermittently connected sites.
- Site-locals should be retained as a means for internal connections
to survive global prefix renumbering.
For those of you who are voting "no" on the question of deprecation...
I just want to reiterate something that Tony Li had mentioned (and I
hope Tony will correct me if I've lost something in the translation):
Given that if the mechanism exists we know people will develop NAT
functionality in o
Warning!!
A virus was detected in this message. The part of the message that
contained the virus has been deleted. No further action is required.
Virus: %
This message was added by the virus filtering service in place on
Sun's inbound email.
A reminder to PC users, please make sure you ar
From: "Eliot Lear" <[EMAIL PROTECTED]>
"...what is the benefit of going forward at all with IP version 6..." ???
=
IPv6 is a never-ending research project that keeps people busy while real protocol
work is done elsewhere.
Jim Fleming
http://www.IPv8.info
- Original Message -
From
"NO -- Do not deprecate site-local unicast addressing".
Daniel
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Margaret Wasserman
Sent: Wednesday, April 02, 2003 4:38 AM
To: [EMAIL PROTECTED]
Subject: CONSENSUS CALL: Deprecating Site-Local Address
Hi all,
For what it's worth, my opinion is:
"NO -- Do not deprecate site-local unicast addressing".
because:
- Site-locals should be retained for disconnected sites.
- Site-locals should be retained for intermittently
connected sites.
- Site-locals should
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
68 matches
Mail list logo
