=> Why is it gone ? Not everyone wants NATs and for those who
do, deprecating SL addresses will not help. It will just make
their (Network admins) behaviour less predictable.
Maybe, but from a operator point of view, the advantage of
being early
on IPv6 is to enable your users to do peer-to-peer
> On Thu, 31 Oct 2002 19:38:46 -0500,
> Margaret Wasserman <[EMAIL PROTECTED]> said:
>> A BCP that discourages uses of SLs except
>> in certain narrow cases and explains why is probably more useful than a
>> BCP that tries to explain exactly when SLs cause problems and when they don't.
>>
Hi Margaret,
> - Transport Protocols (particularly the voice/session stuff)
I think Randy Stewart has some draft out on IPv6 and SCTP, which talks
about some scoping that SCTP needs, due to the support of multiple
addresses. I think it is 'IPv6 and SCTP' - that might be a useful
read fo
> Keith, can I sign you up to help with applications?
absolutely.
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com
A BCP that discourages uses of SLs except
in certain narrow cases and explains why is probably more useful than a
BCP that tries to explain exactly when SLs cause problems and when they don't.
Of course, it's quite possible to have both.
I just happen to have a somewhat incomplete document lyi
> > similarly, it's not the case that SLs only affect networks that
> > use them if SLs are widely used.
>
> => Yes, but my point is, this will happen independently
> of deprecating a bitstring. The /16 itself is meaningless;
> what we're arguing about is the use. So removing a /16
> will not
> > => Why is it gone ? Not everyone wants NATs and for those who
> > do, deprecating SL addresses will not help. It will just make
> > their (Network admins) behaviour less predictable.
>
> it's not the case that NATs only affect networks that use them.
> widespread use of NATs makes
> > => Why is it gone ? Not everyone wants NATs and for those who
> > do, deprecating SL addresses will not help. It will just make
> > their (Network admins) behaviour less predictable.
>
> Maybe, but from a operator point of view, the advantage of
> being early
> on IPv6 is to e
> > For what it's worth I agree. If we now specify a RFC1918
> > like structure for IPv6, we will be faced with people doing NAT like
> > structures - for whatever reason, and a lot of what is considered the drive
> > for IPv6 is gone.
>
> => Why is it gone ? Not everyone wants NATs an
For what it's worth I agree. If we now specify a RFC1918
like structure
for IPv6, we will be faced with people doing NAT like
structures - for
whatever reason, and a lot of what is considered the drive
for IPv6 is
gone.
=> Why is it gone ? Not everyone wants NATs and for those who
do, deprecati
> > of course, just because there are implementations of SL and that
> > customers
> > have bought those implementations doesn't mean that
> widespread use of
> > SLs
> > is something that IETF should endorse.
>
> For what it's worth I agree. If we now specify a RFC1918
> li
of course, just because there are implementations of SL and that
customers
have bought those implementations doesn't mean that widespread use of
SLs
is something that IETF should endorse.
For what it's worth I agree. If we now specify a RFC1918 like structure
for IPv6, we will be faced with pe
At Mon, 28 Oct 2002 10:31:58 -0500, Keith Moore wrote:
>
> Distributed applications depend on consistent results from DNS,
> regardless of where the query came from.
Yep. RFC 2826 discusses this in some detail.
> and what compelling purpose does all of this complexity serve?
> none that I can
a sunny day]
> -Original Message-
> From: Keith Moore [mailto:moore@;cs.utk.edu]
> Sent: Monday, October 28, 2002 12:25 PM
> To: Bound, Jim
> Cc: Keith Moore; Pekka Savola; Margaret Wasserman; Richard
> Draves; [EMAIL PROTECTED]
> Subject: Re: Node Requirements Issue
> Richard has stated he has implemented this and has customers. Lets here
> him out.
by all means, if there are good reasons to impose this considerable burden
on applications, let's hear them.
of course, just because there are implementations of SL and that customers
have bought those implem
ailto:moore@;cs.utk.edu]
> Sent: Monday, October 28, 2002 7:52 AM
> To: Pekka Savola
> Cc: Margaret Wasserman; Richard Draves; Keith Moore;
> [EMAIL PROTECTED]
> Subject: Re: Node Requirements Issue 3
>
>
> > I believe often an issue here is that OS/application
>
It has been pointed out to me that having an extensive discussion
of whether or not the IPv6 WG should limit the use of site-local
addresses to non-globally-connected networks in a lengthy thread
called "Node Requirements Issue 3" may be flying below the radar
for many IPv6 list me
> If the DNS name server is on a muti-sited host
> (which I suppose makes sense if it is performing name-to-address
> resolution for hosts which are muti-sited), then it needs to be configured
> to return different site-local addresses for each given site to which it
> is connected.
Distributed ap
and what compelling purpose does all of this complexity serve?
none that I can see.
I think that this is a key question.
Could folks who support the use of site-local addresses on
globally-connected networks explain what benefits they
offer that out-weigh the considerable costs?
Margaret
-
anything that encourages multi-faced DNS is a bad idea.
Keith
> At 02:43 AM 10/28/02, Markku Savela wrote:
>
> > > When a multi-sited implementation gets site-local addresses from
> > > the DNS (assuming that it runs two-faced DNS and returns site-locals),
> > > how will the multi-sited host kno
> > When a multi-sited implementation gets site-local addresses from
> > the DNS (assuming that it runs two-faced DNS and returns site-locals),
> > how will the multi-sited host know which site the addresses are in?
>
> My guess, and tentative implementation is that the resolver library
> complete
At 02:43 AM 10/28/02, Markku Savela wrote:
> When a multi-sited implementation gets site-local addresses from
> the DNS (assuming that it runs two-faced DNS and returns site-locals),
> how will the multi-sited host know which site the addresses are in?
My guess, and tentative implementation is
I believe often an issue here is that OS/application vendors can just bind
all the local services to nodes' site-local addresses, and make the
security someone else's (ie router vendor, because site locals must not go
out of the site) problem.
Needless to say that sounds pretty much like "NAT p
> I believe often an issue here is that OS/application vendors can just bind
> all the local services to nodes' site-local addresses, and make the
> security someone else's (ie router vendor, because site locals must not go
> out of the site) problem.
IMHO this is a really good reason for deprecat
On Sun, 27 Oct 2002, Margaret Wasserman wrote:
> Could you elaborate a bit more?
>
> Are there particular problems that would be caused by
> limiting the use of site-local addresses to non-globally-
> connected networks?
I believe often an issue here is that OS/application vendors can just bind
> When a multi-sited implementation gets site-local addresses from
> the DNS (assuming that it runs two-faced DNS and returns site-locals),
> how will the multi-sited host know which site the addresses are in?
My guess, and tentative implementation is that the resolver library
completes the scope
For a multi-sited host, one additional requirement is that applications
should deal with sockaddrs instead of directly with addresses, so that
the scope-id is preserved & passed around as needed. Another additional
requirement is routing table lookup needs to be cognizant of scoping.
When a mu
Hi Rich,
Could you elaborate a bit more?
Are there particular problems that would be caused by
limiting the use of site-local addresses to non-globally-
connected networks?
Margaret
At 12:53 PM 10/24/02, Richard Draves wrote:
This is craziness. We (I don't mean just MS) have shipping
impleme
Title: Message
> > But in routing code I would as> >
implementor check if a site came in at me and if globally connected> >
drop the packet and not let thru default route.>> This would be
relatively easy to do, I suppose
Yes but I believe we need this in products quickly if we support
Margar
I think that Margaret's proposal on site-local addresses makes a lot
of sense, and I think it's the best suggestion I've heard to date for
how we should move forward from where we are now on this issue.
IETF IPng Working Group Mai
Margaret,
I think this is the right direction. Thank you for clarifying things.
Also I support Keith point on limiting SL to sites that do not have
a transitive connection to the Internet.
- Alain.
On Friday, October 25, 2002, at 12:40 PM, Margaret Wasserman wrote:
At 12:17 PM 10/24/02, Marga
ctober 25, 2002 3:41 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Node Requirements Issue 3
> >
> >
> > At 12:17 PM 10/24/02, Margaret Wasserman wrote:
> >
> > >I think that we should keep site-local addresses in the addressing
> > >architecture,
age-
> From: Margaret Wasserman [mailto:mrw@;windriver.com]
> Sent: Friday, October 25, 2002 3:41 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Node Requirements Issue 3
>
>
> At 12:17 PM 10/24/02, Margaret Wasserman wrote:
>
> >I think that we should keep site-
> At 12:17 PM 10/24/02, Margaret Wasserman wrote:
>
> >I think that we should keep site-local addresses in the
> >addressing architecture, but limit their use to non-globally-
> >connected IPv6 networks.
>
> Some folks have pointed out that it might have been helpful if
> I had explained my reaso
> Site locals as defined in draft-ietf-ipngwg-addr-arch-v3-10.txt are
> functionally no different than RFC 1918 addresses for IPv4.
RFC 1918 addresses are intended only for isolated networks, with the
only connections to the outside world to be provided by application
level gateways.
> Long t
So, the synopsis is:
1. FE80::/10 allocation stays in addr arch
2. Text is added to the node reqs specifying single-site
behavior as the default
3. Text is added to the scoped addr arch to clearly define
the use case for scoped addresses
Yes, that sounds right
Margaret,
Margaret Wasserman wrote:
At 12:17 PM 10/24/02, Margaret Wasserman wrote:
I think that we should keep site-local addresses in the
addressing architecture, but limit their use to non-globally-
connected IPv6 networks.
Some folks have pointed out that it might have been helpful if
I
At 12:17 PM 10/24/02, Margaret Wasserman wrote:
I think that we should keep site-local addresses in the
addressing architecture, but limit their use to non-globally-
connected IPv6 networks.
Some folks have pointed out that it might have been helpful if
I had explained my reasoning...
The addr
> None of this is insurmountable. With sufficient architecture and updates
> to susceptible applications, support for multi-sited hosts can likely be
> made functional. Whether it is worth the effort is a different question,
> though, and one which only this WG can answer.
actually I doubt this
On Thu, 2002-10-24 at 12:02, Keith Moore wrote:
> we'd be far better off to deprecate site local addresses, as nobody has
> actually given a convincing case for their use.
Site locals as defined in draft-ietf-ipngwg-addr-arch-v3-10.txt are
functionally no different than RFC 1918 addresses
> How do site-locals work?
>
> For a single-sited host, I think the main requirement is
> draft-ietf-ipv6-default-addr-select-09. For applications that send
> addresses to correspondents (note this is a small minority of
> applications)
the number of applications is irrelevant. what's important
> How do site-locals work?
>
> For a single-sited host, I think the main requirement is
> draft-ietf-ipv6-default-addr-select-09. For applications that send
> addresses to correspondents (note this is a small minority of
> applications) it can get more complicated but it's still not bad - see
> kr
re;
> Margaret Wasserman
> Subject: Re: Node Requirements Issue 3
>
>
> Hi Roy,
>
> Roy Brabson wrote:
> >>This is craziness. We (I don't mean just MS) have shipping
> >>implementations that support site-locals. We have operational
> >&g
ng to which sites.
Rich
> -Original Message-
> From: Roy Brabson [mailto:rbrabson@;us.ibm.com]
> Sent: Thursday, October 24, 2002 11:32 AM
> To: Richard Draves
> Cc: [EMAIL PROTECTED]; Keith Moore; Margaret Wasserman
> Subject: RE: Node Requirements Issue 3
>
>
>
> Maybe the best way forward would be to work on a BCP on Site
> Local addresses. This could point out what site-locals are
> good for, what they are not good for and some recommendations
> on using them.
I don't think this would solve the problem that I'm concerned about -
which is that the very
n Haberman [mailto:bkhabs@;nc.rr.com]
> Sent: 24 October, 2002 23:21
> To: Richard Draves
> Cc: Keith Moore; Margaret Wasserman; [EMAIL PROTECTED]
> Subject: Re: Node Requirements Issue 3
>
>
> Rich,
> Just for my edification:
>
> 1. Who else has site-local sup
>
> I think that we should keep site-local addresses in the
> addressing architecture, but limit their use to non-globally-
> connected IPv6 networks.
>
=> Agreed. Another useful use is that long lived
connections within a site can survive renumbering.
Hesham
---
Rich,
Just for my edification:
1. Who else has site-local support?
2. Can you describe the operational deployments?
3. What applications?
Thanks,
Brian
Richard Draves wrote:
This is craziness. We (I don't mean just MS) have shipping
implementations that support site-locals
we'd be far better off to deprecate site local addresses, as nobody has
actually given a convincing case for their use.
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP a
In addition, my intuition is that we don't fully understand the impact and
effect of site-local addresses on, for example, router configuration, DNS,
addressing architecture, etc.
It would help if we had a document describing use cases and open issues
that we could discuss...
- Ralph
At 06:14
I think that we should keep site-local addresses in the
addressing architecture, but limit their use to non-globally-
connected IPv6 networks.
Margaret
At 11:02 AM 10/24/02, Keith Moore wrote:
we'd be far better off to deprecate site local addresses, as nobody has
actually given a convincing
> I think that we should keep site-local addresses in the
> addressing architecture, but limit their use to non-globally-
> connected IPv6 networks.
the problem is that even a network that isn't connected directly to
the global internet may have nodes that communicate with other nodes
that are con
This is craziness. We (I don't mean just MS) have shipping
implementations that support site-locals. We have operational
deployments using site-locals. We have applications that work just fine
with site-locals.
Rich
IETF IPng Wo
> This is craziness. We (I don't mean just MS) have shipping
> implementations that support site-locals. We have operational
> deployments using site-locals. We have applications that work just fine
> with site-locals.
indeed, some applications work just fine with them. but trying to
make applica
> This is craziness. We (I don't mean just MS) have shipping
> implementations that support site-locals. We have operational
> deployments using site-locals. We have applications that work just fine
> with site-locals.
Could you (or someone else who has this working) publish an ID which
describes
> Without standards, or at least
> standards-track IDs, its hard to see how site-locals can be viewed as
> useful beyond a single-site configuration, with anything beyond that being
> experimental and/or proprietary.
more to the point, it's not even clear that we know how to write standards
that
Hi Roy,
Roy Brabson wrote:
This is craziness. We (I don't mean just MS) have shipping
implementations that support site-locals. We have operational
deployments using site-locals. We have applications that work just fine
with site-locals.
Could you (or someone else who has this working) publish
Hi all,
> 3) How to support Site Local Addresses.
Brian Haberman said:
A node is only required to support being in 1 site. The issues with
multi-sited nodes is too complex to make a mandatory feature. By
supporting 1 site, the node can treat the site local addresses as
globals.
Bob
58 matches
Mail list logo
