Unfortunately it's too late to catch the addressing architecture
document unless we recall it from the RFC Editor and cycle it
through the IESG again. But I propose that we do exactly that,
in order to change the following paragraph in section 2.5.6:
Current text:
>Site-local addresses are de
Current text:
Hi Brian,
>Site-local addresses are designed to be used for addressing inside of
>a site without the need for a global prefix. Although a subnet ID
>may be up to 54-bits long, it is expected that globally-connected
>sites will use the same subnet IDs for site-l
Margaret Wasserman wrote:
Current text:
Hi Brian,
>Site-local addresses are designed to be used for addressing
inside of
>a site without the need for a global prefix. Although a subnet ID
>may be up to 54-bits long, it is expected that globally-connected
>sites will use t
On Tue, 12 Nov 2002, Brian Haberman wrote:
> Margaret Wasserman wrote:
> >
> >>
> >> Current text:
> >
> >
> > Hi Brian,
> >
> >> >Site-local addresses are designed to be used for addressing
> >> inside of
> >> >a site without the need for a global prefix. Although a subnet ID
> >> >
On Tue, 12 Nov 2002, Brian E Carpenter wrote:
[...]
> Otherwise, we will need a whole new RFC just for this paragraph.
>
> Alternatively, we could spend the next 5 years discussing the
> unnecessary complexities of using site-locals on connected sites.
Note that we will need at least one more RFC
aberman
> Cc: Margaret Wasserman; Brian E Carpenter; [EMAIL PROTECTED]
> Subject: Re: Proposal for site-local clean-up
>
>
> On Tue, 12 Nov 2002, Brian Haberman wrote:
> > Margaret Wasserman wrote:
> > >
> > >>
> > >> Current text:
> > >
>
Count me in on agreeing with Brian too.
Mike
Pekka Savola writes:
> On Tue, 12 Nov 2002, Brian Haberman wrote:
> > Margaret Wasserman wrote:
> > >
> > >>
> > >> Current text:
> > >
> > >
> > > Hi Brian,
> > >
> > >> >Site-local addresses are designed to be used for add
Brian E Carpenter wrote:
Unfortunately it's too late to catch the addressing architecture
document unless we recall it from the RFC Editor and cycle it
through the IESG again. But I propose that we do exactly that,
in order to change the following paragraph in section 2.5.6:
[...]
Alternati
: Tuesday, November 12, 2002 1:50 PM
> To: Brian E Carpenter
> Cc: [EMAIL PROTECTED]
> Subject: Re: Proposal for site-local clean-up
>
>
>
>
> Brian E Carpenter wrote:
>
> >Unfortunately it's too late to catch the addressing architecture
> >document un
I support this suggested course of action and the proposed new text.
- Ralph
At 01:53 PM 11/12/2002 +0100, Brian E Carpenter wrote:
Unfortunately it's too late to catch the addressing architecture
document unless we recall it from the RFC Editor and cycle it
through the IESG again. But I propose
I strongly disagree with this suggestion.
Site-local addresses (and more generally, scoped addresses) are a
fundamental part of the IPv6 architecture. They are an important
feature of IPv6, one of the great improvements that makes IPv6 better
than IPv4. It would be a serious loss to IPv6 if site
I don't really have a strong opinion one way
or the other, but I would like to make the following
observations:
- "MUST NOTs" are there for a reason, saying MUST NOT
when it can be done and protocols don't break is not
a good idea.
- People have shown that there are ways of using
site-locals f
I support this change and the new text.
Mark.
> At 01:53 PM 11/12/2002 +0100, Brian E Carpenter wrote:
> >Unfortunately it's too late to catch the addressing architecture
> >document unless we recall it from the RFC Editor and cycle it
> >through the IESG again. But I propose that we do exactly
> Unfortunately it's too late to catch the addressing architecture
> document unless we recall it from the RFC Editor and cycle it
> through the IESG again. But I propose that we do exactly that,
> in order to change the following paragraph in section 2.5.6:
>
> Current text:
>
>> Site-local addr
What Brian C., Margaret, Brian H., Pekka, Mike, Jim, Alain, Ralph,
Keith, and Mark said, but not what Brian Z. said :).
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP a
> What Brian C., Margaret, Brian H., Pekka, Mike, Jim, Alain, Ralph,
> Keith, and Mark said, but not what Brian Z. said :).
what he said
IETF IPng Working Group Mailing List
IPng Home Page: http://playground
> Randy Bush wrote:
> processwise it could be done with a note to the rfc
> editor or in the 48 hour edit call as s/he is doing
> the final edits.
Processwise a recall from the RFC editor could also be challenged all
the way to the IAB or even the ISOC and lead us to 1000+ more emails up
front and
Hi,
What they said.
I mean, I support Brian's wording change in the RFC. Being a newbie on
this list I probably shouldn't get a vote, but being a newbie I may have
a new perspective. A lot of the networking world sees IPv6 as still
thrashing and not ready for prime time. A year ag
>
> Personally, I don't have a big problem with the suggestion
> itself, but I do not agree with it, simply because it's a
> meaningless restriction. I'd rather see a
> separate BCP for this, or at least say should not and
> explain why.
>
I agree with Hesham here. Should we not explain w
Mohan Parthasarathy writes:
>
> >
> > Personally, I don't have a big problem with the suggestion
> > itself, but I do not agree with it, simply because it's a
> > meaningless restriction. I'd rather see a
> > separate BCP for this, or at least say should not and
> > explain why.
>
ber 12, 2002 11:59 AM
> To: Alain Durand; Brian E Carpenter
> Cc: [EMAIL PROTECTED]
> Subject: RE: Proposal for site-local clean-up
>
>
> OK folks I am counting and I see clear majority for margarets
> proposal?
>
> /jim
> [In matters of style, swim with the cur
he currentsin matters of principle,
> stand like a rock. - Thomas Jefferson]
>
>
> > -Original Message-
> > From: Alain Durand [mailto:Alain.Durand@;Sun.COM]
> > Sent: Tuesday, November 12, 2002 1:50 PM
> > To: Brian E Carpenter
> > Cc: [EMAIL PROT
I support this text.
should "must not" be in upper case?
>Proposed new text:
>
>Site-local addresses are designed to be used for addressing inside of
>a site which is not connected to the Internet and therefore does not
>need a global prefix. They must not be used for a site that i
> Site-local addresses (and more generally, scoped addresses) are a
> fundamental part of the IPv6 architecture. They are an important
> feature of IPv6, one of the great improvements that makes IPv6 better
> than IPv4. It would be a serious loss to IPv6 if site-local addresses
> were only allowe
> On Tue, 12 Nov 2002 13:53:00 +0100,
> Brian E Carpenter <[EMAIL PROTECTED]> said:
> Unfortunately it's too late to catch the addressing architecture
> document unless we recall it from the RFC Editor and cycle it
> through the IESG again. But I propose that we do exactly that,
> in orde
> I don't really have a strong opinion one way
> or the other, but I would like to make the following
> observations:
>
> - "MUST NOTs" are there for a reason, saying MUST NOT
> when it can be done and protocols don't break is not
> a good idea.
perhaps not, but protocols DO break when we subject
Processwise a recall from the RFC editor could also be challenged all
the way to the IAB or even the ISOC and lead us to 1000+ more emails up
front and 1 more before all the appeal processes have been
exhausted. Is this the road we are taking?
Without pointing at anyone in particular...
Why
>Unfortunately it's too late to catch the addressing architecture
>document unless we recall it from the RFC Editor and cycle it
>through the IESG again. But I propose that we do exactly that,
>in order to change the following paragraph in section 2.5.6:
>
>Current text:
>
>>Site-local addresse
I think Brian's proposal, if adopted, makes my worry about site-locals
inducing complexity in naming lookup mechanisms go away (naming mechanisms
for disconnected networks have to be different from those for connected
networks anyway).
So you can count me as supporting the proposal.
That said,
If I could sleep assured that site-locals would not be used for any
other network than networks not connected to global Internets, I would
be all for this. What still have me really worried is that there is no
way to enforce this, and it is just inviting NATv6.
In that case Brians wording wil
> There is absolutely no reason to restrict SL to disconnected sites.
Tony, we've been discussing the reasons for weeks now. It's pretty
disingeneous to say 'absolutely no reason' in the face of this.
Face it, SLs as originally conceived are broken. This is the simplest fix.
Keith
EMAIL PROTECTED]
Objet : Proposal for site-local clean-up
Unfortunately it's too late to catch the addressing architecture
document unless we recall it from the RFC Editor and cycle it
through the IESG again. But I propose that we do exactly that,
in order to change the following paragraph in sec
Keith Moore wrote:
> > There is absolutely no reason to restrict SL to disconnected sites.
>
> Tony, we've been discussing the reasons for weeks now. It's
> pretty disingeneous to say 'absolutely no reason' in the face of this.
>
> Face it, SLs as originally conceived are broken. This is the
> The fundemental issue here the architecture has been changed to support
> multiple simultanious scopes.
And it was taken too far before the consequences were understood.
Now we're fixing this bug, and it's about time.
> Those that are having a hard time figuring
> out how to do that are oppo
Keith Moore wrote:
> ...
> Why in the world you should be trying to promote dysfunction in the
> network is beyond me.
I am not promoting dysfunction, that will happen for operational /
policy reasons. I am trying to make sure that when it does happen, there
is a clearly understood mechanism fo
> > Why in the world you should be trying to promote dysfunction in the
> > network is beyond me.
>
> I am not promoting dysfunction, that will happen for operational /
> policy reasons. I am trying to make sure that when it does happen,
> there is a clearly understood mechanism for identifying
Keith Moore writes:
> Hesham writes:
> > - "MUST NOTs" are there for a reason, saying MUST NOT
> > when it can be done and protocols don't break is not
> > a good idea.
I agree with Hesham. We shouldn't be applying "MUST NOT"s to situations
where we have workable solutions. Restricting site-loca
> I agree with Hesham. We shouldn't be applying "MUST NOT"s to situations
> where we have workable solutions.
the closest thing we have to a workable solution is to find a way to
give every site that connects to another network a global prefix
(whether it's globally connected or not) and have ap
> From: Harald Tveit Alvestrand <[EMAIL PROTECTED]>
> every time we come across a case where complexity is increased by
> considering how to use site-local concurrently with global addresses (my
> favourite list starts with source address selection and DNS lookup, but
> does not end there.
--On onsdag, november 13, 2002 16:38:55 +0200 Markku Savela
<[EMAIL PROTECTED]> wrote:
(my
favourite list starts with source address selection and DNS lookup, but
does not end there.),
1. There is NO PROBLEM with source address selection.
- if your destination is site local, your sourc
Brian E Carpenter wrote:
Proposed new text:
Site-local addresses are designed to be used for addressing inside of
a site which is not connected to the Internet and therefore does not
need a global prefix. They must not be used for a site that is connected
to the Internet. Using si
> My view on this is that you need the "scoped DNS" architecture, which
> can be seens as extension to "two-faced DNS". You can have
DNS is only one of many applications that have this problem. you can't
solve the DNS problem and ignore those of the other applications.
also, scoped DNS will break
Vladislav Yasevich wrote:
>
> Brian E Carpenter wrote:
> >
> > Proposed new text:
> >
> >Site-local addresses are designed to be used for addressing inside of
> >a site which is not connected to the Internet and therefore does not
> >need a global prefix. They must not be used for a s
Keith Moore wrote:
> the closest thing we have to a workable solution is to find a
> way to give every site that connects to another network a
> global prefix
> (whether it's globally connected or not) and have applications
> ignore the SLs (at least for purpose of referrals). and if you do
>
Keith;
At 09:27 PM 11/12/02 -0500, Keith Moore wrote:
[snip snip snip]
No. Scopes reduce the ablity of the network to support apps.
They make it harder to produce an app that works independently
of network location, and they don't add a single extra capability
that wasn't present already.
You
> Keith;
>
> At 09:27 PM 11/12/02 -0500, Keith Moore wrote:
> >[snip snip snip]
> >No. Scopes reduce the ablity of the network to support apps.
> >They make it harder to produce an app that works independently
> >of network location, and they don't add a single extra capability
>
> >No. Scopes reduce the ablity of the network to support apps.
> >They make it harder to produce an app that works independently
> >of network location, and they don't add a single extra capability
> >that wasn't present already.
>
> You keep saying that some apps will fail with scoped addresses
> => I think he did to some extent, but the point
> is Brian Z. and Rich already showed how this can be
> done. Sure there is additional complexity, but
> didn't we know this 3 years ago ? I think we did.
It is simply not acceptable to expect apps to absorb all of this
complexity for the sake of t
So much traffic has flown by on this subject that my head is still spinning.
But, let me give one example in which the use of site-locals on globally
connected networks might be useful.
While at SRI International, I had the privilege of participating in a study of
autonomous teams of unmanned vehc
NOISETTE Yoann FTRD/DMI/CAE wrote:
Hi all,
I would possibly agree with this change, but it must be clear that some
ongoing work or considered solutions will be restricted or even totally
impossible after this new statement becomes effective.
For instance, draft-ietf-ipv6-dns-discovery-07.txt g
FWIW,
This study, along with others in the US Army CECOM division,
produced the transition mechansim now known as ISATAP.
Fred Templin
[EMAIL PROTECTED]
Fred L. Templin wrote:
So much traffic has flown by on this subject that my head is still
spinning.
But, let me give one example in which the
Hi Fred,
That's interesting. There has been some talk about multiple ISATAP site
routers, and scalability. Can you comment on how ISATAP performed in this
network of thousands of (mobile) hosts? (I assume you meant hundreds or
thousands, not hundreds of thousands)
Tim
On Wed, Nov 13, 2002 at
> > IMHO, it would almost be easier to remove the "must not be used" sentence
> > from the above paragraph.
>
> Yes, I like that suggestion. It's consistent with Harald's comment
> that we don't have an enforcement department.
Well, I don't think the paragraph is sufficient without it.
How abo
Michael Thomas wrote:
> So I have a question for those who support
> connected site locals: what would prevent a new
> RFC from updating Brian's wording for site locals
> (if that's the right thing)?
>
> I say this because it seems to me that there's a
> lot of issues being conflated in these argu
Tony Hain writes:
> Michael Thomas wrote:
> > So I have a question for those who support
> > connected site locals: what would prevent a new
> > RFC from updating Brian's wording for site locals
> > (if that's the right thing)?
> >
> > I say this because it seems to me that there's a
> > l
Tony,
>
> Michael Thomas wrote:
> > So I have a question for those who support
> > connected site locals: what would prevent a new
> > RFC from updating Brian's wording for site locals
> > (if that's the right thing)?
> >
> > I say this because it seems to me that there's a
> > lot of issues be
Take the case of a 20,000 node network where half are allowed global
access and half are not. It is much more complex to sort through a
10,000 node list per packet for access filtering than it would be to
have two entries, SL deny & PA allow. Yes the list of which 10,000 nodes
are allowed the gl
Mohan Parthasarathy wrote:
> > ...
> I miss something here. How do you make sure that nodes
> configure just site local and not global address on seeing an
> RA ? Are you keeping them in separate networks i.e not mixing
> nodes that require globals and site locals ? If so, then I
> can do the s
Margaret Wasserman wrote:
> ...
> How are you planning to configure and organize these 20,000 nodes?
The ones that should not have public access would be configured to only
listen for the SL prefix in an RA, or could be fed by DHCP.
>
> If the private nodes are randomly distributed around the
Keith Moore wrote:
Finally, the team as a whole is only intermittently connected to the
global Internet - perhaps with long periods of disconnected operation.
yes, intermittent connection is one of the genuinely valid justifications
for SLs.
Glad to hear you agree.
however even with intermi
> > I miss something here. How do you make sure that nodes
> > configure just site local and not global address on seeing an
> > RA ? Are you keeping them in separate networks i.e not mixing
> > nodes that require globals and site locals ? If so, then I
> > can do the same with globals with app
Tim Chown wrote:
Hi Fred,
That's interesting. There has been some talk about multiple ISATAP site
routers, and scalability. Can you comment on how ISATAP performed in this
network of thousands of (mobile) hosts?
I don't have any scaling figures from actual experiments, but scaling is
bounded
> Mohan Parthasarathy wrote:
> > > ...
> > I miss something here. How do you make sure that nodes
> > configure just site local and not global address on seeing an
> > RA ? Are you keeping them in separate networks i.e not mixing
> > nodes that require globals and site locals ? If so, then I
Roy Brabson wrote:
> ...
> So, instead of filtering global addresses at the firewall,
> you go to each
> individual box in the network which you want to restricted
> access to/from
> and configure it to only use restricted (i.e., site-local)
> addresses? And,
> as a bonus, you get to deal wit
Mohan Parthasarathy wrote:
> I agree that this is possible. But this is extra
> configuration and assumption that the restricted box IPv6
> implementation has support for such policy knobs.
Yes. It also aligns the policy implementation with the device that is
restricted, rather than trying to tr
Keith Moore wrote:
> ...
> > Even
> > when it is available, that does not automatically create a
> reason to
> > restrict the use of SL. It will always be easier to filter
> a short /10
> > than to maintain a long list of access controls at the
> border. THIS IS
> > A MAJOR OPERATIONAL REASON
> I don't know how you can get from needing a simple filter to not needing
> a filter...
> A simple example would be; as per spec, SL is blocked at the border,
> globals are allowed without restriction, and hosts that are allowed out
> have a policy that allows them to configure a global prefix alo
> Finally, the team as a whole is only intermittently connected to the
> global Internet - perhaps with long periods of disconnected operation.
yes, intermittent connection is one of the genuinely valid justifications
for SLs.
however even with intermittent connection it is often possible to use
Keith Moore wrote:
> > I don't know how you can get from needing a simple filter to not
> > needing a filter... A simple example would be; as per spec, SL is
> > blocked at the border, globals are allowed without restriction, and
> > hosts that are allowed out have a policy that allows them
> t
> One opinion. You keep saying that, but it is not requiring that the app
> work using SL across the border. In fact the reason the network manager
> likes SL is the apps will explicitly not work in that case.
Actually that's a delusion. In today's networks the apps are still
expected to "work"
> Some of the uses for SL would be better served by PI addresses, but not
> all.
>
> Take the case of a 20,000 node network where half are allowed global
> access and half are not.
yes, let's take that case. but give them all global addresses.
assign one bit in the site's portion of the address
Keith;
At 01:43 PM 11/13/02 -0500, Keith Moore wrote:
> >No. Scopes reduce the ablity of the network to support apps.
> >They make it harder to produce an app that works independently
> >of network location, and they don't add a single extra capability
> >that wasn't present already.
>
> You kee
> >example 1: Process A sends the addresses of process B to process C.
> >Processes B and C are in different scopes. (Either one might or might
> >not share a scope with A.) Process C cannot communicate with process
> >B using SLs that it has received from A.
> >
> >example 2: A sends the addre
> > If the private nodes are organized into private and public
> > subnets, so that you could use autoconfiguration with
> > site-local addresses on some networks and global addresses on
> > others, then why would you need site-locals for that? You
> > could just advertise two different global pre
> > I agree that this is possible. But this is extra
> > configuration and assumption that the restricted box IPv6
> > implementation has support for such policy knobs.
>
> Yes. It also aligns the policy implementation with the device that is
> restricted, rather than trying to track it at every e
Keith Moore writes:
> In either example the problem is solved if B and C
> have global addresses, and all referrals filter
> SL addresses.
Yes, nodes communicating globally should have global addresses, and then
there is no problem. (Although again, I think you're being overly
draconian with the
me
service ??
Did I miss something ?
Yoann
-Message d'origine-
De : Alain Durand [mailto:Alain.Durand@;Sun.COM]
Envoye : mercredi 13 novembre 2002 19:57
A : NOISETTE Yoann FTRD/DMI/CAE
Cc : [EMAIL PROTECTED]
Objet : Re: Proposal for site-local clean-up
NOISETTE Yoann FTRD/DMI/CAE wrote:
> Either way, when associated with a MANET that is currently disconnected
> from the global Internet, site-locals seem like a nice feature.
Right. But I don't know how to get arbitrary apps to work over such networks.
IETF IPng
> It aligns access policy with the device rather than a difficult to
> manage table at every edge of the network. This is much simpler at
> scale.
neither one scales well, but for many networks (those with only one
border router) you'd rather control the edge than the hosts.
ideally you want to s
> Keith Moore writes:
> > In either example the problem is solved if B and C
> > have global addresses, and all referrals filter
> > SL addresses.
>
> Yes, nodes communicating globally should have global addresses, and then
> there is no problem.
they don't need to be communicating globally, or
> It doesn't matter how many times you write this, you can not make it
> become true. Brian keeps pointing out the simple case of an
> intermittently connected network getting a different prefix on each
> connect, but you keep ignoring it. STABLE ADDRESS SPACE IS A MAJOR
> APPLICATION REASON TO HAV
> So let's not loose sight of the fact that the goal is a robust network.
well said. and offhand I don't see any reason to assume that SL addresses
are more stable/robust than globals.
IETF IPng Working Group Mailing List
IPng H
Erik Nordmark <[EMAIL PROTECTED]> wrote:
|Being the probable guilty party for introducing this thought back in
|draft-*-site-prefixes-00.txt I can offer a slightly expanded perspective.
|
|I don't think stable addresses per se is the key thing - it is
|the robustness of the communication that is i
Erik Nordmark writes:
> I don't think stable addresses per se is the key
> thing - it is the robustness of the communication
> that is important.
I agree with this. However, the minimal degree of robustness is working
at all - something which requires some address of some sort. There
needs to be
> Erik Nordmark writes:
> > I don't think stable addresses per se is the key
> > thing - it is the robustness of the communication
> > that is important.
>
> I agree with this. However, the minimal degree of robustness
> is working at all - something which requires some address of
> some sort.
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? I can see ISPs wanting to charge for extra services where th
> I agree with this. However, the minimal degree of robustness is working
> at all - something which requires some address of some sort. There
> needs to be a way to get an address when you don't have a provider.
> This means either scoped addresses as we have defined them already (and
> in mult
> Erik Nordmark <[EMAIL PROTECTED]> wrote:
>
> |Being the probable guilty party for introducing this thought back in
> |draft-*-site-prefixes-00.txt I can offer a slightly expanded perspective.
> |
> |I don't think stable addresses per se is the key thing - it is
> |the robustness of the communica
> I think, but I'm not certain, that most of the large sites
> that do this have completely different DNS content in the
> two-faces i.e. it is more like two separate DNS services than
> two-faces of the same DNS database. That is, the DNS outside
> the firewall contain a subset of the RRs and
> Yes, needless complexity is bad. But site-locals don't add any
> significant complexity to applications (which I think I've demonstated
> enough in too many emails already).
this is only true if globals are always available to any node that
potentially participates in an application that commu
Hi Jim,
> > There needs to be a way to get an address when you don't
> > have a provider. This means either scoped addresses as we
> > have defined them already (and in multi-link locations, this
> > means either site-local or multi-link subnet routers and
> > link-local), or some sort of provid
>> Ok, but it isn't clear that these two factors are of even remotely similar
>> weight. Leakage is a problem that can be addressed, but there are a lot of
>> things that simply will not work without stable addresses (at least not
>> without a complete overhaul of many higher-level protocols).
>
>
> > Yes, needless complexity is bad. But site-locals don't add any
> > significant complexity to applications (which I think I've
> demonstated
> > enough in too many emails already).
>
> this is only true if globals are always available to any node
> that potentially participates in an appli
Richard Draves writes:
> > > Yes, needless complexity is bad. But site-locals don't add any
> > > significant complexity to applications (which I think I've
> > demonstated
> > > enough in too many emails already).
> >
> > this is only true if globals are always available to any node
>
> I guess we are stuck with site local for now.
As long as we don't have a willingness to either solve the problems with
site-locals (by imposing limits on their use ) or to solve those problems
in other ways (e.g. by providing provider-independent addresses) I think
we are stuck in general. Bu
> I find this kind of thinking rather suspect. The
> question in my mind shouldn't be "why global", but
> "why not global". There seems to an underlying
> assumption that site locals would give better
> security properties due to their global
> inaccessibility. I find that rather uncompelling
> an
> So to restate - Keith, it sounds like you now agree, that with a
> reasonably small amount of additional complexity, apps can function in a
> network environment that has both globals & site-locals - subject to
> your condition about globals being available for apps that communicate
> off-site?
> > I think the vendor of one of
> > these devices should have the freedom to determine the
> device's "out
> > of the box" configuration, based on expected usage patterns.
>
> Here I strongly disagree. It's simply not reasonable in
> general for a vendor to make assumptions about the
> distr
Sorry for the delayed response - didn't see me in the to: or cc: fields.
> |In terms of the stability of the addresses one has to take into account
> |both stability as it relates to local communication and stability for
> |global communication.
>
> We have always been told that stable global v6
Hi Brian,
ACK. I get it now and agree with your point. thanks
/jim
[Honor, Commitment, Integrity]
> -Original Message-
> From: Brian Zill [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 19, 2002 5:50 PM
> To: Bound, Jim; [EMAIL PROTECTED]
> Subject: RE: Proposal
1 - 100 of 154 matches
Mail list logo
