On Thu, 13 Jun 2002, Michel Py wrote:
> > Pekka Savola wrote:
> > In addition to using a different prefix length, one could
> > also use only link-local addresses or "two /128's".
>
> I don't like the "or two /128's" part of this. Link-local addresses are
> not /128s.
Note that link-locals and t
> Pekka Savola wrote:
> In addition to using a different prefix length, one could
> also use only link-local addresses or "two /128's".
I don't like the "or two /128's" part of this. Link-local addresses are
not /128s.
Link-local addresses are technically ok. Actually, I think that they
should b
> Tony Hain wrote:
> There are uses for 1918, and life would have been good without NAT.
> We need to keep the real problem child in focus and not blame 1918
> for the transgressions of NAT.
I agree.
> Service providers and network managers clearly know the boundaries
> of their routing complex,
JJ,
> JJ Behrens wrote:
> Michael,
> I am no security wizard. However, it seems to me that you are
> suggesting that site-local addresses add a small amount of
> security because there's no way to connect directly from the
> attacker's machine to the database machine. However, if the Web
> serve
for those who care, or can do anything about it, the mail loop is
[EMAIL PROTECTED]
> Received: from patan.sun.com ([192.18.98.43])
> by psg.com with esmtp (Exim 3.36 #1)
> id 17IgtV-00065s-00
> for [EMAIL PROTECTED]; Thu, 13 Jun 2002 19:32:57 -0700
> Received: from engmail1.En
Randy Bush wrote:
> > It is time to get off this thread and back to real work.
> Those who want
> > SL removed should get 1918 moved to historic first
>
> complete red herring.
They are designed to serve the same purposes. Clearly the market has
found several uses for 1918, so claiming any of tho
> It is time to get off this thread and back to real work. Those who want
> SL removed should get 1918 moved to historic first
complete red herring.
a socially better case of this herring would be to cure world hunger first.
we may not like 1918, but that does not mean we should reproduce it to
> > Pekka Savola wrote
> > You take one approach and disregard all the others.
>
> I don't. I just say that in this scenario site-local address helps. What
> is the hacker knows the backdoor because he installed it himself and
> cannot compromise the web server? Your argument is irrelevant.
>
>
It is time to get off this thread and back to real work. Those who want
SL removed should get 1918 moved to historic first, get all products
using that off the market, then come back and raise the issue. Since we
know that won't happen, the constructive thing to do is for those that
don't think th
>> let me be clear - I usually use either /64 global address prefix, or
>> no global address (link-local only), on p2p link. both works just
>> fine.
>traceroute is my friend. this is an enemy of traceroute. and enemy of
>my friend is my enemy.
as long as the following t
> let me be clear - I usually use either /64 global address prefix, or
> no global address (link-local only), on p2p link. both works just
> fine.
traceroute is my friend. this is an enemy of traceroute. and enemy of
my friend is my enemy.
> i assign /64 global prefix
> i usually use /64 for p2p link. it works just fine, it supports
> temporary address (RFC3041) if you desire, i can think of no reason to
> use somethiing other than /64.
let me be clear - I usually use either /64 global address prefix, or no
global address (li
> Ripping site-locals out of the specs will not prevent folks who perceive
> the need for stable addresses (e.g., for internal use) from allocating
> them, especially given that ~7/8 of the IPv6 address space is held in
> reserve.
that is what folk said about chunks of v4 space and then got into
Vlad,
Not at all. The zone IDs are not included in the route
advertisement messages. That simplifies things a great deal since
you don't have to coordinate the zone IDs across a site. The zone
IDs only have meaning on the node in which they are used.
Brian
Vladislav Yasevich wrote:
>
>
> Read the latest architectural Internet doc by Bush et al.
from the credit where due department: dave meyer was the principal author
IETF IPng Working Group Mailing List
IPng Home Page: http://playground
As all know I wanted these dreaded site-locals gone since we invented them in IPv6.
This has been discussed before if we can revisit this again that is a very good thing.
Steve and Randy are 100% correct.
I would also add they break lots of stuff.
/jim
> -Original Message-
> From: Randa
> Place this in context: what we are talking about here is either a
> router-to-router tunnel or a router-to-router link. Guess what: there is
> likely to be a routing protocol there. Could you explain me how you
> configure RIP when the other router is not on the same subnet?
In all of my labs
> Your logic doesn't make sense. In fact the app that needs a fixed
> address should know that, and one that can live with a variable one
> probably has no idea what address is being used anyway.
the problem is there's a large body of code out there written
to assume fixed addresses because that'
Keith Moore wrote:
>
> > I firmly beleive that RFC3041 should be the default option
> and only the
> > nodes that require a fixed address should enable that
> option. 'Privacy'
> > should be the default option.
>
> no.
> having apps work should be the default.
> having the reasons for failure be
> get off the soap box... IPv6 requires a new API, so there is no valid
> argument that we are not changing it. If you want to argue that we
> should minimize the changes, I would agree.
believe it or not there are already lots of progams using the v6 API...
many of which were very slight modific
>get off the soap box... IPv6 requires a new API, so there is no valid
>argument that we are not changing it. If you want to argue that we
>should minimize the changes, I would agree.
no more changes, *please*. we have spent more than reasonable amount
of years to settle down to
> Ripping site-locals out of the specs will not prevent folks who perceive
> the need for stable addresses (e.g., for internal use) from allocating them,
> especially given that ~7/8 of the IPv6 address space is held in reserve.
the problem of course is that such addresses are not for internal us
Keith,
get off the soap box... IPv6 requires a new API, so there is no valid
argument that we are not changing it. If you want to argue that we
should minimize the changes, I would agree.
Tony
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Keith
Jim Bound wrote:
> with all due respect. rfc 1918 was a hack and never would pass the IESG
> today IMO they are doing a far better job these days causing us to detail
> our network views and development of protocols. 1918 has wrecked the
> Internet.
Ripping site-locals out of the specs will not
> I have also the confidence that apps that require the use of PUBLIC
> fixed addresses, will do so if we give them a uniform API to work with.
we've had that API for 20+ years now. what we're arguing about is
whether to change it. I say "no".
---
I have also the confidence that apps that require the use of PUBLIC
fixed addresses, will do so if we give them a uniform API to work with.
/aep
On Thu, 13 Jun 2002, Keith Moore wrote:
> > I firmly beleive that RFC3041 should be the default option and only the
> > nodes that require a fixed ad
> I firmly beleive that RFC3041 should be the default option and only the
> nodes that require a fixed address should enable that option. 'Privacy'
> should be the default option.
no.
having apps work should be the default.
having the reasons for failure be obvious should be the default.
having
On Thu, 13 Jun 2002, Michel Py wrote:
> > Antonio Querubin wrote:
> > Concur on both points. Just because one can assign a /64 and get
> > millions of addresses on a p2p link doesn't mean one should.
> > Furthermore, I can understand the arguments for avoiding /127 or
> > /128 but in the cases wh
Time ago i wrote a paper concerning the observability of RFC3041 and the
famous u=0 bit in the address.
http://www.it.kth.se/~aep/publications/rvk02-escuderoa.pdf
Escudero A, Requirements for unobservability of privacy extension in IPv6.
/aep
On Thu, 13 Jun 2002, Bound, Jim wrote:
> The d
Hi Jim!
If only the users that have concerns about privacy will end up using temp
addresses (RFC3041) we will end up with a minority group of techno-geeks
or as you call us 'paranoids' highly observable and easy to identify from
the crowd.
I firmly beleive that RFC3041 should be the default opt
Bill Sommerfeld wrote:
> Using AH/ESP to protect ND works fine once the SA's exist.
>
> However, there's a chicken & egg problem if you want to use IKE, and
> manually configuring N*(N-1) SA's across N machines on the link is not
> deployable.
Actually, it's worse. ND uses e.g. the solicited
> Antonio Querubin wrote:
> Concur on both points. Just because one can assign a /64 and get
> millions of addresses on a p2p link doesn't mean one should.
> Furthermore, I can understand the arguments for avoiding /127 or
> /128 but in the cases where the lost capability is a non-issue
> why bot
On Thu, 13 Jun 2002, Bound, Jim wrote:
> and that has produced horror not warm and fuzzy.
Exactly: horror to thow who know what they're about, warm and fuzzy who
think they're safe.
> > -Original Message-
> > From: Pekka Savola [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, June 13, 20
On Thu, 13 Jun 2002, Robert Elz wrote:
> From:Jun-ichiro itojun Hagino <[EMAIL PROTECTED]>
> | i can think of no reason to use somethiing other than /64.
>
> The obvious one is to conserve address space. Another is to make it
> easier to see what are p2p links from their addres
Brian
Wouldn't the Zone ID for a given site on all routers in that same site
have to be same for this to work?
-vlad
Brian Haberman wrote:
> Hi Margaret,
> I suppose that I should admit to being remiss in this area. I
> have done a fair amount of work in this area and just haven't had th
and that has produced horror not warm and fuzzy.
/jim
> -Original Message-
> From: Pekka Savola [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 13, 2002 10:02 AM
> To: Bound, Jim
> Cc: Michel Py; [EMAIL PROTECTED]; Bob Hinden; Steven M.
> Bellovin;
> [EMAIL PROTECTED]
> Subject: RE: Fw
Maybe...
/jim
> -Original Message-
> From: Brian E Carpenter [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 13, 2002 9:45 AM
> To: [EMAIL PROTECTED]
> Cc: Thomas Narten
> Subject: Re: IESG comments on
> draft-ietf-ipngwg-default-addr-select-06.txt
>
>
> JINMEI Tatuya / $B?@L
The IESG had a telechat today and discussed the WG feedback on its
request regarding draft-ietf-ipv6-default-addr-select-07.txt. Based on
the feedback, the request to prefer temporary addresses over public
addresses is withdrawn; leaving the default to prefer public addresses
is OK.
The IESG woul
> What problem are you trying to solve?
securing neighbor discovery exchanges.
> IPsec works for ND?
Using AH/ESP to protect ND works fine once the SA's exist.
However, there's a chicken & egg problem if you want to use IKE, and
manually configuring N*(N-1) SA's across N machines on the link
The default should be public. Thats the Internet way. Temp is means Temp. If you
want to make a phone call over VoIPv6 and you have a temp address my phone call could
be killed or paused waiting for renew. I find that kind of rude.
Default should be public temp should be an option.
Also gi
[I am not sure if this has been said yet, I stil have ~130 unread
messages, but...]
Tony
I strongly disagree. DNS servers function from the stand point of RRsets
not individuals RRs like A and . What you are proposing is similar
to not returning A records for a query that used IPv6 networ
Thomas,
I can't support this at my end. It should be left to configuration. All we can do is
tell users the danger (which I believe is mostly perceived) forcing people to not use
public addresses is very bad as a default. That was not what many of us bought into
when the paranoid forced us
exactly.
/jim
> -Original Message-
> From: Keith Moore [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 11, 2002 1:00 PM
> To: Steven M. Bellovin
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols
>
>
> > I think this is the key p
We
have seen this for too long. We should not wait on this SL figuring it out
anymore rip them out of IPv6.
/jim
-Original Message- [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, June 11, 2002 9:47
AMTo: [EMAIL PROTECTED];
[EMAIL PROTECTED]Subject: Re: Fwd: I
let me second that and add. Its BRAIN DEAD idea. Sorry I view code like a child.
children with sitelocals is like children on drugs to use a randy type abstraction :--)
/jim
> -Original Message-
> From: Keith Moore [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 11:14 AM
> T
we can keep link-local and not above.
/jim
> -Original Message-
> From: Derek Fawcus [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 11, 2002 4:36 PM
> To: [EMAIL PROTECTED]
> Subject: Re: IPv6 Scoped Addresses and Routing Protocols
>
>
> My view on site local addresses is a bit split.
another good point. I will have to put all this "virtual" if-then context in all the
transition code. YUCK
Come on folks lets kill them.
/jim
> -Original Message-
> From: Alain Durand [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 11, 2002 3:13 PM
> To: Randy Bush
> Cc:
randy,
I know how this must work and its even more horrifying than you might imagine.
What you have to do in a nutshell is add tons of context and management to the
implementation to note the boundaries and then the sub-boundaries as you can have in
the future org-scope, or dept-scope and on a
None that I am aware of? Putting SLs in DNS is the two-face problem and at least the
BIND code don't deal with this yet. And I don't think it should ever do this IMO.
/jim
> -Original Message-
> From: Allison Mankin [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, June 09, 2002 7:50 PM
> To:
> (though I'm not making an objection to what you're sayign) let me
> clarify the issue (mostly for myself) once more. We're perhaps mixing
> up host issues and application issues. In my understanding,
>
> 1. whether or not privacy is desired is a per-host (or
> per-administrator) issue, not
Brian,
It would not be significant to rip the site stuff out of the code as I see it.
/jim
> -Original Message-
> From: Brian Haberman [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, June 09, 2002 10:33 AM
> To: Margaret Wasserman
> Cc: [EMAIL PROTECTED]
> Subject: Re: Fwd: IPv6 Scoped Addre
Without managing protocols like icmp or mibs or something to use this then its still a
virtual abstraction in the code that must be understoond. the room for error or
isolating nodes incorrectly in a network design is very bad. In my role as consultant
to several large deployers of IPv6 with
Exactly. The entire IPv6 code base would be reduced in size and more importantly the
decision constructs and data struct lookups which is a big win.
Lets face it site-locals are very painful for real development currently and in the
long run will produce more bugs in all our products (handhelds
the market will solve the keying problem James while the IETF is still working on it
:--)
/jim
> -Original Message-
> From: James Kempf [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, June 09, 2002 2:41 AM
> To: Pekka Savola
> Cc: [EMAIL PROTECTED]
> Subject: Re: Securing Neighbor Discovery B
I don't do warm and fuzzy in the IETF. I am an engineer and architect.
I don't think this mail is even constructive below.
/jim
> -Original Message-
> From: Pekka Savola [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, June 08, 2002 6:20 AM
> To: Michel Py
> Cc: [EMAIL PROTECTED]; Bob Hinde
with all due respect. rfc 1918 was a hack and never would pass the IESG today IMO they
are doing a far better job these days causing us to detail our network views and
development of protocols. 1918 has wrecked the Internet.
/jim
> -Original Message-
> From: Steven M. Bellovin [mailto:
Michel,
Your view of planet could be the IPv4 NAT view and with true e2e with IPsec, TLS, and
many others those security interrupts and gateways that see my conversations on the
net will go away. So I don't like the way the planet is and we should change it.
/jim
> -Original Message-
Bob,
As one who has worked with you a long time and always fight to not break existing
implementations in this case I don't find your (and mine to some degree) abstracts for
site-local compelling enough. I think they are very bad and evil for the Internet too
and more importantly private ente
and this is my biggest fear for the Internet with IPv6. These site-locals could undo
all we did with IPv6 to restore end-to-end architecture for the Internet.
Trying to limit them with words or BCPs whatever will NOT prevent the potential
tragedy to our beloved Internet as Bill points out belo
link-locals should live.
site-local in this case can be multicast limited by scope that would be similar to
site-local. that is neeeded for multicast and the scope is better than the IPv6 TTL
use.
But we don't need unicast site-locals is what I support.
/jim
> -Original Message-
> Fr
ack to keith. we had to hack this in to apis. be nice if it left the api too.
/jim
> -Original Message-
> From: Keith Moore [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 07, 2002 1:17 PM
> To: [EMAIL PROTECTED]
> Cc: Keith Moore; R.P. Aditya; [EMAIL PROTECTED]
> Subject: Re: Fwd: IPv6
these are what I call "standard" Internet applications that have long lives. But a
NASTRAN MCAD network app should not being using link-local. The ones people use who
use networks and computers to run their business and most users dont see the standard
apps anymore except net admins. Go say
developers who use link-local for customer apps are going to get burned. How many apps
only run on a link? not many. if we kill all but global, mulicast, and link-local it
will be prevented by programmer ipv6 evolution.
/jim
> -Original Message-
> From: Keith Moore [mailto:[EMAIL P
Jari,
Can you be more clear. Customers are using IPsec for IPv4 just fine and now using
IPv6 in test beds. The bake-offs work.
Whats the problem.
IPR is only issue for the keying. And that the IETF has punted on IMO.
/jim
> -Original Message-
> From: Jari Arkko [mailto:[EMAIL PRO
I agree. Its just not a good use of our time or to get this spec done.
/jim
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 07, 2002 6:53 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: Mandating Route Optimization
>
>
> Hi De
James,
What is the point of this meeting. We have so many meetings to go to.
Just turn on IPsec whats not in ND to support this?
What problem are you trying to solve?
IPsec works for ND?
thanks
/jim
> -Original Message-
> From: James Kempf [mailto:[EMAIL PROTECTED]]
> Sent: Friday
one of the rare times I get randy's wisdom and agree :---)
/jim
> -Original Message-
> From: Randy Bush [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 06, 2002 2:25 PM
> To: Steven M. Bellovin
> Cc: [EMAIL PROTECTED]
> Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols
>
link-locals are different. The reason is that link-local is a control mechanisms in
the Internet architecture and gives the /etc/init of stateless addr-conf, whereas
site-local is a carry over of the band-aid of private addresses from IPv4 gone bad.
As an implementor I would love to rip out al
> And anyone who attempts to run server style apps on a host using temporary
> addresses will get all kinds of trouble anyway.
I don't believe in the client-host vs. server-host distinction.
Yes, I realize that large-scape production "servers" usually need
dedicated hardware. But there are lot
> So is it the case then that there would be no change in IPsec policy
> required for doing AAA-based or roaming consortia-based key
> management?
"policy" could mean a lot of things.
the overall architecture does not require change. the idea that there
can be more than one way to manage keys
> On Thu, 13 Jun 2002 15:45:17 +0200,
> Brian E Carpenter <[EMAIL PROTECTED]> said:
> But in fact that isn't a correct assumption. It's only a certain class of
> systems (today's pure-client style PCs or their equivalents) for which the
> privacy aspect of temporary addresses makes any s
Hi Jim,
> What is the point of this meeting. We have so many meetings to go to.
>
> Just turn on IPsec whats not in ND to support this?
>
> What problem are you trying to solve?
>
> IPsec works for ND?
>
We are interested in discussing how to secure IPv6 Neighbor Discovery in
a way that would w
On Thursday, June 13, 2002, at 09:32 AM, Pekka Savola wrote:
> On Thu, 13 Jun 2002, Alain Durand wrote:
>> On Wednesday, June 12, 2002, at 01:13 PM, Thomas Narten wrote:
>>
>>> The default-addr-select document isn't mandating the use of temporary
>>> addresses. So what is being requested here is
On Thu, 13 Jun 2002, Alain Durand wrote:
> On Wednesday, June 12, 2002, at 01:13 PM, Thomas Narten wrote:
>
> > The default-addr-select document isn't mandating the use of temporary
> > addresses. So what is being requested here is that *if* temporary
> > addresses have been implemented and are b
On Wednesday, June 12, 2002, at 01:13 PM, Thomas Narten wrote:
> The default-addr-select document isn't mandating the use of temporary
> addresses. So what is being requested here is that *if* temporary
> addresses have been implemented and are being used, *then* give them
> preference over publ
> Jim Bound wrote:
> and this is my biggest fear for the Internet with IPv6. These
> site-locals could undo all we did with IPv6 to restore end-to-end
> architecture for the Internet.
> Trying to limit them with words or BCPs whatever will NOT prevent
> the potential tragedy to our beloved Intern
> Jun-ichiro itojun Hagino wrote:
> I usually use /64 for p2p link. it works just fine, it supports
> temporary address (RFC3041) if you desire, i can think of no reason to
> use somethiing other than /64.
I agree. I think the only option is /64.
Michel.
--
On Thu, 13 Jun 2002, Bound, Jim wrote:
> I don't do warm and fuzzy in the IETF. [...]
My point exactly. I believe site-locals as a serious security measure
mainly provide a "warm fuzzy feeling" like NAT does with IPv4 today.
> > -Original Message-
> > From: Pekka Savola [mailto:[EMAI
JINMEI Tatuya / $B?@L@C#:H(B wrote:
>
> > On Wed, 12 Jun 2002 10:38:24 -0400,
> > Margaret Wasserman <[EMAIL PROTECTED]> said:
>
> >> The proposed text is trying to say that temporary addresses are preferable
> >> but that there might be issues (such as applications having problems)
>
> And to Keith - yes, apps need to get a lot smarter (or perhaps a lot dumber)
> about their use of addresses. That's true now with IPv4 - we've been using
> temporary use addresses ever since we started using dhcp for address
> assignment. Addresses come with a lease length, after which they
> |i usually use /64 for p2p link. it works just fine, it supports
> |temporary address (RFC3041) if you desire,
>Yes, no argument with any of that. As I recall, using /64 is one of
>the alternatives (to using /127 which this draft was written to discourage
>I believe) that is given.
>
> From my perspective, it is OK to prefer temporary addresses _but only if_
> using them isn't enabled by default.
I guess it depends on who does the enabling. If it's the app that does
the enabling, maybe that's okay. But I don't think it's reasonable to
let the host or site assign private sou
> Go say FTP or DNS to your private accountant, lawyer, or doctors office
> they will look at us like we have two heads.
yeah, but they do that no matter what I say to them, unless it's
"here is your money" :)
I agree that we shouldn't fall into the trap of assuming that everybody
uses the sam
> developers who use link-local for customer apps are going to get burned.
tell that to the zeroconf folks.
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive:
> link-locals are different. The reason is that link-local is a
> control mechanisms in the Internet architecture and gives the
> /etc/init of stateless addr-conf, whereas site-local is a carry
> over of the band-aid of private addresses from IPv4 gone bad.
I understand the need for LLs. But
Hello,
There appears to be something/someone looping messages back to the list.
I've received multiple copies of several mails, many of them with a double
mailing-list advertisement below.
On Mon, 10 Jun 2002, Steven M. Bellovin wrote:
> In message <002f01c210af$df9ec240$246015ac@T23KEMPF>,
Date:Wed, 12 Jun 2002 16:13:37 -0400
From:Thomas Narten <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| The default-addr-select document isn't mandating the use of temporary
| addresses. So what is being requested here is that *if* temporary
| addresses ha
Date:Thu, 13 Jun 2002 13:04:57 +0900
From:Jun-ichiro itojun Hagino <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| i usually use /64 for p2p link. it works just fine, it supports
| temporary address (RFC3041) if you desire,
Yes, no argument with an
88 matches
Mail list logo
