RE: Fourth alternative [was Re: Moving forward ....]
Eliot / Bob, >> Bob Hinden wrote: >> Is this sufficient? Would it better to also include an >> "operational considerations" or similar section? More text >> on why this is important? > Eliot Lear wrote: > Venders speak the language of money, So do operators and so do enterprises. Allow me to share the way it works for enterprises: - I am already paying $2.5k/yr to ARIN for portable IPv4 address space. - Although I could do without, I am ready to pay another $2.5k/yr for portable IPv6 address space (when IPv6 takes off, that is). - If globally unique IPv6 address space is free, I am willing to give these $2.5k/yr to my ISP to announce my /48. - On top of that, if doing so also solves the IPv6 multihoming issue, where do I sign? On the operator side, I do acknowledge that we have some of them around that do what they are supposed to and filter, thanks to people that promote routing table health such as Jeroen and Gert. That being said, the hard facts are that a) as of today 42% of my IPv6 BGP routing table is made of /48s, /64s and other crud and b) lots of ISP will think twice before refusing my $2.5k/yr to announce my prefix. > and that overrides whatever language is in the draft :-( Which is doubly lame, because 1) I should not offer the money and 2) they should not accept it; bottom line though is that both them and I run a business, not a charity. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
Eliot, That seems to me to be orthogonal. I agree that it would be good to see renumbering support (maybe it's a v6ops item??). But that doesn't destroy the value of Bob's proposal. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS <[EMAIL PROTECTED]> PLEASE UPDATE ADDRESS BOOK Eliot Lear wrote: > > Bob, > > I am sorry, but while it is a good attempt to come up with a happy > medium between SLs and global addresses, I disagree with the approach > that draft-hinden-ipv6-global-local-addr-02.txt takes. I would prefer > an approach that makes the stability of the IP address less important > rather than attempting to stablize it (a seemingly lost cause). > > What this means to me is that first we need to promulgate something > along the lines of draft-baker-ipv6-renumber-procedure-00.txt. It needs > some expanding to further automate the process. The more we automate > the less pain the network manager will feel during a renumbering event. > > This changes the problem from one of a scoped address to one of a > standard default and reduces any ambiguity that we might have. It > leaves open the question of how to find a name server, and how a name > server finds you, but the former can be found with SLP, and the latter > can then be handled with DDNS. > > I'd like to put Fred on the spot (not having asked him) and propose that > his draft be adopted as a WG doc. > > Eliot > > > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
What will happen to ::RFC1918?
As we are all looking at what to do with site locals, has anyone any text on what happens to the old RFC 1918 addresses? >From what I have seen the 0::10:x:x:x is still going to need to be treated as site local (private) as in a 6to4 enfironment we still need to maintain the old rules (at least until 4 is really dead, and that can be years away). Thus we can depreciate FEC:: /10 right now, and allow the old RFC 1918 addresses to continue to fill in the needs that people seem to want in a non-routable address. Otherwise we will not only need to depreciate FEC:: /10 but also all of the current installations of RFC 1918. This will also be where people try to sneak NATv6 into the network as these addresses (0::10:x:x:x) were hijacked years ago, and I don't see how we will get them back now. Eric IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
Bob Hinden wrote: Is this sufficient? Would it better to also include an "operational considerations" or similar section? More text on why this is important? Bob, Putting aside Michel's comments just for the moment, this would seemingly be necessary, but I don't know if there is anything you can write to make it sufficient. That will be a test of time. As I said earlier, I think the draft is a substantial advance over previous attempts. I do think Michel's comments need to be addressed. The issue is really an expectations game. Venders speak the language of money, and that overrides whatever language is in the draft :-( Eliot IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
Bob, Thanks for the clarification. I think I misunderstood "not replace site-local addresses in any form". If I have it right, the phrase implies "explicitly do not consider any alternatives", to which I agree that accepting indicates that the WG is interested in considering alternatives. - Ralph At 09:15 PM 8/4/2003 -0700, Bob Hinden wrote: Ralph, Furthermore, based on the record of the question from the minutes of the SF meeting and the question put to the ipng mailing list, how was this conclusion arrived at: A fourth alternative is to not replace site-local addresses in any form, but I think the working group has made it clear that this is not a reasonable alternative. It's from my reading of the discussion (on the mailing list and in the meetings) and the fact that the working group decided to accept as a working group document in Vienna. Bob IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Moving forward on Site-Local and Local Addressing
B A or C would be acceptable were they to happen but I think they will not in a reasonable timescale (and as an engineer, I want something that I can use:-) In passing, I am one of the third, not the two thirds, and do accept that we have rough consensus. Tom Petch -Original Message- From: Bob Hinden <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: 04 August 2003 19:14 Subject: Moving forward on Site-Local and Local Addressing >[IPv6 working group chair hat on] > >B) Deprecate Site-Local addresses at the same time as a alternative >solution is agreed to. This would mean advancing both documents at the >same time and making them include normative references to each other to >insure that they were published at the same time. This would result in the >deprecation only happening if a consensus was reached on an alternative. > >Thanks, >Bob > > >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to [EMAIL PROTECTED] > IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: What to do with FEC0? [was Re: Moving forward on Site-Local andLocal Addressing
On Tue, 5 Aug 2003, Eliot Lear wrote: > Brian E Carpenter wrote: > > That's an interesting expectation. As co-author of the planned > > deprecation draft, I'd been assuming a more classical deprecation > > action, in which we would simply state the previous semantics of > > FEC0::/10, state that the prefix SHOULD NOT be used, but leave it > > permanently assigned by IANA. > The term "permanent" is a bit long. It should not be used for some > period of time, and since there's a lot of address space out there, > perhaps that period of time should be considerable ;-) > Eliot Wouldn't it make practical sense if the local addressing primarily stuck with the suffix :1 ? -- Michael Mielke <[EMAIL PROTECTED]> http://www.mielke.cc/~michael/ IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Unicast scope field (was: Moving forward on Site-Local and Local Addressing)
Hi,
I was thinking to bring this suggestion myself, and I'm glad Yibo did.
Having a Scope field in unicast addresses seems (to me) to solve all-so-many problems.
I would go further to allow nodes to only send, receive and forward packets from- and
to- the same scope.
Being still on the IPv6 learning curve I might well be wrong, but it seems to me the
silver bullet for:
- Killing NAT ("site local" interfaces, whether globally unique or not, may never
communicate with global unicast
interfaces)
- Simplifying address selection
- Cleaning the routing tables
- Simplifying router design and setup
Coming from a router design point-of-view, the current address architecture, and more
important, the forseeable and
unforseeable changes within it, make it difficult to desgin a mechanism that
identifies the source/destination address
scopes.
OK - now I'm ready to take the flames...
Regards,
-- Nir Arad
- Original Message -
From: "Yibo Zhang" <[EMAIL PROTECTED]>
To: "Alain Durand" <[EMAIL PROTECTED]>
Cc: "Bob Hinden" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, August 06, 2003 12:38 PM
Subject: Re: Moving forward on Site-Local and Local Addressing
> 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.
>
> That's definitely a good idea because that way we might be able to
> replace all current local addresses with a single type of local addresses
> with a Range or Scope field like the multicast addresses.
> It would looks more consistent, more flexible, more scalable, and could
> even help the WG move the current situation forward more smoothly and
> smartly.
>
>
>
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
>
>
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
Re: Moving forward on Site-Local and Local Addressing
On Mon, 2003-08-04 at 20:06, Bob Hinden wrote: > I would like to hear from the working group on how we should proceed. I > think the choices are: I'd like to see A happen. Going for B, and even worse C, will just prolong the current state of uncertainty where a lot of people have heard that site-locals might be deprecated, but are uncertain as to whether they need to concern themselves with support for them or not in ongoing development etc. Let's just get rid of the darn things and move on - please. /leg IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: A suggestion around address selection behaviour
> What I am trying to get to is: > > - Application designers who want to work in the "end-to-end clean" > Internet and who do not care to support the corner cases should be > able to do so. > > - The default address selection rules should favor solutions based on > global addressing, I think we all agree that if such a solution is > reasonably possible, it should be used. With the defaults above, the > > "path of least resistance" is not to use limited range, which is > good. > > - Finally, if a solution requires local addressing, and application > writers want to support it, there needs to be a standardized way to > do this (which is why local addresses must be defined and > recognizable). IMHO, the need for local addressing has not been established, and we should not burden either hosts, apps, or networks with it in the absence of strong justification. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: FW: AD response to Site-Local Appeal
Tony Hain wrote: 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 decided. On the contrary, I believe that there was strong consensus about the nature of the question. In fact (as I recall) at the meeting in SF there was signifficant discussion about the question posed - there was ample opportunity to clear up any remaining confusion about the question posed. MVH leifj IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Appel due to management of the "site-local issue"
Leif, You didn't address this to me, but I feel obligated to answer. The questions I have asked the working group in the email "Moving forward on Site-Local and Local Addressing" was to ascertain the manner in which the working group wanted the deprecation of site-local was to happen. The steps the working group should take. This has been a topic of debate it and I thought it best to get feedback from the working group. It was not in any way an attempt to revisit or un-deprecate site-locals. Each choices I asked people to indicate their preference for in that email included deprecating site-local addresses. I support that the working group did decide to deprecate site-local addresses, helped to declare that consensus, and I am one of the w.g. chairs who rejected the appeal on that topic to overturn the decision. The chairs are not trying to change the decision of the working group. I think you may be misinterpreting the intent of this email. Site-Local is, as everyone can see, a contentious issue and it is my desire get clarity on the way the WG wants to move forward. Getting feed back from the working group on how it wants to do this is something I feel is essential. Regards, Bob At 02:41 AM 8/5/2003, Leif Johansson wrote: During the IETF meeting in San Francisco, rough consensus found that site-local was to be deprecated. The wg was to investigate other approaches to the problems site-local claims to solve. It should be noted that the wg chairs explicitly before the meeting in San Francisco asked people not directly involved in ipv6 design (security, routing and applications people) to get involved with this issue. In my opinion from talking to a number of collegues and from the traffic on the mailing list those involved from other areas are no longer actively participating in the debate since they believe that site-locals has indeed been deprecated and that the ipv6 wg is continuing the important work on ipv6 in the IETF. Currently the question about the future and status of site-locals is again beeing discussed in the wg despite the fact that consensus was achieved in SF and confirmed on the mailing-list. This is a sign that the wg chairs have not been able to follow the plan laid out at the SF meeting. I respectfully ask that the ADs to confirm the decision made in San Francisco, later confirmed on the mailing list, and ask the wg chairs to please move on, working on real issues regarding ipv6 than beating this dead horse once again. Best Regards Leif Johansson Stockholm university IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Appel due to management of the "site-local issue"
Thomas Narten wrote: To be clear, are you filing a formal appeal? If so, you need to be very clear about which action you are appealing, on what grounds, what the remedy should be, and so forth. Also, per 2026, the first place to start with an appeal is the chairs. Only if you are not satisfied with their response would you go to the next level. I am filing a formal appeal and I hope that both the grounds for the appeal, the actions appealed and the remedy were clear from my email. If not I appologize. I gather then that you believe that there is already consensus for Bob's "choice A", and that even offering choice B (and C) is inappropriate. Correct. The choices B and C actually imply that site-locals will be used which in no way can be construed as "deprecating" site-locals. Given the complexity of the issues and the time ipv6-wg has spent to date it is not entierly clear that B and C imply anything other than full deployment of site-locals on the Internet for the forseeable future. In anycase, clarification would be helpful. I am new to the appeals process. Could you please tell me what in my original message needed clarification. Thanks! Thomas Cheers Leif IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Independence of Deprecation (Was: Re: Moving forward on Site-Local and Local Addressing)
Hi Ralph, At 11:01 PM 8/4/2003 -0400, Ralph Droms wrote: Bob's e-mail to the ipng mailing list used to judge WG consensus on deprecating site-local addresses asked: The question is: Should we deprecate IPv6 site-local unicast addressing? Valid responses are: "YES -- Deprecate site-local unicast addressing". "NO -- Do not deprecate site-local unicast addressing". which I read to be pretty clearly independent of consideration of any replacement mechanism. In response to Bob's question on the WG mailing list, the YESes followed the format from Bob's e-mail - that is, those YESes were unconditional "YES -- deprecate SL", not any form of "YES -- deprecate SL after a suitable replacement has been defined". If you look at the results of this poll, though, you will see that there was some significant resistance to deprecating site-local addressing, without regard to a replacement (about 1/4 of the people who responded to the poll indicated "NO"). Fortunately (if you favor finding consensus), many of the people who expressed an opinion against the idea of deprecating site-local addresses with no replacement did indicate (in their poll response, or in other e-mail to the list) that they thought that site-local addressing had serious problems, but that we should only deprecate unicast site-local if we could provide an alternative for local addressing. In reading through the e-mail to the list (in response to the poll, and other discussion), Bob and I determined that there was a consensus to deprecate site-local addressing AND provide a replacement. And, that is what our consensus call said. Our consensus call indicated that work to deprecate site-locals and replace them would be undertaken "in parallel". Some people have since asked, quite reasonably I think, whether "in parallel" implies that these things would happen at the same time, or if one could/should complete before the other (i.e. do we deprecate then replace, replace and then deprecate, or do both at once). It hasn't been clear (to me and Bob, anyway) from the discussion what the consensus of the WG is regarding this question, which is why Bob has posed a question to the list to try to clarify things. If we don't reach any consensus on the order/dependency, then I guess we will continue with all of the work items "in parallel" and determine when/if we get WG consensus to advance each document to the IESG. It would be easier to plan WG milestones and focus our work, however, if we understand what order/dependencies the WG would like to place on these work items. Furthermore, based on the record of the question from the minutes of the SF meeting and the question put to the ipng mailing list, how was this conclusion arrived at: A fourth alternative is to not replace site-local addresses in any form, but I think the working group has made it clear that this is not a reasonable alternative. I don't think that you could draw this conclusion from the discussion at the SF meeting, but it has been pretty clear on the mailing list that we do not have consensus to deprecate site-local addressing unless we also develop a replacement. In Vienna, the working group did accepted a replacement proposal as a WG work item, which also seems to indicate that the WG has consensus to replace site-locals with an alternative local addressing mechanism. Margaret IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: apps people?
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 I > don't see > the need for site-locals. So is all of your space is globally routed without any filtering or exclusion from routing protocols? Not everyone is in such a lucky position to have all of their network globally exposed. > I think it is time to drop the "silent > majority" argument. > > What edge-network do you run? Currently an insignificant one, but in past lives I have been involved in both large scale edge and core network management. The point is not what you or I think about the need for local addressing, it is about what the manager who can't get PI space is going to do. Insufficient resources to justify PI space does not invalidate their need for internal network stability. In the absence of NAT, allowing the ISPs to renumber customer networks at a whim will ensure 'address-portability' becomes a hot button. We can help mitigate what would become random PI by providing local stability. We can go further by providing a 'less-than-perfect' PI. PI will solve most of the requirements for local space, but by definition can't deal with the requirement to avoid accidentally becoming part of a routed aggregate. Tony IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Moving forward on Site-Local and Local Addressing
I think we should do alternative B, i.e. deprecate and at the same time propose a replacement. Barring that, C is also acceptable. Alternative A is likely to generate fisrt uncertainty, and then a free-for-all, and the risk of some "grass root RFC 1918". -- Christian Huitema IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
Brian E Carpenter writes: > Michael Thomas wrote: > > > > Brian E Carpenter writes: > > > Eliot, > > > > > > That seems to me to be orthogonal. I agree that it would be good to see > > > renumbering support (maybe it's a v6ops item??). But that doesn't destroy > > > the value of Bob's proposal. > > > > I disagree. What we seem to be dancing around with > > here is an aversion to dealing with the actual > > requirements of people who deploy networks. Even > > though Bob's proposal polishes the site local > > t***, it's still a dangerous stopgap and doesn't > > address _why_ this requirement for stability in > > the here and now is so strong, and the fact that > > we don't have a credible answer. > > "Why" is addressed in draft-hain-templin-ipv6-limitedrange-00.txt > That document may need more work, but it certainly attempts to > answer the question, convincingly to my mind. The problem is that this draft proceedes from the premise that the answer is consing up limited range addresses. That's incorrect and not helpful. We need to start by determining what the *requirements* are, and only then outline what the range of solutions are, and what their problems and possible consequences are. Until we can get an consensus on what we need to do, and what the engineering tradeoffs are, we will never come to closure. That in a nutshell is why I have a problem with the religiosity on both sides of this argument. Mike IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: draft-hain-templin-ipv6-limitedrange-00.txt
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 > > not initially exist in IPv4, and history shows that people took > > whatever bit > > patterns looked interesting. > > You must talk with different operators than the ones I talk with. > > I have heard operators wanting address space for the following: > > - Private networks which are never routed to the Internet > (management and various things like GPRS things), but > possibly routed to peers, i.e. there might be the need > for local routing > > This can be done by using real addresses which are never > routed to the > Internet. This is something which is possible to do in IPv6 but not > IPv4 due to RIR policies. Not unless the site is willing to pay an ISP for address space, then probably pay extra to make sure it does not get routed as part of the ISP aggregate. > So, today, the ISP's use RFC 1918 > addresses, > but of course peering then end up being a problem. Because of > this, we > see telcos using 11/8 and such IPv4 space for gprs. Local address space MAY be used by ISPs, but the primary target for local use space is the edge network. I agree that when ISPs use unrouted space, results may not be deterministic. > > In IPv6 world, real addresses can and should be used. Real or imaginary are perspectives of the onlooker. I suspect you intended 'globally routed'. > > - Private networks which they nat customers behind so the > customers can not so easy set up their own servers > > This is a packet filter/security issue and not a NAT issue. The > selection of NAT is a bad thing, and this is exactly what we should > prohibit in IPv6 world. Yes, the ISP can still sell filtered > access of > various kinds and possibly a large portion of the users out > there want > it. But, it should not be part of the architecture. I absolutely agree, and have been working on documenting similar requirements for address space that is known to not be globally routed. > > - Private networks for certain services which is located > close to the customers so the same IP address is reused > at every pop > > The ISP can in IPv6 world take a portion of their (real) > address space > and do the same thing. That ISP's today use RFC 1918 addresses means > the RFC 1918 addresses are (for the customer) not used as > intended, but > as real addresses. In IPv6 world this is not needed. Duplication of addresses is not 'needed', but may be perceived as an operational simplifier (ie: the dhcp servers in every pop are 192.168.255.1, ACL configs at every pop are the same ...). This is not arguing that we need to keep that, just pointing out that there are operational costs to changing the model. One thing that is required is that an ISP have a means to provide private networks to their customers. The address space for these can't be taken out of the same aggregate that is being announced to peers, else the network is not really private. > > - Tons of addresses so they can redesign their internal > network a lot without risking renumbering > > With IPv6 they get many many more addresses than before, so > they don't > have to allocate /29 here and there in IPv4 for small networks which > should only have a few hosts. They can have the same netmask all over > the place. And still limit the size of their broadcast domains. Nice in theory, but when route filtering practice hits the fan, there will be allocations within networks that don't seem to make any sense from the outside. There are many more bits for aggregation, so having different lengths and exposing the topology details should not be as frequent as in IPv4, but there are times that the aggregate policy does not match the longer prefix, so those will still show up. The real problem with restricting access happens when the aggregate policy is more open than the longer prefix wants to be. Tony IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Moving forward on Site-Local and Local Addressing
A) for me, even though B) would be fine too. thanks. - Naiming IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Moving forward on Site-Local and Local Addressing
Brian Carptener writes: > http://www.apnic.net/meetings/16/programme/sigs/docs/policy/addpol-doc-huston-local-use-addrs.doc > attempts to to refine this draft into some considerations from a registry > perspective. (If there's interest > I'll put this out as an Internet Draft) Geoff, Three comments on your draft: Thank you for reviewing the document 1. I don't think the RIRs as institutions have any special standing to comment on the locally-assigned variant in draft-hinden. It's a technical choice for the WG and the IETF. If you're arguing personally that you don't like the birthday paradox risk, let's discuss it. It is an individual document, as stated by listing only myself as the author. It is not an RIR document, and it does not represent any RIR position. As an individual IETF participant I have as much standing to comment on the locally assigned random choice proposal as any other individual, obviously. The probability of a collision using random choice is not a paradox. Its a simple calculation, using the formula as given in the document. The observation is that even though the /8 space contains 1.1 trillion entries, there is a greater than 0.5 probability that there will be a clash after some 1.2 million draws. Normally this would not matter in the slightest, BUT the proposal also notes a potential to use these addresses in the context of end point identifiers, and in such a case there is a strict requirement for uniqueness, and my observation is that self-driven random choice is inadequate. Its not a paradox risk. Its just the underlying mathematics of random draw probabilities. 2. Most of your arguments appear to be hinting at a re-run of the ICANN wars for the centrally assigned variant. Well, that's why there is an analogy with .org in the draft. You may be right that the pricing level should be set competitively, but I really don't see this being a gold rush. There's not much marketing value in a random number. In any case, you're correct that the IETF can't decide this, but we need to give IANA the clearest instructions possible. I honestly can't make any sense of these sentences. Could you please rephrase it? Incidentally, since these are not routeable addresses, and have no geography, it doesn't follow that the RIRs have a role in this part of the address space. In fact, the RIRs might be quite uncomfortable with the idea of competing in the sale of random numbers. It may be. It may not. But attempting to second guess anyone, as you appear to be doing in your comment, without at least allowing them the courtesy of consideration of the issues is not normally considered a very wise course of action. So this document is considering the issues and looking at the pros and cons of various forms of distribution, and looking at an RIR perspective in considering the implications of a central registry function of such local use allocations. You'd prefer that this analysis was done behind closed doors? I'd be tempted to guess that your answer would be a 'no', but I'll avoid the temptation to second guess you and leave it for you to answer. 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. And the document considers this approach as well as others. Interestingly enough there are other perspectives here to the one you've stated, and there are pros and cons to each of them, and the document explores some aspects of these considerations. You appear to offer the hint here that its in some manner heretical behaviour to explore alternatives. Again I'm tempted to guess that you do not mean it to sound that way, but once more I'll refrain :-) Regards, Geoff IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
Umm, the draft has *two* authors - not one. The requirements and scenarios in the document are showing a *real need* independent of whether link-local, site-local, limited-range, global, provider-independent, etc etc. provide the best solution. If you think the document has a scoping issue (no pun intended), then let's discuss that with a measured tone. Thanks, Fred Templin [EMAIL PROTECTED] > -Original Message- > From: ext Michael Thomas [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 06, 2003 12:47 PM > To: Tony Hain > Cc: 'Michael Thomas'; 'Brian E Carpenter'; [EMAIL PROTECTED] > Subject: RE: Fourth alternative [was Re: Moving forward ] > > > Tony Hain writes: > > 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 meet the need to explain it for those who don't > believe their > > requirements are real. > > Tony, quit patronizing me and everybody else. I've > not seen one person here who is insensitive to the > actual needs of network managers. What I've seen > is differing opinions of how to weigh the > conflicts and most especially what the long term > implications are of any particular approach. Your > trying to frame these conversations as a one-man > crusade against the IETF ivory-tower is lame and > insulting. > > Your draft is not helpful because it starts out > with a conclusion and works back from there, much > like yellowcake and WMD. The bias is in the title > of the draft, for gawd sake. What we really need > is something that lays out all of the requirements > -- and local scope is not a requirement, it's a > solution -- and tries to analyze the problem space > without bias to a particular solution; laying out > the good, bad and the ugly for each possible > approach. > > > > > > That's incorrect and not > > > helpful. We need to start by determining what the > > > *requirements* are, > > > > That is the point of the draft. > > It fails. See above. > > > Unfortunately some on this list want to > > argue that some requirements are not real, rather than > accept that different > > situations create different requirements. Given that not > everyone has > > expierenced every situation, the draft needs to provide > enough context > > around a requirement so that others can see the issue. > > And now your patronizing the group again. Stop it. > > > > and only then outline what the > > > range of solutions are, and what their problems > > > and possible consequences are. Until we can get an > > > consensus on what we need to do, and what the > > > engineering tradeoffs are, we will never come to > > > closure. > > > > Yes and no. There is no way to achieve a single optimal > solution for the > > diverse set of requirements, so we know the outcome will > be a compromise. > > Bob's draft (as did the others to randomize SL) meets the > requirements in > > the current draft. > > You mean the requirements of "do no harm wrt NAT > and DFZ route pollution?" Oh, golly, I guess I > didn't find those in the draft. Both of these > requirement are downsides of limited scope > addresses approach, btw. > > > > That in a nutshell is why I have a problem with > > > the religiosity on both sides of this argument. > > > > My religion is that the deploying network manger is right, > no matter what > > the IETF decides. If the IETF decides to provide tools to > make deployment > > easy, that will be the path of least resistance. If not, > the network manager > > will demand ad-hoc tools to get the job done. > > Aside from the preposterous notion that you're the > torch bearer of the poor under represented network > manager (::snort::), this isn't helpful because > what we need here is to balance out the > conflicting requirements both in whose work load > is affected, as well as the general architecture > of the net. The network manager is *one* voice > that needs to be considered, not the *only* voice. > > Mike > > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > > IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Moving forward on Site-Local and Local Addressing
I'm in favour of B. I use SL addressing today to achieve address stability in a 6to4 environment. The current drafts look like progress to me and remove the biggest wart of SL: ambiguity. - aidan Bob Hinden wrote: B) Deprecate Site-Local addresses at the same time as a alternative solution is agreed to. This would mean advancing both documents at the same time and making them include normative references to each other to insure that they were published at the same time. This would result in the deprecation only happening if a consensus was reached on an alternative. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Real life scenario - requirements (local addressing)
Keith Moore wrote: > > > - I need some form of local addressing that is not dependent on anyone > > or anything connected to the global internet. > > no, you need some form of globally unique address that isn't dependent > on having an external internet connection. Nor on needing an external registration procedure. I'd like to be able to turn my router on and have it all just work. (Side point: hence why I favour using the router's MAC rather than my birthday and current system time to generate the network prefix. The former is hard-coded into the router and unique - the latter requires user intervention). > > - I need this local addressing unique enough that I can safely join my > > network and my friend's network together and allow them to swap > > prefixes. > > agreed. > > > - I want hosts in my network to prefer my local address scheme when > > talking to other hosts in my network. > > you've not shown any justification for that. what do you care what > addresses are used as long as the traffic doesn't escape and/or the > hosts that you don't want to be accessible from outside your > network, aren't accessible from outside your network? When that 6to4 address goes away, I don't want my persistent sessions to be forced to maintain a stale address. > > I want hosts in my network to > > prefer one of the local schemes when talking to hosts in my friend's > > network (since I don't want the packets to leave 'our' network). > > again, you haven't show any justification for that. it's far easier to > filter global addresses than to filter local ones. *boggle* Am I the only one that finds this claim nonsensical? > > I want hosts in my network to prefer global addresses when talking > > externally. > > why not have them use global addresses whenever possible? it makes the > applications MUCH simpler... Because (in the current context) there's no such thing? A local address is an address that promises to be filtered. A global address is an address that makes no promises. > > - I want my local addresses filtered at appropriate borders, > > preferably without having to set it up myself. > > sorry, that's not going to happen. how are the routers supposed to know > which borders are appropriate without being configured to know? you've > already suggested you'd like the same set of "local" addresses to > be routed between your network and your friend's network. On my 'home router / gateway' I have one port coloured red and placed on one side of the box. This says 'uplink'. The other ports are on the other side of the box and are labelled 'internal'. The rest follows from there. Especially since all my 'home router / gateway' boxes are using a common prefix for generating their internal addresses (say FD00::/8). Note that I either don't have or don't use the 'uplink' port on internal routers. It's not REALLY that difficult. -- Andrew White IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: A suggestion around address selection behaviour
Citerat från Tony Hain <[EMAIL PROTECTED]>: > > You're asking the DNS views to be in sync with the routing > > views. > Yes, a layer violation which is in wide deployment and use today. Yes > there > are technical issues which could be dealt with to make it work better, > but > those won't happen as long as the IETF DNS community refuses to step up > to > them. Good solution. Lets move the problem somewhere else... I think you are fighting a loosing battle. Even if there was something wrong with the way site locals were deprecated from IPv6 in terms of itty bitty details of procedure, do you honestly believe that bringing them "back" would prevent us (the site locals depreceators) from getting rid of them once again, by the book? I think all that will be lost is precious time to work on a better solution because there is enough strong voices against site locals. Certainly enough for my interpretation of "rough consensus". Arguments for and against is repeating itself and that makes the likelihood of someone changing opinion smaller by the day. People are locked into their positions and in essence the consensus will remain IMHO. The only thing to change that is new evidence. None is appearing. We can always bring site locals BACK into the standard at some later point if we realize that it actually was a good thing. But the apps people, the routing people, the ISP people, the edge people and a bunch of other people seems to think it is a very bad thing compared to living without it. It is much more difficult to change things once 100,000 people or a million people are using it compared to when 1000 people are using it. Are there 1000 site local uses of IPv6 in the world today? I say, lets see if it really is a bad thing by trying to find a better solution and work with that for a while. If it turns out there are better solutions, everybody wins. If there aren't any, you were right and we bring site locals back into the picture and everybody wins. IANA can sit on the necessary ranges until the end of time if required. It is always easier to ADD features in the future than to remove them. So lets get on with it. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Independence of Deprecation (Was: Re: Moving forward onSite-Local and Local Addressing)
> I look forward to reading an ID describing a set of necessary (not > sufficient!) requirements fulfilled by scoped unicast addressing - > i.e. the problems which cannot be solved by *any other* mechanism. personally I'm not interested in having this group spend any time trying to justify a "feature" which we already know is unworkable. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
