>Unfortunately, I can't find any indication that these concepts have been reflected
>in the current IPv6 routing protocols. None of our IPv6 routing protocol documents
>deal with site-local boundaries or SBR behaviour explicitly.
>
>There are currently four standards for how IPv6 routes will be
y the same
thing.
Mark.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, 6 June 2002 8:22
> To: Margaret Wasserman
> Cc: [EMAIL PROTECTED]
> Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols
>
>
> >Unfortu
Hi Itojun,
> in my opinion, site border routers need to have ability to run
> separate entity of RIP/OSPFv3/IS-IS for each site (don't mix them up).
> there's no need for protocol modification, since there will be no
> interaction between routes in site A and site
>I am not quite sure what you mean...
>
>Assume that I have a router with 4 interfaces (A, B, C and D) in two sites (S1 & S2),
>with
>interfaces A & B in S1, and interfaces C & D in site 2, all on an OSPF network. How
>many
>instances of OSPF would I need to run?
>
>Your message seems to indic
Hi Margaret,
>
>> NEC IX router is the only implementation supporting this, as far as
>> i know (i'm a bit embarrassed, KAME doesn't handle this - yet).
>
>Does the NEC implementation use multi-instance routing protocols? Do you
>know anyone
>on this team? Could we get them to
In message <[EMAIL PROTECTED]>, Margaret Wasserm
an writes:
>
>I sent the attached message to the routing area discussion list. I thought th
>at people on
>the IPv6 list might be interested in this discussion, so I will forward a mess
>age containing
>the responses after this one. I suppose I ju
Steve:
Having implemented SCTP and IPv6 together I could not agree with you
more.
I know in our work on scoping of addresses it got very very tricky on
attempting to figure out which set of addresses to tell the other
SCTP endpoint about to avoid black hole conditions. So in the end
the only way
> My strong preference would be to drop site-local addresses completely.
> I think they're an administrative and technical nightmare.
for that matter, so are link-local addresses. they do have some
legitimate uses, but they need to be kept to a minimum
(in both ipv6 and ipv4)
Keith
> My strong preference would be to drop site-local addresses completely.
> I think they're an administrative and technical nightmare.
trying to solve a routing problem by an ill-understood addressing
hack.
randy
IETF IPng W
> "Keith" == Keith Moore <[EMAIL PROTECTED]> writes:
>> My strong preference would be to drop site-local addresses
>> completely. I think they're an administrative and technical
>> nightmare.
Keith> for that matter, so are link-local addresses. they do have
Keith> some
Hi Margaret,
Here is the description of NEC IX router.
>> NEC IX router is the only implementation supporting this, as far as
>> i know (i'm a bit embarrassed, KAME doesn't handle this - yet).
>
>Does the NEC implementation use multi-instance routing protocols? Do you
>know any
In message <[EMAIL PROTECTED]>, Hiroki Ishibashi writes:
>Now, OSPFv3. Since it is much complicated than any RIPng, of course,
>and it has capability to run multiple processes by nature, we decided to
>run an OSPFv3 process per site. Still, we could have handle site routing
>with single OSP
> For link-local addresses, as long as the scope is
> well-defined, what are your objections?
for the most part, they're only a problem if you try to use
them in applications (where zero-configuration appliances
are an important subset of applications)
part of the problem is that the scope of li
>> For link-local addresses, as long as the scope is
>> well-defined, what are your objections?
>for the most part, they're only a problem if you try to use
>them in applications (where zero-configuration appliances
>are an important subset of applications)
>part of the problem is that the scope o
DHCPv6 currently uses a site-scoped multicast address as the default for
forwarding messages from a relay agent to servers. The relay agent can be
configured with a list of unicast addresses for servers instead of using
the site-scoped multicast address.
DHCPv6 also depends on link-local address
> >for the most part, they're only a problem if you try to use
> >them in applications (where zero-configuration appliances
> >are an important subset of applications)
> >part of the problem is that the scope of link-local addresses
> >is *not* well-defined from an application's point of view,
> >
> they are okay. the problem reside in protocols that pass IPv6
> addresses in payloads (since view of the scope is different by nodes),
> including:
i'm not saying that these protocols are bad.
s/problem reside in/site-local address does not play nicely with/
Steve,
Thanks for raising this issue on the list. I think it has been lurking for
a while.
(with no hat on)
Here is my personal explanation about why site-local addresses exist. My
intent of the email is to not take a strong position on either side.
I think the important question is the on
> Bob Hinden wrote:
> 3) Keep site-local and allow full usage
Personally, I do not see a reason not to continue in this direction (3).
There is something that bugs me, though. Last time I read it, the
allocation was as follows:
Link-local unicast 111010 FE80::/10
Site-local unicast 1110
> The outbound-only firewall is a false idea of security as well since
> 2nd generation peer-to-peer software such as Morpheus can easily
> bypass firewalls and allow ingress connections to RFC1918 hosts.
>
> On the other hand, considering that a typical IPv6 will _not_ feature
> IPv6 NAT, an IPv6
>> Michel Py wrote:
>> On the other hand, considering that a typical IPv6 will _not_ feature
>> IPv6 NAT, an IPv6 host that has _only_ a site-local address would
have
>> an extra layer of protection against external attacks as it would not
be
>> reachable at all from the outside.
> Bill Sommerfel
On Fri, 7 Jun 2002, Michel Py wrote:
> > If there is widespread deployment of systems with site-local only
> > addresses, this will in turn drive the creation of ipv6 NAT
> > specifically to give them external connectivity..
>
> That looks like a solution without a problem. To give these hosts
>
I think i was a little too subtle in my original post.
Denying external connectivity on a host-by-host basis is harder than
it looks, because if any system with external connectivity at any
layer is compromised, it can be used as a springboard to attack
"internal" systems which the firewall alleg
> Bill Sommerfeld wrote:
> Denying external connectivity on a host-by-host basis is harder
> than it looks, because if any system with external connectivity
> at any layer is compromised, it can be used as a springboard to
> attack "internal" systems which the firewall allegedly protects.
This is
> - With an RFC 1918 host behind a firewall, compromising the firewall is
> enough to grant that host outside access. Single point of failure.
>
> - With a site-local only host behind a firewall, this become a double
> hack thing: you need to reconfigure the firewall _and_ reconfigure the
> host
On Sun, 9 Jun 2002, Bill Sommerfeld wrote:
> > - With an RFC 1918 host behind a firewall, compromising the firewall is
> > enough to grant that host outside access. Single point of failure.
> >
> > - With a site-local only host behind a firewall, this become a double
> > hack thing: you need to r
Regarding "Routers must not forward any packets with site-local source or
destination addresses outside of the site." [RFC 2373] (note lower case for
"must not"): the problem is not so much a vendor problem as a deployment
problem. A router can't know when it's forwarding a packet outside of a
On Sun, 9 Jun 2002, Ralph Droms wrote:
> problem. A router can't know when it's forwarding a packet outside of a
> site unless it's been configured with information about site borders. So
> network architects and admins have to define what makes up sites and
> configure the routers at the bor
In message <[EMAIL PROTECTED]>, Pekka Savola
writes:
>On Sun, 9 Jun 2002, Ralph Droms wrote:
>> problem. A router can't know when it's forwarding a packet outside of a
>> site unless it's been configured with information about site borders. So
>> network architects and admins have to define w
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 the
time to document routing protocol behavior changes to support site
local prefixes (even though I recall telling you I was going to do it).
An
Ralph,
Ralph Droms wrote:
> And, I don't think there's a good way to define default behavior
> or auto-discovery for site-local addressing...
Well, we could very easily apply RFC 2776 to the problem. It is
already designed to advertise multicast zones. I may not help
with auto-configuring the
Steve,
"Steven M. Bellovin" wrote:
> Yah. Let's pick a prefix, and tell folks to pick a random number (more
> precisely, use an RFC 1750-compatible RNG) to fill out the rest of the
> high-order bits to a /48 or a /64. We encourage ISPs to provide real
> prefixes to companies that are using appl
Steven M. Bellovin wrote:
> In message
> <[EMAIL PROTECTED]>, Pekka Savola
> writes:
> >On Sun, 9 Jun 2002, Ralph Droms wrote:
> >> problem. A router can't know when it's forwarding a
> packet outside of a
> >> site unless it's been configured with information about
> site borders. So
> >> netwo
> Ralph Droms wrote:
> Regarding "Routers must not forward any packets with site-local source
> or destination addresses outside of the site." [RFC 2373] (note lower
> case for "must not"): the problem is not so much a vendor problem as
> a deployment problem. A router can't know when it's forwar
Hi Brian,
>That, in a nutshell, allows a single instance of RIPng to control
>the advertising of site local unicast prefixes. Though I haven't
>done the work, I would see OSPF as acting in a similar manner.
This does sound like it would work, and that similar changes would work
for other rout
Hi Tony,
>While I am all for avoiding architectural and operational pain, I don't
>see this is as big a deal as the thread seems to be making it out to be.
>There is no need for fixing the IGPs to deal with SiteLocal as they run
>within the context of the site, therefore shouldn't know about any
Hi Michel,
>The question Steve Bellovin was asking (if I interpret it correctly) is
>more or less "does anybody need site-local addresses anyway?". I do.
What do you need them for?
Margaret
IETF IPng Working Group Mailing Li
> and the
> only reason a DNS server should return an SL address is if the query was
> addressed to its SL address. Maybe this needs to be stated clearly in
> the ngtrans doc on DNS issues, but this should be obvious from the
> perspective of 'don't return an answer that can't be used'.
I wo
Margaret,
> [site-local addresses]
> What do you need them for?
In a nutshell, to put one more obstacle in the hacker's way.
I was trying to make the point that site-local addresses do provide some
extra security, compared to RFC 1918 addresses that provide only the
illusion of extra security.
In message <[EMAIL PROTECTED]>, "Tony Hain" writes
:
>
>
>While I am all for avoiding architectural and operational pain, I don't
>see this is as big a deal as the thread seems to be making it out to be.
>There is no need for fixing the IGPs to deal with SiteLocal as they run
>within the context o
Steven M. Bellovin wrote:
>In message <[EMAIL PROTECTED]>, Hiroki Ishibashi writes:
>
>>Now, OSPFv3. Since it is much complicated than any RIPng, of course,
>>and it has capability to run multiple processes by nature, we decided to
>>run an OSPFv3 process per site. Still, we could have handl
On Sun, 9 Jun 2002, Michel Py wrote:
> IPv4 / RFC1918 :
>
> - The network has a stateful firewall and uses NAT.
> - There is a web server with a public IP address in the DFZ.
> - There is a database server with an RFC 1918 address in the inside.
> - The web server needs to access
Steven M. Bellovin wrote:
> In message <[EMAIL PROTECTED]>,
> "Tony Hain" writes
> :
> >
> >
> >While I am all for avoiding architectural and operational
> pain, I don't
> >see this is as big a deal as the thread seems to be making
> it out to be.
> >There is no need for fixing the IGPs to deal wi
> On Sun, 09 Jun 2002 18:56:11 -0400,
> Margaret Wasserman <[EMAIL PROTECTED]> said:
> I'm also concerned about the complexity that site-local addressing
> adds to an IPv6 host. Looking at the default address selection rules,
> it appears that host implementations will be impacted by si
> On Sun, 09 Jun 2002 19:49:34 -0400,
> Allison Mankin <[EMAIL PROTECTED]> said:
>> and the
>> only reason a DNS server should return an SL address is if the query was
>> addressed to its SL address. Maybe this needs to be stated clearly in
>> the ngtrans doc on DNS issues, but this s
On Sat, Jun 08, 2002 at 06:38:22PM -0700, Michel Py wrote:
> - With an RFC 1918 host behind a firewall, compromising the firewall is
> enough to grant that host outside access. Single point of failure.
>
> - With a site-local only host behind a firewall, this become a double
> hack thing: you nee
> 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.
> Security is ab
Date:Sun, 9 Jun 2002 14:54:33 +0300 (EEST)
From:Pekka Savola <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Me neither. More probable outcome is that someone starts to request that
| people implement NATv6, because 1) they're already used to it (and like
On Mon, 10 Jun 2002, Michel Py wrote:
> > 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 ser
In your previous mail you wrote:
in my opinion, site border routers need to have ability to run
separate entity of RIP/OSPFv3/IS-IS for each site (don't mix them up).
there's no need for protocol modification, since there will be no
interaction between routes in s
Date:Sun, 09 Jun 2002 19:49:34 -0400
From:Allison Mankin <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I would question whether this is well-understood and DNS servers
| are ready to select which records to reply with depending
| on the address the
On Mon, 10 Jun 2002, Robert Elz wrote:
> | It's
> | just easier for people to use a global address block (even if we define
> | that address block to be 3ffe:eff3::/32 or whatever) even with these
> | "internal needs" (note: I believe there should be _something_ that does
> | not require
In your previous mail you wrote:
My strong preference would be to drop site-local addresses completely.
I think they're an administrative and technical nightmare.
=> many of us share your opinion but the other side has enough people
to make a consensus unlikely...
Margaret has po
In your previous mail you wrote:
as long as the applications are properly implemented with sockaddrs,
they are okay. the problem reside in protocols that pass IPv6
addresses in payloads (since view of the scope is different by nodes),
including:
- FTP (EP
In your previous mail you wrote:
Well, addr-arch states that routers MUST drop traffic with site-local
source address at the edge of a site.
=> yes, there is a new ICMP error for this case.
But as site is rather vaguely defined, I think many vendors just skip this
little detai
In your previous mail you wrote:
1. The RIB now contains an additional field, the zone ID. I
have done this in two different ways. The first is to add
the zone ID as a separate field. The second is to embed
the zone ID in the "unused" portion of the si
>> But as site is rather vaguely defined, I think many vendors just skip
>> this little detail..
> I disagree: we have a similar but more complex issue for multicast
> forwarding and the zone boundary check is very easy to implement
cool. how do you detect that you are at the edge of a site?
ra
Date:Mon, 10 Jun 2002 12:42:10 +0300 (EEST)
From:Pekka Savola <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Bit pattern is not relevant of course (except how it is handled by
| "legacy" implementations, which is why I tossed 3ffe:eff3::/32 in the
| air).
In message <[EMAIL PROTECTED]>, Hiroki Ishibashi writes:
>Steven M. Bellovin wrote:
>
>>I'm still confused. If a packet arrives on a site-enabled interface,
>>addressed to multicast address AllSPFRouters, and with protocol number
>>89 (OSPF), to which process is it delivered? Does something a
Date:Mon, 10 Jun 2002 12:22:54 +0200
From:Francis Dupont <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| PS: to put a random thing in the unused part of site-locals was proposed
| twice and rejected twice...
It was rejected once, when I made it, because it
> In any
> case, the only way a DNS server should return a SL in a response is if
> the query was received on a SL. This is the only reasonable way for the
> server to know if the answer is usable.
it doesn't work in general, because the query could be from a cache
that doesn't know anything abou
> Security is about plugging holes. There are hundreds to plug. Saying
> that plugging a hole is useless because some other holes might be open
> is the best way to get hacked.
that's sort of like saying that putting your finger in a crack in the dam
is useless because there are probably other cr
It's also worth pointing out that NAT is not the only way a
site-local-only system could get external connectivity.
A transport-layer gateway/relay like a socks implementation for v6 or
the KAME "faithd" would be another way..
- Bill
--
On Mon, Jun 10, 2002 at 07:43:18AM -0400, Steven M. Bellovin wrote:
> In message <[EMAIL PROTECTED]>, Hiroki Ishibashi writes:
> >Steven M. Bellovin wrote:
> >
>
> >>I'm still confused. If a packet arrives on a site-enabled interface,
> >>addressed to multicast address AllSPFRouters, and with p
An example that may be a little too contrived:
H1
|
|//
B---A
/ // \
/ |
| |
> -Original Message-
> From: Bill Fenner [mailto:[EMAIL PROTECTED]]
[...]
> It's fairly clear how to allow A and F to not advertise site-local
> addresses across the boundary (at least, as long as it coincides with
a
> routing protocol boundary, e.g. OSPF area). However, if H1 knows that
>Yes, scopes have to be convex. This is not new in IPv6.
>See section 7 of the IPv4 scoped multicast RFC (2365).
The worry is that people might look at routing protocols mechanisms
that keep the site convex wrt site-local addresses and consider
that sufficient.
draft-ietf-ipngwg-scoping-arch-0
> From: Bill Fenner [mailto:[EMAIL PROTECTED]]
[...]
> >Yes, scopes have to be convex. This is not new in IPv6.
> >See section 7 of the IPv4 scoped multicast RFC (2365).
>
> The worry is that people might look at routing protocols mechanisms
> that keep the site convex wrt site-local addresses a
I think this restriction precludes lots of real network topologies.
I also think that the wording in the spec needs to be a little more
clear that it means globally convex and not just convex with respect
to the zone-scoped addresses.
Bill
--
> > In any
> > case, the only way a DNS server should return a SL in a response is if
> > the query was received on a SL. This is the only reasonable way for the
> > server to know if the answer is usable.
>
> it doesn't work in general, because the query could be from a cache
> that doesn't kno
> > > In any
> > > case, the only way a DNS server should return a SL in a response is if
> > > the query was received on a SL. This is the only reasonable way for the
> > > server to know if the answer is usable.
> >
> > it doesn't work in general, because the query could be from a cache
> > that
On Mon, 10 Jun 2002, Robert Elz wrote:
> Date:Mon, 10 Jun 2002 12:42:10 +0300 (EEST)
> From:Pekka Savola <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
>
> | Bit pattern is not relevant of course (except how it is handled by
> | "legacy" implementations, wh
On Mon, Jun 10, 2002 at 01:45:16PM -0400, Bill Sommerfeld wrote:
> It's also worth pointing out that NAT is not the only way a
> site-local-only system could get external connectivity.
>
> A transport-layer gateway/relay like a socks implementation for v6 or
> the KAME "faithd" would be another w
In your previous mail you wrote:
| PS: to put a random thing in the unused part of site-locals was proposed
| twice and rejected twice...
It was rejected once, when I made it, because it wasn't really a very
well thought out proposal (the rejection was largely based upon
a
In your previous mail you wrote:
>> But as site is rather vaguely defined, I think many vendors just skip
>> this little detail..
> I disagree: we have a similar but more complex issue for multicast
> forwarding and the zone boundary check is very easy to implement
cool. how
On Tuesday, 06/11/2002 at 01:47ZE10, [EMAIL PROTECTED] wrote:
> Putting limited-scope addrs in DNS is a bad idea *unless*
> you have a way to uniquely identify the scope.
>
> Neither or A6 provide support for this. I made a proposal
> that would have added this to A6 *before* there was a
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
m.com writes:
>So, to make SL work, we need changes to the DNS name server, changes
>to the resolver, routers to advertise the scope zones, hosts to
>learn the scope zones from routers and include them on DDNS
>registrations and use them in makin
> faithd does NAT while changing the address family at the same time, doesn't
> it?
No doubt one of the KAME folks will correct me but my impression was
that it was more of a TCP-layer proxy rather than a layer-3 NAT.
Regardless of how it works, it's one of many ways for a
site-local-addresses
> I think this is the key point. Regardless of the possible benefits of
> site-local addresses -- and I'm willing to withhold judgment on that
> point -- we don't know in detail how to make them work. At a minimum,
> we need changes in routing and the DNS. We may need new global
> namespaces as
> In message <[EMAIL PROTECTED]>, rbrabson@us.
> ib
> m.com writes:
>
>
> >So, to make SL work, we need changes to the DNS name server, changes
> >to the resolver, routers to advertise the scope zones, hosts to
> >learn the scope zones from routers and include them on DDNS
> >registrations and
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
writes:
>
>>
>> I think this is the key point. Regardless of the possible benefits of
>> site-local addresses -- and I'm willing to withhold judgment on that
>> point -- we don't know in detail how to make them work. At a minimum,
>> we nee
> In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> rg
> writes:
> >
>
> >>
> >> I think this is the key point. Regardless of the possible benefits of
> >> site-local addresses -- and I'm willing to withhold judgment on that
> >> point -- we don't know in detail how to make them work. At
>> faithd does NAT while changing the address family at the same time, doesn't
>> it?
>No doubt one of the KAME folks will correct me but my impression was
>that it was more of a TCP-layer proxy rather than a layer-3 NAT.
exactly, it is a TCP-layer proxy with specific address handling
Date:Tue, 11 Jun 2002 11:05:25 -0400
From:"Steven M. Bellovin" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I think this is the key point. Regardless of the possible benefits of
| site-local addresses -- and I'm willing to withhold judgment on that
> That's true.Te question is really should we go ahead and figure
> out the answer, or should be just decide that we don't know the answer
> today, and consequently, we will delete the mechanism, so even if someone
> does work out the answer tomorrow, it is all irrelevant, because there's
> no
> kre wrote:
> There is way too much of the latter in all areas of the IETF these
> days. I don't know the answer to this today, so I will forbid it
> forever.
Yep. I will write a requirements draft that is impossible to meet so it
will be forbidden for ever.
> SL addresses are just fine. Mor
> 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
> 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:
> 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
gt; From: Pekka Savola [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, June 08, 2002 6:20 AM
> > To: Michel Py
> > Cc: [EMAIL PROTECTED]; Bob Hinden; Steven M. Bellovin;
> > [EMAIL PROTECTED]
> > Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols
> >
> 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
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 Addresse
below.
/jim
> -Original Message-
> From: Bill Sommerfeld [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 07, 2002 7:41 PM
> To: Michel Py
> Cc: Bob Hinden; Steven M. Bellovin; [EMAIL PROTECTED]
> Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols
>
>
den [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 07, 2002 6:57 PM
> To: Steven M. Bellovin
> Cc: [EMAIL PROTECTED]
> Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols
>
>
> Steve,
>
> Thanks for raising this issue on the list. I think it has
> been
Message-
> From: Michel Py [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 07, 2002 10:32 PM
> To: [EMAIL PROTECTED]
> Cc: Bob Hinden; Steven M. Bellovin; [EMAIL PROTECTED]
> Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols
>
>
> >> Michel Py wrote:
&g
mailto:[EMAIL PROTECTED]]
> Sent: Sunday, June 09, 2002 10:17 AM
> To: Pekka Savola
> Cc: Ralph Droms; [EMAIL PROTECTED]
> Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols
>
>
> In message
> <[EMAIL PROTECTED]>, Pekka Savola
> writes:
&
c: [EMAIL PROTECTED]; Bob Hinden; Steven M. Bellovin;
> [EMAIL PROTECTED]
> Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols
>
>
> On Fri, 7 Jun 2002, Michel Py wrote:
> > > If there is widespread deployment of systems with site-local only
> > > a
man
> Cc: Brian Haberman; [EMAIL PROTECTED]
> Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols
>
>
> >>>>> On Sun, 09 Jun 2002 18:56:11 -0400,
> >>>>> Margaret Wasserman <[EMAIL PROTECTED]> said:
>
> > I'm also concerned
principle completely.
Good diagram too.
/jim
> -Original Message-
> From: Bill Fenner [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 4:01 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols
>
>
>
> An examp
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
1 - 100 of 260 matches
Mail list logo
