Dan Lanciani wrote:
> |So you prove my original point, 'there is a sacred invariant, and we
> |must avoid messing with the app / transport interface at all costs'.
>
> As a practical matter, this is probably true.
Are you saying that for existing apps we can't change (in which case I
agree), or
Jeroen Massar wrote:
> [?Does this need to keep going to both [EMAIL PROTECTED] & [EMAIL PROTECTED]
>
Not as far as I am concerned. If we take the suggested path, the work is
clearly outside the IPv6 WG, and anyone on the IPv6 list that cares to
follow the discussion is now aware of it. I will be
Iljitsch van Beijnum wrote:
> The multi6 wg has been working on locator/identifier separation as a
> way to solve the multihoming in IPv6 problem for a while now.
>
> The problems we're facing (apart from the fact that there are
> many ways
> to skin this particular cat and everyone has a diffe
Jeroen Massar wrote:
> ... As far as it stands I think that HIP
> is going the best way there is. LIN6 is flawed as it won't
> scale and can't be deployed easily. Next to those I got my
> own odd idea and I will probably work it out and implement it
> as a proof of concept. Though timing on whe
[EMAIL PROTECTED] wrote:
> A very quick question about your idea. Does this layer have a
> protocol / interface to other elements on the network? Or are
> you proposing something more like an abstract API?
Simple question, complex answer ... It really depends on where you are
looking at it from
Robert Honore wrote:
> Perhaps this proposal really requires another working group or
> something.
To be clear, I was not recommending where the work get done, that is why it
was sent to the IETF list. I only cc'd the IPv6 list because it ties into
the recent discussion. In fact it is not clear
Pekka Savola wrote:
> The document assumes we need local addressing. That's
> already solutionism. Having a document which explores local
> addressing
> requirements may be OK -- but at least state it clearly and
> DON'T pretend otherwise! :-)
There is no intent to pretend. Maybe what you ar
Eliot Lear wrote:
> Brian E Carpenter wrote:
>
> > The other point that's been missed here is that the
> security-by-hiding
> > argument is only part of the story. Stable address space for
> > intermittently connected networks, unambiguous address
> space for VPNs,
> > and stable identifiers
Brian E Carpenter wrote:
> How true. I'd be more than happy to forget the hain/templin
> draft if we can get this agreed quickly. The IETF has
> developed a silly habit of getting hung up on requirements
> drafts; maybe we should just not bother.
In many cases I agree. Yet one of the justificat
Keith Moore wrote:
> You are arbitrarily calling network conditions "reality"
> without recognizing application needs as "reality". This may
> be why you persist in thinking that the problem can be fixed
> by creating an "illusion". What we need is not illusion, but
> to rearrange functionalit
Leif Johansson wrote:
> Sigh. This is almost to dumb to respond to and I'll be kicking myself
> when the
> next stats come out ;-) It is possible to build a good car lock (I
> claim) and some
> day someone will find the economic incentive to do so.
So there should be no locks on cars until someo
Leif Johansson wrote:
> Unfortunately there does not seem to be a hypertext archive
> of the list but the post was from 2003-07-08:
The manual spam filter must have fat-fingered that one into the trash ...
>
> === paf ===
>
> I don't know how to attack the people which tal
Leif Johansson wrote:
> ... Patrik posed a few direct
> questions to this effect on the list - none of which have
> been answered.
I must have missed them, so please send a pointer to the questions.
Tony
IETF IPng Working Grou
---
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tony Hain
> Sent: Friday, August 01, 2003 11:36 AM
> To: 'Steven M. Bellovin'
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: FW: AD response to Site-Local Appeal
>
>
> Steven M.
Mans Nilsson wrote:
> ... Thus, there is
> an operational requirement to remove potential sources of
> ambiguity because the usage patterns for addresses tend to
> approach a state where every service may be deployed on any
> address.
Please read the draft so that you can be on the same page a
Ralph Droms wrote:
> ...
> Certainly some of my problems with IPv4LL have resulted, as
> you suggest, from the restriction that an interface have just
> one dynamic IPv4 address at a time. I think there's more to
> the problem - my experience has been that the IPv4LL address
> is configured *s
Pekka Savola wrote:
> Hi,
>
> As some others have also commented, I have serious concerns about the
> hain/templin draft.
Thank you for providing constructive text, rather than simply complaining.
>
> An observation:
>
> This document seems to take for granted that local-use addressing is
>
Leif Johansson wrote:
> Keith Moore wrote:
>
> >On Fri, 22 Aug 2003 14:35:15 -0700
> >Fred Templin <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >>Folks - do we have consensus to accept this document as an IPv6 wg
> >>item (see below)?
> >>
> >>
> >
> >what does it mean to do this?
> >
> >
> I
In the ongoing saga about topology reality vs. application perception of
stability, it occurs to me we are not working on the right problem. In short
we have established a sacred invariant in the application / transport
interface, and the demands on either side of that interface are the root of
con
Keith Moore wrote:
> > > The fact is that the WG believes this is important
> > > discussion.
> >
> > It is an important discussion. There is a very critical
> architectural
> > point here, and it is being glossed over by 'the sky is falling'
> > claims that apps might fail, or have to do som
Bound, Jim wrote:
> The fact is that the WG believes this is important
> discussion.
It is an important discussion. There is a very critical architectural point
here, and it is being glossed over by 'the sky is falling' claims that apps
might fail, or have to do some work.
The architectural po
Keith Moore wrote:
> L3 makes routing look flat to the end systems. That's its
> job - to steer packets through the network. The network is
> aware of topology so that end systems don't have to be.
Step back from the trees and notice the forest. The L3 attachment point of
each end system is pa
Keith Moore wrote:
> > > > Expecting the network to be globally
> > > > accessable and flat is not reality.
> > >
> > > the network has never been flat in reality, but part of the
> > > purpose of IP has always been to provide the illusion of a
> > > flat network.
> >
> > That would be the purpo
Keith Moore wrote:
> for LL as currently defined, ambiguity is part of the
> equation. another kind of address might provide a way to
> resolve that ambiguity.
There is nothing about the address type the creates ambiguity. These
addresses are not meant to be used off of the current link. That me
Keith Moore wrote:
> ... What's foolish is to assume
> that everyone uses the Internet, now and in the future,
> exactly like you've seen it used within your limited experience.
Yet you want to do exactly that by insisting that all apps for all time want
to view the network as a globally flat-r
Mika Liljeberg wrote:
> > However I do think it's necessary to work out these details, and to
> > make the changes necessary, rather than simply assuming
> that one can
> > "just use LL" or "just use PI" or whatever.
>
> It would be nice to see some of this happen. While the bulk
> of the work
Keith Moore wrote:
> ...
> but let's not try to make our task even more difficult by
> insisting that apps support ambiguous addresses or addresses
> with inherently limited reachability.
For one ambiguity and reachability are different concepts, and for two there
is no ambiguity required. It ma
Keith Moore wrote:
> you know, I'm really fed up with your misrepresenting my positions.
I am not trying to misrepresent them. From my perspective, they are
frequently circular and self contradictory so I am trying to sort them out.
Tony
-
Keith Moore wrote:
> > Yet you want to ban apps from recognizing the defined flags FE80,
> > FEC0, FC00, ...
>
> more precisely, I want to discourage the expectation that
> apps can make
> do with *just* these. and if apps have more portable addresses
> available to them, why should apps deal
Keith Moore wrote:
> Too many people seem to forget that the purpose of the
> Internet is to support a diverse set of applications.
Yet you are in fact the one insisting on limiting that diversity. There is a
clear flag for the apps you seem to be focused on (ie: not equal FE80 or
FEC0 or FC00)
Keith Moore wrote:
> or to state this better, it's fine if apps simply avoid
> passing some kinds of addresses around as long as they can
> easily tell which ones to pass around and which ones to not
> pass around.
Yet you want to ban apps from recognizing the defined flags FE80, FEC0,
FC00,
Ralph Droms wrote:
> Tony - (assuming "they" == IPv6LL) can you explain why IPv6LL
> will work while "they don't work in IPv4"? My experience
> with IPv4LL has been uniformly bad; I've never intentionally
> used an IPv4LL address and the automatic assignment of an
> IPv4LL address has on sever
Keith Moore wrote:
> > > But it has turned into another absurd avoidance of basic
> > > principles because folks have their heals dug in on for
> some reason.
> >
> > Look carefully before you speak. From another perspective,
> those who
> > are insisting that IPv6 not be capable of anything mo
Bound, Jim wrote:
> I know a few of those too and it will happen today with state
> at the user level and command line interface yes. With the
> local-unicast-global address problem is gone too and LLs are
> not required. They can be annouced on ad hoc net (my
> definition previously
> stated
Bound, Jim wrote:
> I came here and asked a simple question. Look what happened.
> In industry this would be a no brainer and most would take
> your view is my opinion. Don't use these for applications.
That is one opinion. In reality industry will build what customers are
paying for. If you
Erik Nordmark wrote:
> ...
> FWIW, I think a multi6 solution with id/loc separation will
> make the local addressing concerns go away.
Well a 'solution' might do that, but I don't see one happening in our
lifetimes. Any separation will require a mapping infrastructure to
dynamically bind the val
Kurt Erik Lindqvist wrote:
> ... There
> are a number of ways that we have changed HOW things are
> done, but it's
> still the same things.
That statement exposes the problem here. Some people want to make sure that
IPv6 does *exactly* the same things that IPv4 does, while others want IPv6
to d
Bound, Jim wrote:
> ...
> The solution that will work for now is make a statement in the
> IETF and in industry IPv6 implementation documentation that
> link-local addresses SHOULD not be used as an IPv6 address
> type by applications.
Jim, this is simply pointless. I haven't gotten through a
Forming a WG to fantasize about renumbering will not suddenly remove the
edge network manager's requirement for stable address space. The only way
this comes close to being an Ops problem is due to the lack of reliability &
scale in DNS. As long as end users feel that name resolution is
insufficien
Eliot Lear wrote:
> Tony Hain wrote:
> > Assuming 'inherently' means 'well-known', yes it is true
> that manually
> > configured filtering does not *require* a well-known prefix. It is
> > also true that automation is required for consumers. Just
Alain Durand wrote:
> So what we have here is a case where you are multihomed with
> one side that is permanently unreachable from a large portion
> of the universe.
The only difference between this and the case for > 90% of the deployed end
systems today is the multihoming. Using PA addresses w
Keith Moore wrote:
> Anything that involves ambiguous addresses will cause problems.
Please read
http://www.ietf.org/internet-drafts/draft-hain-templin-ipv6-limitedrange-00.
txt and note there is no requirement for ambiguous addresses. Please read
http://www.ietf.org/internet-drafts/draft-hinden-
Leif Johansson wrote:
> Listen Andrew, I am sort of impressed by your tennacity (if
> that is the
> word I
> am looking for) but writing a loop through a table does not quite
> constitute
> "running code". You actually need to use this in an application and
> demonstrate
> its utility on the In
Pekka Savola wrote:
> Why exactly is advertising the aggregate a problem? The
> nodes will filter
> out those sources they are auto-configured not to speak to
> before even
> seeing any maliscious packets.
You clearly trust your filter configuration manager. Not everyone does, and
there is am
Mark Smith wrote:
> ...
> > So is this a statement that the approach is not useful in
> government
> > networks, or a statement that the tool is inadequate
> because it does
> > not solve the government network problems?
> >
>
> I think it is inadequate, because it doesn't provide the
> reso
Michael Thomas wrote:
> The few self-described apps people I've seen take
> a stand have to my recollection been strongly
> against dealing with locally scoped addresses .
>
> Have I missed anybody? It seems to me that people
> with strong app and/or host kernel background
> ought to be given a di
Keith Moore wrote:
> > > Since IPv6 prefixes are going to be mapped along the same
> > > boundaries as IPv4 prefixes ie., layer 2 broadcast domains,
> > > IPv6 route filtering in an government network will be just as
> > > dull a tool as it is in IPv4.
> >
> > This shows IPv4 thinking, where th
Keith Moore wrote:
> > > there is no justification for the idea that internal-use
> > > applications have a greater need for stability than other
> > > applications.
> >
> > Not in an academic environment, but when people's jobs are
> on the line
> > they tend to set the bar *much* higher.
>
>
Mark Smith wrote:
> True, but in my experience in a large, multi-departmental
> govenment network, is it fairly common that end user security
> / access requirements don't fall neatly along route / prefix
> boundaries. Typically this is because security has crept into
> the network, triggered b
Leif Johansson wrote:
> You should spend some time in the academic world. In most
> countries the academic institutions are essentially companies
> offering education and research on a competitive market.
> There is not inherent difference and real money is just as
> much at stake.
I have been
Andrew White wrote:
> ...
> > I would like to point out again, that as per my suggestion,
> nodes MUST
> > NOT send, receive or forward traffic in which the source and
> > destination addresses are not of the same scope.
>
> I think this is unnecessarily stringent. Certainly nodes
> should pr
Alain Durand wrote:
> You're asking the DNS views to be in sync with the routing
> views. Possible to achieve at a cost if there is one local
> and one global view, as it is current practise with two-fade
> DNS, but much harder when you have n enterprise networks
> joining to create an extranet
Eliot Lear wrote:
> Tony Hain wrote:
> > There are some historic 'lessons learned' included here,
> but the real
> > issue is meeting the expectations of the network managers who are
> > currently using IPv4 logic. That is not to say we don't
> wan
Mans Nilsson wrote:
> By forcing the end user to NAT and hide things behind a
> "broadband router"
> or similar device, you now give the attacker one convenient weak spot
> which, once attacked and brought to its knees, will deny
> every node in the
> house network service, especially since th
Michael Thomas wrote:
> The problem is that this draft proceedes from the
> premise that the answer is consing up limited
> range addresses.
It is not intended to. It is trying to point out the requirements that
network managers have. It uses examples where they have found limited range
addresses
August 05, 2003 12:02 PM Keith Moore wrote:
> I concur. A real story for renumbering is probably the
> biggest "missing piece" of the IPv6 puzzle, and we need to be
> devoting our energies to solving this important problem
> rather than to propagating past errors.
August 05, 2003 12:29 PM K
Eliot Lear wrote:
> > Like it or not, it is accepted
> > security practice to limit access by filtering on bits in the IP
> > header, and restricting what prefixes are announced in routing
> > protocols.
>
> But that filtering is done EXPLICITLY based on a PARTICULAR
> device in a
> PARTICULAR
Leif Johansson wrote:
> Of course we filter -
What is your requirement to do that? I am serious, because those are the
things the current draft is trying to document. If it is not covered by the
current text, please send details.
> but we don't NAT!
I never said NAT was a good thing, in fact I
Leif Johansson wrote:
> Tony Hain wrote:
>
> >Leif Johansson wrote:
> >
> >
> >>Of course we filter -
> >>
> >>
> >
> >What is your requirement to do that? I am serious, because those are
> >the things the current draf
Keith Moore wrote:
> there is no justification for the idea that internal-use
> applications have a greater need for stability than other
> applications.
Not in an academic environment, but when people's jobs are on the line they
tend to set the bar *much* higher. One example of an app that requ
Eliot Lear wrote:
> ...
> >>>Failing such, we seem to have limited
> >>>range addressing
> >>>and "graceful" renumbering as alternative options. Perhaps
> >>
> >>there are
> >>
> >>>others also?
> >>
> >>Yes: a default address, which is different from a limited
> >>range address. The default addres
Alain Durand wrote:
> I'm affraid you're overlooking the impact on address selection here.
Back to the flat earth concept ...
Insisting on a single address per interface is the only way to avoid address
selection. Until we have a globally routed PI space we know there will be
multiple PA addresse
[EMAIL PROTECTED] wrote:
> You are assuming that there is only one boundary in that
> consumers house.
No, I am assuming there is at least one boundry between the consumer and
other networks.
> I can
> assure you that the teenage daugther or son in that house will have a
> completely differe
a while.
>
> paf
>
> On onsdag, aug 6, 2003, at 11:04 Europe/Stockholm, Patrik Fältström
> wrote:
>
> > On onsdag, aug 6, 2003, at 02:05 Europe/Stockholm, Tony Hain wrote:
> >
> >> From the operator perspective, the demand is for address
> spac
Brian E Carpenter wrote:
> 3. I feel strongly that this absolutely needs to be a
> one-time fee. The idea of constructing an artificial service
> industry to maintain an annual registration system for random
> numbers is plain wasteful.
Well a database with stale information is of no value eith
Brian E Carpenter wrote:
> I share Tony's frustration with long hiatus in multi6, but it
> seems to be unstuck at the moment. I also agree that it's
> hard to separate the topics, but I see no practical advantage
> in repatriating the multihoming issue into this WG, which
> already has a divers
Brian E Carpenter wrote:
> ...
> > The requirement was met fine by the SL prefix; the only reason they
> > still are ambiguous is because both Bob and I put our
> drafts to remove
> > ambiguity from SLs on the back burner due to the deprecation
> > situation.
>
> Sure, at one level it doesn't
Keith Moore wrote:
> ...
> I think the requirement is better stated that apps (not just
> local apps) continue to operate independent of any normal
> address change events, whether or not at the SP edge.
Nice goal, but requires changes to transport to pull it off. The point is to
deliver service
Hans Kruse wrote:
> ...
> and in draft-hain-templin-ipv6-limitedrange-00.txt
>In the simple case, hosts that are allowed external access have a
>policy that allows them to configure both global and limited range
>prefixes, while those that are not allowed global access have a
>polic
Check
http://www.ripe.net/ripencc/mem-services/registration/ipv6/ipv6allocs.html
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Leonardo
> Saavedra Henriquez
> Sent: Thursday, August 07, 2003 4:24 PM
> To: [EMAIL PROTECTED]
> Subject: RFC 2928
>
Eliot Lear wrote:
> ...
> No, I think that given today's technology I
> believe we need
> stable addresses so that lack of connectivity does not cause internal
> transport connections to fail.
?!?
> Yes, I wonder whether this could be
> sufficiently handled by minimum length leases that a
Brian E Carpenter wrote:
> ...
> > No, a link must be wholly contained within a site, and by
> definition
> > anything that is less than global fits wholly within global. Yes
> > multiple local regions can overlap, but that does not
> invalidate the
> > overall model.
>
> I think it does, bec
Keith Moore wrote:
> Tony,
>
> there was strong concensus in the WG to deprecate SL.
No, there was a question asked where there would be multiple undefined
meanings for a Yes vote, and multiple undefined meanings for a No vote.
Basically a blank check for the chair to tell the WG what it had dec
Pekka Savola wrote:
> So, what exactly is wrong with the Bellovin/Zill Router
> Advertisement option proposals which make it very easy for
> normally local-only appliances to restrict the nodes they
> allow access from?
For the function it performs, nothing. What it lacks is a prefix space to
a
Brian E Carpenter wrote:
> Well, here's my attempt at becoming flame bait :-)
>
> I'm close to concluding that address scope is simply a bogus concept.
>
> 1. We've been arguing about it for years and have reached no
> sort of consensus. That suggests to me that there is in fact
> no consensus
Margaret Wasserman wrote:
> At 10:26 AM 8/7/2003 -0700, Tony Hain wrote:
> > > Right now I cannot find a single application where locally scoped
> > > addresses give me anything worth the effort. Those are my
> 5 cents -
> > > since you asked for
> > >
Andrew,
Would you mind if we put this sequence in the requirements doc?
Tony
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrew White
> Sent: Wednesday, August 06, 2003 6:55 PM
> To: IPng
> Subject: Real life scenario - requirements (local ad
Patrik Fältström wrote:
> On onsdag, aug 6, 2003, at 02:05 Europe/Stockholm, Tony Hain wrote:
>
> > From the operator perspective, the demand is for address
> space that is
> > architecturally set aside as private use, locally
> controlled. That did
> > no
Leif Johansson wrote:
> Yet another old argument. I remember several opposing voices
> from the SL
> debate.
Appearing to be primarily from service providers. By my count most of the no
voters were from edge focused people.
> I am running a large edge network. I have both PI and PA v4 and yet
Eliot Lear wrote:
> Hello,
>
> I've read over this draft, and I find it very confusing. The
> title of
> the draft is "Limited Range Addressing Requirements".
> However, as one
> goes through the document, there is both justification and
> requirements.
> What time is spent on the justif
Alain Durand wrote:
> ...
> IMHO, what need to happen is the following:
>
> -1. Make an in-depth study of the consequences of introducing
> addresses with different ranges.
This is not an introduction, they happened long ago ...
>
> -2. Realize that if the issue at stake here has more to
Given the requirements from edge network managers I have talked to, I would
prefer C, but could live with B.
Tony
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Bob Hinden
> Sent: Monday, August 04, 2003 11:07 AM
> To: [EMAIL PROTECTED]
> Cc: [EM
kre wrote:
>
> | All documents produced as part of this course of action will
> | be subject to discussion by the WG, and they will go through
> | WG last call, etc. In keeping with normal IETF processes,
> | these documents won't be sent to the IESG unless they
> | represent the co
Steven M. Bellovin wrote:
> Tony -- to make life easier for all concerned, please state
> explicitly
> what recourse you're asking for from the IESG. As things stand now,
> even if we agreed with everything you say, we wouldn't know exactly
> what you want us to do.
I thought I did:
'The de
George Michaelson wrote:
> ...
> > What is special about a number allocated by
> the "blessed
> > agency" in the case we're discussing?
>
> Strong admission checks into routing are going to make Joe's
> numbers less useful.
Admission checks by which authority? Remember we are talking about
pr
Margaret,
I am not trying to twist words, I am reflecting what I hear as it
applies to the reality of the deployed network. Our primary disagreement
is over process. Forgive me but I can't figure out the technical
differences that exist, because at this point it is not clear to me what
you believe
Margaret Wasserman wrote:
> ...
> What we _really_ want is to achieve all three of the
> following things simultaneously:
>
> - All addresses are globally routable (note that this doesn't
> preclude filtering some addresses or
> address/port combos).
> - Addres
Randy Bush wrote:
> just in case folk have short memories, i am strongly against
> site-locals. they attempt to solve a routing problem with an
> address hack, a la rfc 1918. they are unneeded complexity.
> now is the time to abjure them.
They solve an addressing problem PI, where other propo
Thomas Narten wrote:
> "Tony Hain" <[EMAIL PROTECTED]> writes:
>
> > The discussion that should have happened first is 'what
> alternatives
> > do we have to deal with the requirements that network managers are
> > using SL to deal with?&#x
Bill Manning wrote:
> ... Even if a site uses global scope addresses for its %
> internal use nodes & applications, a name resolution that
> includes both % filtered and unfiltered addresses will cause
> applications that falsely % assume a single address scope to fail.
> %
> % Tony
>
>
Christian Huitema wrote:
> ...
> Bad, bad application developers. We should really punish them! :-)
Recognizing the smile, punishment was not my point. What many are
missing here is that the perspective of a single address scope does not,
and will not match the reality of the deployed network.
>
Måns Nilsson wrote:
> ...
> So, I'm glad that you call on the operator community, but I
> think you will be surprised at what they say.
I am not surprised because ISPs have a different perspective on this
issue (and many others) than enterprise network managers. The network
managers that will pr
Thomas Narten wrote:
> Dan Lanciani <[EMAIL PROTECTED]> writes:
>
> > I can't speak for others, but to me it is very interesting (and
> > important) to have internal connections that are not at the
> mercy of
> > my ISP's renumbering policy.
>
> I agree that this is a very desirable property to
Thomas Narten wrote:
> ...
> I've seen it now (somewhat independently) in the zeroconf WG
> too, where similar issues have been discussed with LL
> addressing for IPv4. There are plenty of people there that
> don't see what is hard about scoping and that it's not a big
> deal to make applicatio
Dan Lanciani wrote:
> ...
> Charging for addresses has nothing to do with an IPv4
> mentality. It has to do with a business model. There is
> absolutely nothing in IPv6 that would cause this business
> model to change.
Customers insisting that their privacy is important, so the ISP must
suppo
Margaret Wasserman wrote:
> Hi Tony,
>
> At 10:23 AM 4/3/2003 -0800, Tony Hain wrote:
> >Margaret Wasserman wrote:
> > > ...
> > > Access control is also useful, and a simple form of
> access control
> > > will be needed in IPv6. However, site-loc
Eliot Lear wrote:
> >>...
> >>Access control is also useful, and a simple form of access
> >>control will be needed in IPv6. However, site-local
> >>addresses are a poor form of access control for two reasons:
> >>
> >>- Site-local boundaries need to be at routing area
> >>or AS b
Margaret Wasserman wrote:
> ...
> Access control is also useful, and a simple form of access
> control will be needed in IPv6. However, site-local
> addresses are a poor form of access control for two reasons:
>
> - Site-local boundaries need to be at routing area
> or AS bo
Margaret Wasserman wrote:
> ...
> The work to keep, and finish, site-locals is much greater
> than the work to deprecate them.
Wishful thinking...
>
> To deprecate them, I think that the addressing architecture
> and the default address selection rules would be the only
> RFCs (both at PS) tha
Erik Nordmark wrote:
> ...
> I think #4 (which I didn't talk about at the mike) is a red
> herring. Perhaps the issue is a restatement of #1 (due to the
> ISP implicitly forcing a
> renumbering each time the site connects) in which case the
> points about #1 applies. And note that making site-l
1 - 100 of 361 matches
Mail list logo
