Michel,
Thursday, April 3, 2003, 3:53:08 PM, Michel Py wrote:
>> Margaret Wasserman wrote:
>> Bill Fenner, Alex Zinin, Steve Deering, Bob Hinden and I
>> (along with a variety of other folks) spent a long time
>> discussing this in various fora of the past two years,
>> and we have not come up wit
Let's ask a different question. Would the following be acceptable:
-
The address space FEC0::/10 is reserved for non-global use. It is intended
not to be globally routeable. All routers MUST by default blackhole any
packet destined to FEC0::/10, and MAY return a 'destination unreachable'
me
> => this is like playing with UIDs, which are in the context of the
> application and can be set by set[e]uid() & co, to permit or deny access to
> privileged ports. My idea is to tune the context before performing some
> operations and to reset it after to its previous setup.
While the semantics
> > The psychological benefit of the two flags is that we don't have to choose
> > the default; we can say that any application which has an explicit preference
> > should always invoke the API to state that preference.
>
> I don't follow. This is true regardless of whether there is one bit or
> t
Hi Alper, Greg. I'm not flaming, and not try to generate any heat :-)
Greg Daley wrote:
That's right. This gives the option to use LCoA with a CN if MN
wants to. So, location privacy is an optional feature for MN to
use, unlike with the NATs.
Actually, I think that MN can decide about its use o
I was in San Francisco, but not in the room.
YES -- Deprecate site-local unicast addressing
Increases application complexity.
Reduces application reliability.
Requires too many compensating hacks to other protocols.
Note: By "Deprecate Site-Local", I mean "Do not require a
> 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
Thanks Pekka. We did get a few private comments on the revised
security considerations from Ran Atkinson, and we forgot to
acknowledge your comments, so a quick -07 revision is needed,
and then we can ask the chairs whether they are ready to
declare consensus.
Brian
Pekka Savola wrote:
>
> A
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
Julian, I think the one problem we need to avoid is
What do you do when two occurrences of FEC0::0001/64 exist
within a single routing domain?
This is the problem created by the current SL definition when
two 'sites' are united by merger or VPN and they both happen
to have a subnet #1.
We sh
This doesn't resolve the problem of ambiguous subnet prefixes
when routing domains merge. So it doesn't go far enough IMHO.
Brian
Andrew White wrote:
>
> Let's ask a different question. Would the following be acceptable:
>
> -
> The address space FEC0::/10 is reserved for non-global use
and it isn't clear how we can ever finalize the scoped
addressing architecture without some type of decision
on this issue. Perhaps we can break out the
non-contentious parts and advance those parts?
We need to break out some of it regardless. If everyone recalls,
I pointed out that pieces of
Brian,
Am Freitag, 4. April 2003 15:14 schrieb Brian E Carpenter:
> What do you do when two occurrences of FEC0::0001/64 exist
> within a single routing domain?
>
> This is the problem created by the current SL definition when
> two 'sites' are united by merger or VPN and they both happen
> t
Thomas Narten wrote:
Hi James.
However, I believe some of the resistance to deprecation may be the
result of people who have implementations and would rather not have
to pay the costs of ripping out that code and putting in something
new.
This I don't understand. AFAIK, there is little or no co
"Christian Schild (JOIN Project Team)" wrote:
>
> Brian,
>
> Am Freitag, 4. April 2003 15:14 schrieb Brian E Carpenter:
> > What do you do when two occurrences of FEC0::0001/64 exist
> > within a single routing domain?
> >
> > This is the problem created by the current SL definition when
> >
Hi Michel,
At 04:39 PM 4/3/2003 -0800, Michel Py wrote:
Unfortunately this requires people that are for IPv6 and not against and
that are willing to compromise. I regret to report that at this point I
count only three: Bob Hinden, you and me.
I find this statement highly offensive, and I completel
Hi Christian,
At 03:53 PM 4/4/2003 +0200, Christian Schild (JOIN Project Team) wrote:
I think it would be enough to come up with a BCP how to subdivide bits
11-48 in an intelligent way to prevent above. There were lots of ideas how
this could be done on this list.
We do need to define some method(
I wonder to know how to configure an IPv6 multicast address in FreeBSD so that it
could receive packets sent to the multicast address.
Thank you for your help.
Hong Liu
IETF IPng Working Group Mailing List
IPng Home Page:
> 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
> Each zone is required to be "convex" from a routing
> perspective, i.e., packets sent from one interface to any
> other interface in the same zone are never routed outside
> the zone.
>
> No one has objected to it. I have implemented the routing of
> scoped addresses. I
Thomas Narten wrote:
> ...
> I've seen it now (somewhat independently) in the zeroconf WG
> too, where similar issues have been discussed with LL
> addressing for IPv4. There are plenty of people there that
> don't see what is hard about scoping and that it's not a big
> deal to make applicatio
Alex,
> Alex Zinin wrote:
> The problem or rather inconvenience with tieing site
> boundaries and area/domain boundaries is that they
> are driven by different factors. Imagine, for instance,
> that your site that is currently implemented as an OSPF
> area is growing so big that you need to split
Erik Nordmark wrote:
Each zone is required to be "convex" from a routing
perspective, i.e., packets sent from one interface to any
other interface in the same zone are never routed outside
the zone.
No one has objected to it. I have implemented the routing of
scoped addresses.
> Correct. My statement was for the protocol, not the forwarding.
> That is why I made the follow-on comment about complexity. The
> next-hop interface's ifindex for the global destination address
> would have to be checked to ensure that it has the same zone ID
> as the interface on which the pa
> > You don't get the point. If enough hosts come programmed to enforce
> > scope restrictions, then the non compliant product ends up with a
> > deployment headache and has to be fixed. This is basically the root
of
> > Internet standards -- enforcement by peer pressure.
>
> The Globally addresse
Folks,
Here is exactly why I say that this is a consensus on vaporware:
> Harald Tveit Alvestrand wrote:
> Note: By "Deprecate Site-Local", I mean [snip]
Everyone has their own definition about what "Deprecate Site-Local"
means.
Michel.
> This should not be surprising. Given that the applications community
> blindly assumes there is a single addressing scope, when they bump
into
> the reality of the deployed network there will be problems.
Proclaiming
> that scopes are bad for applications does not make the filtering that
> causes
Erik Nordmark wrote:
Correct. My statement was for the protocol, not the forwarding.
That is why I made the follow-on comment about complexity. The
next-hop interface's ifindex for the global destination address
would have to be checked to ensure that it has the same zone ID
as the interface on w
Thomas Narten wrote:
> Dan Lanciani <[EMAIL PROTECTED]> writes:
>
> > I can't speak for others, but to me it is very interesting (and
> > important) to have internal connections that are not at the
> mercy of
> > my ISP's renumbering policy.
>
> I agree that this is a very desirable property to
> I thought the hard part about ensuring convexity wasn't about the routing
> protocol itself, but ensuring convexity in the forwarding of a packet
> with
> dst = global address assigned to site
> src = site local address
I must be missing something. There is really nothing hard about
NO -- Do not deprecate site-local unicast addressing.
They are needed for access control in enterprise (as opposed to
home/private use) networks
Tom Petch
[EMAIL PROTECTED]
-Original Message-
From: Margaret Wasserman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: 01
On Thu, Apr 03, 2003 at 03:44:29PM -0800, Michel Py wrote:
> http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-ipv6-gusl-00.txt
Comments below ;)
> Nokia should not be the only company to provide free registration; as a
> matter of fact I think it would be good to have two servers.
Surely, it w
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
On Thu, Apr 03, 2003 at 06:59:19PM -0500, Margaret Wasserman wrote:
> If the consensus to deprecate them does not hold, I'm not quite sure
> what we are going to do... We certainly don't have consensus to do
> any further work on site-locals, and it isn't clear how we can
> ever finalize the scope
"YES -- Deprecate site-local unicast addressing".
Ned
P.S. I was unable to attend the ipv6 meeting due to the conflicting
ASRG meeting.
IETF IPng Working Group Mailing List
IPng Home Page:
Christian Huitema wrote:
> ...
> Bad, bad application developers. We should really punish them! :-)
Recognizing the smile, punishment was not my point. What many are
missing here is that the perspective of a single address scope does not,
and will not match the reality of the deployed network.
>
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
This message did not go through, I'm resending it on behalf of Patrick.
- Alain.
I have been quiet on this list, but have been talking with many many
people about the view I as an application person have on Site Local.
I don't like it.
I have seen a few cases which people bring up where sit
Shannon -jj Behrens wrote:
This is fine as long as Nokia never goes out of business (I'm not
being snide, I'm being practical).
:-)
In that eventuality there's one at http://gusl.nal.motlabs.com visible
both in v4 and v6.
Not that I support gusl proposal, I must first understand it, but it
seems
>The question is:
>
> Should we deprecate IPv6 site-local unicast addressing?
>
>Valid responses are:
>
> "YES -- Deprecate site-local unicast addressing".
> "NO -- Do not deprecate site-local unicast addressing".
>
YES -- Deprecate site-local unicast addressing
Bert
-
Alex,
> So, an idea is that the location privacy might be a problem, and that
> Mobile IPv6 might offer a site-local-free solution for that problem,
> and that HMIPv6 needs site locals in order to provide a solution to
> that problem.
This is not a correct conclusion. As I have explained earlier
[This response was apparently lost, so I'm resending it.]
Thomas Narten <[EMAIL PROTECTED]> wrote:
|Dan Lanciani <[EMAIL PROTECTED]> writes:
|
|> I can't speak for others, but to me it is very interesting (and
|> important) to have internal connections that are not at the mercy of
|> my ISP's ren
Alper, I tried to draw a logic conclusion from this:
-I assumed LCoA and RCoA have same last 64 bits
-I was countered that that is not absolutely necessary, and that rfc
3041 could be used.
-I replied: yes, could, but it is not.
-I was pointed that site-locals might be used too.
-so I concluded.
Th
Dan Lanciani wrote:
[This response was apparently lost, so I'm resending it.]
We know how to achieve it. You may not like the way we achieve it because
it doesn't meet your standards for architectural purity, but until you have
a better approach, how about letting use keep our impure solutions
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
I missed the SF IETF. Here's my vote:
"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
be
Leif Johansson <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|
|>[This response was apparently lost, so I'm resending it.]
|>
|>
|>
|>We know how to achieve it. You may not like the way we achieve it because
|>it doesn't meet your standards for architectural purity, but until you have
|>a bette
YES, I'm in favor of deprecating the IPv6 site-local scope prefix fec0::.
This, in spite of the fact that we have an existing IPv6 product for
embedded systems that includes support for the site-local scope prefix, plus
places in our source code and user documentation where site-local scope is
ref
Eliot Lear <[EMAIL PROTECTED]> wrote:
> Since we have established that site-locals will encourage the use of NATs
> ('cause that's how it's done today)
Certainly a lot of people have tried to advance this proposition, but it
seems dubious to me. Site local addresses will neither encourage nor
di
Patrick wrote:
[...]
|An application *should*always* use the hostname when communicating, and
|that imply it should not cache the IP address of the peers or itself
|between the flows are initiated which it needs. Yes, applications fail
|regarding this, and IP stacks are too bad at keeping the l
YES, I'm in favor of deprecating the IPv6 site-local scope prefix fec0::.
This, in spite of the fact that we have an existing IPv6 product for
embedded systems that includes support for the site-local scope prefix, plus
places in our source code and user documentation where site-local scope is
ref
Hi,
I was at the meeting in SF, and I was one of the minority that voted
to not deprecate site-local addresses.
Well, if I am allowed to, I am now changing my vote to:
"YES -- Deprecate site-local unicast addressing".
Perhaps folks might be interested to know why I originally voted
NO,
> % > How do applications get addresses? In my experience, a lot of
> % > them get them out of the DNS. But, if we put SLs into the
> % > DNS, we have to have split DNS...
> %
> % We need to do that anyway, because there is no valid reason to leak
> % filtered addresses outside of their scope
% "YES -- Deprecate site-local unicast addressing".
%
% reasons += adds complexity to routing, forwarding, and network operations;
%
% --
% Alex Zinin
waxing nostalgic... IPv6 was supposed to be an enabler of a whole
raft of interesting new capabilities. based on your concerns,
Tony,
"Tony Hain" <[EMAIL PROTECTED]> writes:
> The discussion that should have happened first is 'what alternatives do
> we have to deal with the requirements that network managers are using SL
> to deal with?' Without a clear replacement, and with comments that some
> real problems are 'uninter
Thomas Narten wrote:
> "Tony Hain" <[EMAIL PROTECTED]> writes:
>
> > The discussion that should have happened first is 'what
> alternatives
> > do we have to deal with the requirements that network managers are
> > using SL to deal with?' Without a clear replacement, and
> with comments
> > t
[EMAIL PROTECTED] wrote:
Certainly a lot of people have tried to advance this proposition, but it
seems dubious to me. Site local addresses will neither encourage nor
discourage network address translation. And if you're going to cite
the renumbering scenario to support this idea, I suggest that
just in case folk have short memories, i am strongly against
site-locals. they attempt to solve a routing problem with
an address hack, a la rfc 1918. they are unneeded complexity.
now is the time to abjure them.
randy
IETF IP
Michel,
> Agreed. I don't like the word "area" myself in this context; I was
> simply quoting Margaret's words.
Well, it's not that I don't like the word "area" here, in fact it
would not be unreasonable to assume that people would want to map
sites to areas...
> There are plenty of other cases
% > How do applications get addresses? In my experience, a lot of
% > them get them out of the DNS. But, if we put SLs into the
% > DNS, we have to have split DNS...
%
% We need to do that anyway, because there is no valid reason to leak
% filtered addresses outside of their scope of routability
On fredag, apr 4, 2003, at 12:49 Europe/Stockholm, Bill Manning wrote:
based on your concerns, listed
above, IPv6 is going to be nothing more than IPv4 with larger address
space. if that is what we end up with, then IPv6 development might
be considered a waste of time.
> waxing nostalgic... IPv6 was supposed to be an enabler
> of a whole
> raft of interesting new capabilities. based on your
> concerns, listed
> above, IPv6 is going to be nothing more than IPv4 with
> larger address
> space. if that is what we end up with, then IPv6
Bill,
> waxing nostalgic... IPv6 was supposed to be an enabler of a whole
> raft of interesting new capabilities. based on your concerns, listed
> above, IPv6 is going to be nothing more than IPv4 with larger address
> space.
I don't believe we should do somethi
Bill Manning wrote:
> ... Even if a site uses global scope addresses for its %
> internal use nodes & applications, a name resolution that
> includes both % filtered and unfiltered addresses will cause
> applications that falsely % assume a single address scope to fail.
> %
> % Tony
>
>
Bill, I think what your missing is that to many of us, IPv6's selling
points sum up to the following two things (the others pale):
1. Large address space
2. Mobility
(1) is not necessary with site-locals. Since we have established that
site-locals will encourage the use of NATs ('cause that's
DO NOT DISCUSS THINGS IN THIS THREAD! (<-- yelling :-)).
Please change the subject.
Thanks,
Margaret
At 01:56 PM 4/4/2003 -0800, Eliot Lear wrote:
Bill, I think what your missing is that to many of us, IPv6's selling
points sum up to the following two things (the others pale):
1. Large addres
66 matches
Mail list logo
