On Fri, 2002-11-22 at 15:35, Michel Py wrote:
> Bob,
>
>
> (1) I am thinking about something like the default deny at the end,
> except that it would be at the beginning and would be effective even
> though there is no prefix-list applied to the peer. Something that would
> require a separate co
I think another way of looking at this is to consider the "domain of
reliability".
One of the advantages of Pekka's (auto)configured model for globally
unique site local addressing is that it doesn't make absolute guarantees
of global uniqueness. While the chance of globally unique site-local
addr
Richard,
> Richard Nelson wrote:
> It would be really nice if the "not globally routable"
> property was by some mechanism stronger than blocked by
> decree. AFter all we no that RFC1918 addresses do get
> routed sometimes by mistake, but you can't route back
> to them because of the ambiguity.
Bill,
% Michel Py wrote:
% Rationale: ambiguity is a fail-safe for routes that leak in the DFZ
even
% though they were not supposed to and for ISPs that don't filter them
% even though they were supposed to.
% If we could add to this black hole a preconfigured prefix-list for
each
% peer that woul
Bob,
> Bob Hinden wrote:
> Another router issue that gets talked around is should
> packets with site-local destination be forwarded to
> "default". Given that site-local addresses are not
> created without being configured, one approach could be
> to have a "black hole" route for FEC0::/10 preco
"Michel Py" <[EMAIL PROTECTED]> wrote:
|I agree with Charlie.
|
|There could be another model, where the end-site would request the block
|to one of their ISPs and the ISP access the IANA or RIR web site on
|behalf of the customer.
Let's not encourage ISPs to be in the address allocation business
Brian,
> Brian Zill wrote:
> We need to be careful here. In our rush to eliminate
> the bad effects of the ambiguity present in site-local
> addresses today, let's not forget that there are some
> major plusses to existing site-local addresses that
> are the result of this ambiguity:
I agree with
Kurtis,
> Kurt Erik Lindqvist wrote:
> Uhm, if they are truely unique, the only difference to
> global addresses is that they won't be routed - right?
> Now, what is the difference between that and using
> global unicast address space that you do not announce?
>From the enterprise point of view t
Steven,
>> Michel Py wrote:
>> Ambiguity is a fail-safe for routes that leak into
>> the DFZ, even though they were not supposed to, and
>> for ISPs that don't filter traffic, even though they
>> were supposed to. In order to remove ambiguity, we
>> must replace the fail-safe it provides by someth
I agree with Charlie.
There could be another model, where the end-site would request the block
to one of their ISPs and the ISP access the IANA or RIR web site on
behalf of the customer. I think that RIRs would be more comfortable with
this.
Also, there is nothing that says that we can't have bot
In your previous mail you wrote:
I see. When the mobile node has more than one pair of
home_address-care_of_address, then it won't really know which
one to pick. So, maybe, instead of exporting all this information
to the apps and giving them the control, it might be better
to en
Francis Dupont wrote:
> => last chance solutions should be marked and never get more than
> a MAY.
Indeed, the frequency parameter is tunable. There is no specification
that one HAS to use the advertisement as a beacon. You should only
do this if it is suitable for your networks. You MAY us
> In your previous mail you wrote:
>
>An alternative approach could be: If the application cares about
>the source address, it can use the Mobile IP API to figure out which
>ones are home address, which ones are care-of address, and than
>explicitly "bind" the socket to the desir
Hi Christian,
I think that we need to work on understanding the goals of globally-unique,
provider-independent addressing, so that we can properly evaluate the
different proposals that we are likely to see.
In my opinion, the addresses should be routable, although it isn't
necessary that ISPs ad
Markku Savela <[EMAIL PROTECTED]> wrote:
|> Fine by me. It's just that dealing with scopes seems to be the problem that
|> most people are complaining about rather than the existence of the addresses
|> themselves.
|
|I cannot understand those people complaining about scopes.
They are complainin
Bill Sommerfeld wrote:
>
> > 3. They cannot be externally routed (Some would
> >consider this to be a minus as well).
>
> > I believe 1 and 2 can be solved (fairly) easily by other means. The big
> > problem is number 3. The ambiguity is essential to preventing them from
> > ever being route
On Fri, 2002-11-22 at 09:34, Markku Savela wrote:
>
> > Fine by me. It's just that dealing with scopes seems to be the problem that
> > most people are complaining about rather than the existence of the addresses
> > themselves.
>
> I cannot understand those people complaining about scopes. We w
In your previous mail you wrote:
An alternative approach could be: If the application cares about
the source address, it can use the Mobile IP API to figure out which
ones are home address, which ones are care-of address, and than
explicitly "bind" the socket to the desired address. I
> (a) addresses that are global
> (b) addresses that are local, with limited reach (firewalled or
> whatever)
Of course, having only (a) would be ideal. But, this would work only
if the whole address allocation is turned upside down:
- you don't get addresses from your ISP, everyone/e
In your previous mail you wrote:
> => the problem of this API is that it is not useful because nobody wants
> to change all applications to use it. So we need also a way to change
I am not sure why you are saying that all applications needs to change
for this.
=> in order to use
In your previous mail you wrote:
We certainly don't want an unclear specification. And, if a
network manager needs to support mobile nodes on any
local domains, that network manager needs in many circumstances
to have the information that running more frequent advertisements
is ad
> Fine by me. It's just that dealing with scopes seems to be the problem that
> most people are complaining about rather than the existence of the addresses
> themselves.
I cannot understand those people complaining about scopes. We will
have
(a) addresses that are global
(b) addresses that
On Thu, 21 Nov 2002, Christian Huitema wrote:
> > I'm assuming that for the intents and purposes of replacing
> > "local" site-locals, "nearly unique" site-locals would be enough.
>
> Not quite.
Depends on what you want. (Perhaps we should try to formulate these
better first, but it's more int
Pekka Savola <[EMAIL PROTECTED]> wrote:
|> I'm all in favor of unique site locals,
|> but I don't see how they eliminate the need to deal with scopes.
|
|I'm not sure why we'd have to be able to kill scopes.
Fine by me. It's just that dealing with scopes seems to be the problem that
most peopl
> I'm assuming that for the intents and purposes of replacing
> "local" site-locals, "nearly unique" site-locals would be enough.
Not quite. You should get the slides of Rob Austein presentation to the
working group. We must really separate two issues, reachability and
ambiguity. It is very easy t
Brian Zill wrote:
>
>
> 1. They're free.
> 2. They can be (auto)configured without having
> to co-ordinate with some outside entity.
> 3. They cannot be externally routed (Some would
>consider this to be a minus as well).
>
> An IETF edict not to route some new form of
> non-ambiguous ad
On Thu, 21 Nov 2002, Dan Lanciani wrote:
> |It appears to me that we have a very obvious and clear solution here, not
> |even requiring any IANA/IESG action to get kickstarted.
>
> A solution to which problem exactly?
Look at Christian Huitema's mail today. The only thing this can't provide
Pekka Savola <[EMAIL PROTECTED]> wrote:
|I'm assuming that for the intents and purposes of replacing
|"local" site-locals, "nearly unique" site-locals would be enough.
[...]
|It appears to me that we have a very obvious and clear solution here, not
|even requiring any IANA/IESG action to get ki
Hello,
I'm assuming that for the intents and purposes of replacing
"local" site-locals, "nearly unique" site-locals would be enough.
(Actually, the change would be quite nice if implemented under fec0::/10
-- not many changes at all.)
I'd like to focus a bit on how to generate these "nearly un
Tim Chown <[EMAIL PROTECTED]> wrote:
|On Mon, Nov 18, 2002 at 10:49:42PM -0500, Dan Lanciani wrote:
|>
|> We have always been told that stable global v6 addresses will not be available
|> to end users, or at least will not be available to end users at a low cost.
|
|Told by who?
Folks on this li
> 3. They cannot be externally routed (Some would
>consider this to be a minus as well).
> I believe 1 and 2 can be solved (fairly) easily by other means. The big
> problem is number 3. The ambiguity is essential to preventing them from
> ever being routed.
so, i'm not conviced that we hav
This is a valid approach also. However, one might argue that it would
be
nice to do it the right way and make them truly unique if it is not too
much of a hassle.
Uhm, if they are truely unique, the only difference to global addresses
is that they won't be routed - right? Now, what is the diffe
On Thu, Nov 21, 2002 at 10:45:47AM -0800, Michel Py wrote:
> > Steven Blake wrote:
> > This is a business issue between customers and ISPs
> > and is none of the IETF's business IMHO.
>
> I don't think so.
>
> First, there is no business relation between the customer and the
> carrier in the mid
We need to be careful here. In our rush to eliminate the bad effects of
the ambiguity present in site-local addresses today, let's not forget
that there are some major plusses to existing site-local addresses that
are the result of this ambiguity:
1. They're free.
2. They can be (auto)configured
Charlie Perkins wrote:
Maybe it could be done almost for free.
Maybe there could be a web page under the IANA web
page where a network administrator could get the "next"
site-local prefix. This would be rate-limited so that only
a few prefixes would be given out per second, and so on.
It seems
Michel Py wrote:
>
>
> 2. Make these addresses not globally routable, not only by decree but by
> requiring them being blocked by default and also BGP routes for this
> range being rejected by default. Ambiguity is somehow a guarantee that
> these addresses are not publicly routable. If we remove
Tim Chown wrote:
>
> On Thu, Nov 21, 2002 at 12:06:36PM -0500, Richard Nelson wrote:
> > Add to free - easy to obtain for non connected sites. 1918 addresses
> > are easy to obtain.
>
> I have reservations here. I don't see how such prefixes, with the
> associated administration/registry work,
Missed your mail, Pekka otherwise I wouldn't try make the same point.
On 21-11-2002 13:56PM, "Pekka Savola" <[EMAIL PROTECTED]> wrote:
> On Thu, 21 Nov 2002, Jari Arkko wrote:
>>> Take your name, address, phonenumber or whatever (it must be long enough,
>>> though), apply a hash function and BAM
Hello Tim,
Maybe it could be done almost for free.
Maybe there could be a web page under the IANA web
page where a network administrator could get the "next"
site-local prefix. This would be rate-limited so that only
a few prefixes would be given out per second, and so on.
It seems like it wou
On Thu, 21 Nov 2002, Jari Arkko wrote:
> > Take your name, address, phonenumber or whatever (it must be long enough,
> > though), apply a hash function and BAM -- there you have "unique enough"
> > site-id identifier. No need for any registrations etc.
>
> We still need to avoid user input for se
Pekka,
> Pekka Savola wrote:
> One idea IMO is that we don't even want to be aim for
> total, provable, complete uniqueness.
> Looking at some requirements, I believe "unique enough"
> is good enough.
> Take your name, address, phonenumber or whatever (it
> must be long enough, though), apply a ha
What is the use of eliminating ambiguity *and* make sure these addresses are
not globally routable? I can only see one usage, namely: site-to-site
connections. On which there was consensus that this was not the way to go.
But perhaps there are more reasons?
In theory you are absolutely right. But
Pekka Savola wrote:
Take your name, address, phonenumber or whatever (it must be long enough,
though), apply a hash function and BAM -- there you have "unique enough"
site-id identifier. No need for any registrations etc.
We still need to avoid user input for self-configuring home networks etc
Steven,
>> Michel Py wrote:
>> 2. Make these addresses not globally routable, not
>> only by decree but by requiring them being blocked
>> by default and also BGP routes for this range being
>> rejected by default. Ambiguity is somehow a guarantee
>> that these addresses are not publicly routable.
On Thu, Nov 21, 2002 at 12:06:36PM -0500, Richard Nelson wrote:
> Add to free - easy to obtain for non connected sites. 1918 addresses
> are easy to obtain.
I have reservations here. I don't see how such prefixes, with the
associated administration/registry work, will be offered for free.
There
Hi Samita,
> I did take a look at the draft that you folks have for mobile IP
> applications.
>
> That draft gives a general overview of mobile application usage, but I
> am
> addressing a different scope (which is more equivalent to having an
> extension
> to IPv6 advanced Socket API document fo
On torsdag, nov 21, 2002, at 04:01 Europe/Stockholm, Erik Nordmark
wrote:
This assumes that ISPs will use site-locals. So far I haven't seen any
claims of benefits for ISPs to configure site boundaries and use
site-local
addresses in their network.
If the ISPs don't use it the only boundaries w
On Thu, 21 Nov 2002, Michel Py wrote:
> > Christian Huitema wrote:
> > we want to remove ambiguity, which is the root cause
> > of many problems occuring when scoped addresses leak.
>
> If we want these addresses to be used, there are two things we need to
> do:
>
> 1. Make these addresses global
Christian,
I am not disagreeing with you on this, but I do have a comment
on one point:
> * we may or may not want to prevent routing of these
> addresses between sites. I guess we should certainly prevent
> routing between non-consenting sites.
Either we should do or the other. If we create
On Thu, Nov 21, 2002 at 09:35:25AM -0800, Michel Py wrote:
> 2. Make these addresses not globally routable, not only by decree but by
> requiring them being blocked by default and also BGP routes for this
> range being rejected by default. Ambiguity is somehow a guarantee that
> these addresses
Christian,
> Christian Huitema wrote:
> we want to remove ambiguity, which is the root cause
> of many problems occuring when scoped addresses leak.
If we want these addresses to be used, there are two things we need to
do:
1. Make these addresses globally unique, which is effectively removing
a
Add to free - easy to obtain for non connected sites. 1918 addresses
are easy to obtain.
Richard
- Original Message -
From: Christian Huitema <[EMAIL PROTECTED]>
Date: Thursday, November 21, 2002 11:38 am
Subject: globally unique site local addresses
> During the WG meeting, we agreed t
Erik,
>> Michel Py wrote:
>> Where does this come from? There is nothing in Richard's
>> text that implies anything about the ISPs _using_ site
>> locals. It talks about _filtering_ them.
> Erik Nordmark wrote:
> Sorry, I meant to say "using them by configuring site
> boundaries" but I agree that
During the WG meeting, we agreed to work on the definition of a globally unqiue site
local addressing architecture, so that we can eventually deprecate site local
addresses. I am listing here so far a couple of points that were made by different
speakers, as an introduction to the debate:
* we
Hello Alper,
"Alper E. YEGIN" wrote:
>
> > I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API
> > document. The following requirements in MIPv6 spec indicates that there
> > is a need for Socket API which will allow the MIPv6 applications to
> > choose
> > COA as mobile node's
Francis Dupont wrote:
>
> In your previous mail you wrote:
>
>I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API
>document. The following requirements in MIPv6 spec indicates that there
>is a need for Socket API which will allow the MIPv6 applications to
>cho
Hello Francis,
Francis Dupont wrote:
> I agree but I have a concern to get this in an unclear spec,
> i.e., as a network manager, I'd not like to get request to put
> silly RA timing because it is written somewhere.
We certainly don't want an unclear specification. And, if a
network manager ne
> I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API
> document. The following requirements in MIPv6 spec indicates that there
> is a need for Socket API which will allow the MIPv6 applications to
> choose
> COA as mobile node's source address (in a visited network), while
> d
In your previous mail you wrote:
I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API
document. The following requirements in MIPv6 spec indicates that there
is a need for Socket API which will allow the MIPv6 applications to
choose COA as mobile node's source address
In your previous mail you wrote:
So I listened to this argument for a very long
time (too long) yesterday wondering what on earth
the big deal was. I still don't get it. If people
want to dial up the ND rate, it only hurts their
link. There's no greater internet impact that I
> > Perhaps more importantly, I don't buy the argument that *any* set of
> > addresses should be considered trustworthy, by default or otherwise.
> > Addresses are simply not sufficient as an authentication mechanism.
> > This is not a practice that IETF standards should endorse or encourage.
>
>
> I certainly agree with your first point: considering a block of addresses
> trustworthy is silly. What site locals give you is a component of "defense
> in depth": if an application listen only to a local scope addresses, it will
> not receive any packet that come directly from the Internet. Like
> > This assumes that ISPs will use site-locals.
>
> Where does this come from? There is nothing in Richard's text that
> implies anything about the ISPs _using_ site locals. It talks about
> _filtering_ them.
Sorry, I meant to say "using them by configuring site boundaries"
but I agree that it
There may be some additional discussion about the 'M' and 'O' bits during
my slot in the ipv6 WG meeting Thu AM.
- Ralph
At 12:09 PM 11/21/2002 +, Greg Daley wrote:
Hi Jim,
I find it hard to tell if you mean it is wrong (incorrect) or
wrong (not the right way to go).
about the current sta
64 matches
Mail list logo
