Re: RFC Editor and 2006 timeline
Brian E Carpenter wrote: Initial contract with who? The only fair bidding process I know is one in which potential bidders are sought via a very widespread and relatively low cost RFI, followed by a targetted and relatively high cost RFP. IMHO the risk of not having an RFI is that the bids will be out of whack. If informal conversations or experience have led to a conclusion as to what range of bids would be expected then an RFI seems unnecessary. We know the current cost structure, because we're footing the bill. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On Apr 16, 2006, at 3:17 AM, Iljitsch van Beijnum wrote: On 16-apr-2006, at 6:09, Patrick W. Gilmore wrote: Wow, Iljitsch, I have never lost so much respect so quickly for someone who was not flaming a specific person or using profanity. Congratulations. Well, that's too bad. But several years of trying to get a scalable multihoming off the ground (flying to different meetings on my own dime) where first my ideas about PI aggregation are rejected within the IETF mostly without due consideration because it involves the taboo word geography only to see the next best thing being rejected by people who, as far as I can tell, lack a view of the big picture, is enough to make me lose my cool. Just a little. Thank you for believing my opposition of your ideas is simply because I lack a view of the big picture. Note that it is entirely possible I believe the reverse to be true. Or perhaps you see a big picture, and I just see a bigger one. However, I probably won't lose my cool since, as I stated before, the overwhelming majority of people who run the Internet seem to see my bigger picture. Back on topic, it is not just those 60 people - the playground appears to overwhelmingly agree with their position. I know I do. Don't you think it's strange that the views within ARIN are so radically different than those within the IETF? Sure, inside the IETF there are also people who think PI in IPv6 won't be a problem, but it's not the majority (as far as I can tell) and certainly not anything close to 90%. Now the IETF process isn't perfect, as many things depend on whether people feel like actually doing something. But many of the best and the brightest in the IETF have been around for some time in multi6 and really looked at the problem. Many, if not most, of them concluded that we need something better than IPv4 practices to make IPv6 last as long as we need it to last. Do you think all of them were wrong? Yes. And so does essentially everyone else who runs an Internet backbone. These are some of the best and brightest in the world, and most of them have been around for .. well, 'forever' in Internet terms. But decision such as these really shouldn't be decided simply because someone has been doing this longer. I am sorry your technical arguments have not persuaded us in the past. But I would urge you to stick to those, Stay tuned. I'll try. But honestly, reading the same arguments over and over gets tiresome, especially when so many well-qualified people have explained the opposing PoV so well. Oh, and one thing I should have said last time: Technical arguments are important, but they are only part of the decision process. People (like me) have explained that the Internet is a business, and in addition to being .. technically unsavory to many people, shim6 is simply not viable in a business setting. Neither backbone operators (vendors) nor end users (customers) are warming to the idea. Just the opposite. (At least in general, the one-in-a-million end user with DSL and cable who likes the idea 'cause he can't figure out how to spell B-G-P or doesn't want to pay for it is irrelevant.) So how do you get a technology widely accepted when the majority of people involved do not think it is the best technical solution? When the majority of vendors supposed to implement it will not do so for technical -and- business reasons. When the majority of end users who are supposed to buy the service will not? Okie, trick question. :) You don't. -- TTFN, patrick ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On 4/14/06, Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 14-apr-2006, at 16:57, Scott Leibrand wrote: 60 voted in favor of moving forward with PI.6 voted against.Wow, 10 to 1. Amazing.Even more amazing: 60 people who represent nobody but their own paycheck get to blow up the internet.Where is ICANN when you need it? This little experiment in playgrounddemocracy has to end before people get hurt.I am a member of the ICANN ASO AC and I was there, but I'm not sure you meant that, and, the ARIN forums are open to all.The vote was a display to our advisory council to what the constituents want.The ARIN mailing lists get just as much consideration.Where are you? -M___ Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On Apr 14, 2006, at 11:07 AM, Iljitsch van Beijnum wrote: On 14-apr-2006, at 16:57, Scott Leibrand wrote: 60 voted in favor of moving forward with PI. 6 voted against. Wow, 10 to 1. Amazing. Even more amazing: 60 people who represent nobody but their own paycheck get to blow up the internet. Where is ICANN when you need it? This little experiment in playground democracy has to end before people get hurt. Wow, Iljitsch, I have never lost so much respect so quickly for someone who was not flaming a specific person or using profanity. Congratulations. Back on topic, it is not just those 60 people - the playground appears to overwhelmingly agree with their position. I know I do. I am sorry your technical arguments have not persuaded us in the past. But I would urge you to stick to those, or at least consider why we remain unconvinced, rather than devolve into .. whatever that post was supposed to be. -- TTFN, patrick ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
I agree. /jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick W. Gilmore Sent: Sunday, April 16, 2006 12:10 AM To: Iljitsch van Beijnum Cc: Patrick W. Gilmore; shim6-wg; [EMAIL PROTECTED]; [EMAIL PROTECTED]; IETF Discussion; [EMAIL PROTECTED]; v6ops@ops.ietf.org Subject: Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN] On Apr 14, 2006, at 11:07 AM, Iljitsch van Beijnum wrote: On 14-apr-2006, at 16:57, Scott Leibrand wrote: 60 voted in favor of moving forward with PI. 6 voted against. Wow, 10 to 1. Amazing. Even more amazing: 60 people who represent nobody but their own paycheck get to blow up the internet. Where is ICANN when you need it? This little experiment in playground democracy has to end before people get hurt. Wow, Iljitsch, I have never lost so much respect so quickly for someone who was not flaming a specific person or using profanity. Congratulations. Back on topic, it is not just those 60 people - the playground appears to overwhelmingly agree with their position. I know I do. I am sorry your technical arguments have not persuaded us in the past. But I would urge you to stick to those, or at least consider why we remain unconvinced, rather than devolve into .. whatever that post was supposed to be. -- TTFN, patrick ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ppml] [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
This message was cross posted to a large number of lists. I would like to make the root of the discussion clear, without taking an opinion. This link is the original message, best I can tell. Hopefully from there each individual on this message can tell how they came to receive it. http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00162.html Please go back to the header as well. Lists from several different organizations have been CC'ed, and each will have their own opinion. All are available on the web. A well informed reply is the best reply. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpOrmumakdQN.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard
Cullen Jennings [EMAIL PROTECTED] writes: On 4/10/06 6:34 PM, John C Klensin [EMAIL PROTECTED] wrote: --On Tuesday, 11 April, 2006 11:26 +1000 Mark Andrews [EMAIL PROTECTED] wrote: On 4/10/06 4:31 PM, Mark Andrews [EMAIL PROTECTED] wrote: Did the base32 extended hex version get used in the SASL work? Can we upda te the reference or if it is not needed not just remove it. base32 extended hex is being / will be used for NSEC3 as it preserves the sort order. Great - perhaps we could add a reference to that. Work in progress. draft-ietf-dnsext-nsec3-04.txt needs to be update to say base32 extended hex and reference this draft. But such a reference from the Base16, Base32,... draft is not normative. To simply give (clearly non-normative) examples, with each encoding, of where it is used or expected to be used seems to me to helpful to the reader and to cost almost nothing. john I was concerned that we might be defining an option that no one needed and that would just encourage more variations where they were not needed. The fact that nsec3 has chosen to use this particular form is good enough proof for me that there is a need for the base32 extended hex form. I agree a informative ref to the work in progress will help people fine examples of where it was used and perhaps have a better understanding of where and why they might pick a particular form. All sounds good. I agree with this discussion, and have added an informational reference to the NSEC3 document in the base32hex section. The updated version can be found at: http://josefsson.org/base-encoding/draft-josefsson-rfc3548bis.txt with rfcdiff's to the -02 version in last call at: http://josefsson.org/base-encoding/draft-josefsson-rfc3548bis-from--02.diff.html Thanks. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Hi, On Sun, Apr 16, 2006 at 06:03:22PM -0400, Bound, Jim wrote: The IETF has NOTHING to say anymore than any other body about any RIR policy. I want it to remain that way. IETF job is a standards body not a deployment body. Things work a lot better if IETF and RIRs work hand-in-hand - that is, IETF makes standards that people can work with, and RIRs use allocation policies that somewhat reflect what the protocol designers had in mind. For IPv6, this isn't a huge success story yet... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 88685 SpaceNet AGMail: [EMAIL PROTECTED] Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Number portability, after all, only requires a layer of indirection. We can certainly engineer that! And we have. It's called the DNS. no it's not. DNS sucks for that. it's too slow, too likely to be out of sync. DNS names are the wrong kinds of names for this. the protocol is poorly adapted for this purpose, the infrastructure is worse. I agree with Christian. we can build indirection into the routing infrastructure. it's probably the right way to go. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Keith Moore wrote: ... I agree with Christian. we can build indirection into the routing infrastructure. it's probably the right way to go. One could argue that we already have. It's called MPLS... Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard
Hi Cullen, thanks for your review! Sorry for the delay in answering this, I was on vacation. Cullen Jennings [EMAIL PROTECTED] writes: There seems to be two (or more) common base 64 encoding alphabets. Could we enumerate the alphabets used in at least standards track RFCs and give each one a more specific name so that specification could specify which one the forms was used. This might help implementers understand there were multiple forms and libraries might provide a flag to choose the correct one. That seems like a good idea. I'm not sure this document is the best place for it, but it may be. If you want to see this added, please suggest text for a new section with this information. Has the filename safe version of base64 been used anywhere - if so can we provide a better reference and a post to a mailing list? If not can we remove it? I don't know. I recall a request to add a filename safe alphabet to RFC 3548, probably in a last call comment, and while digging up the background on that, the only reference I could find was that mailing list post. I was wondering if this form of Base32 was actually used anywhere. If not, could we just remove it. I don't know. A survey of standards referencing this document may answer that. Did the base32 extended hex version get used in the SASL work? Can we update the reference or if it is not needed not just remove it. The SASL GS2 work is using base32, but which alphabet is not crucial. We could request to have the alphabet in GS2 changed. The reference is there to document from where the alphabet came, if I update it to point at the current document (which point at rfc3548bis), some information is lost. I could add an extra reference to the current version of that document though. Having LGPL code in the draft will no doubt cause concerns for some people - given the simplicity in understanding this algorithm and wide availability of working code, does having this code here really improve the specification? Several people has requested code. Note that several existing implementations are broken, in particular in the handling of non-alphabet characters, excessive padding, and handling prematurely terminated inputs. Eventually I wrote my own, partially based on one with clean design. Thanks, Simon Cullen On 4/3/06 6:29 AM, The IESG [EMAIL PROTECTED] wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Base16, Base32, and Base64 Data Encodings ' draft-josefsson-rfc3548bis-02.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-05-01. The file can be obtained via http://www.ietf.org/internet-drafts/draft-josefsson-rfc3548bis-02.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Keith Moore wrote: ... I agree with Christian. we can build indirection into the routing infrastructure. it's probably the right way to go. One could argue that we already have. It's called MPLS... sort of. MPLS with globally-scoped tags, and a database of coarse (think subnet sized) identifer to locator mappings that is distributed via BGP. border routers look at the destination host identifier, find the set of locators that correspond to it, and pick the best locator given current routing conditions. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Noel Chiappa wrote: ... it is manageable to deal with porting between providers within a city, but not between cities Metro addressing! All those old classics are making a comeback... Ideas never die; some are just ahead of their time. ;) those groups couldn't see the forest for the trees. They were absolutely technically informed, but completely unwilling to listen to the big picture political reality. And the current group has a superior grasp of the all-around picture? Ah, got it. I didn't say that. Note they did not specify exactly how they were going to do it, just that it would be done. If the technical group has approaches that are better than first-come from a swamp-block, now is the time to get them on the table. They have called the bluff of the PA-only tantrum and will do random assignments if nothing better emerges. an attempt to get in front of what is a growing wave of demand to head off an outright pronouncement from outside the community which will result in number portability. Since there's no technical difference between PI and number portability, I expect approval of PI-space will lead to portability anyway. Yes, the current criteria for PI-space are rather limited, but since there's no particular technical rationale for picking /N versus /M, I expect to see a salami-slicing political debate in which people will demand smaller and smaller blocks be supported, because to do anything else is dumping on the little guy, while letting the big players have acess to something the small players don't. I happen to agree with you here, which is why I have been advocating a particular geo approach that can work with existing BGP and be scaled up and down as far as necessary to contain the routes. Unfortunately to date, the IESG has not understood the necessity to have a working group to refine a globally acceptable approach. Sigh, we're going to be paying the price for not (long ago) setting up a charging system for having a route be visible in the default-free zone. The existence of a default-free-zone was long ago relegated to myth status. There are different views of what this mythical entity contains, so by definition there is no single zone. Rather than fight to maintain an ego driven myth, we should be accepting reality and organizing structure in what appears where. there is a middle ground that gets messy because it does not have simple solutions without constraining topology. ... That set of requirements leads to structured allocations and topology constraints. Both sides will have to give I'm curious to hear what the ISP's will have to say about this topology constraints stuff... They never like it because it restrains their freedom. At the same time the carrier side of the house has learned to deal with it in the PSTN context, so the ISP side will be getting an education in dealing with customer/governmental requirements. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On 17-apr-2006, at 21:20, Tony Hain wrote: I have been advocating a particular geo approach that can work with existing BGP and be scaled up and down as far as necessary to contain the routes. Unfortunately to date, the IESG has not understood the necessity to have a working group to refine a globally acceptable approach. Since this has been coming up from time to time for over a decade, why not look at it, document the results and be done much faster when it comes up again and again the following decade, I would think. But I also happen to think that aggregation inside ISP networks based on geography (which has little to do with metro addressing as proposed but never worked out in detail 10 years ago) can actually work. Unfotunately when it was time to decide on an approach to further develop in multi6 there was no support for this so shim6 happened (which is also a good approach in its own right) but now the operator / policy making community balks at shim6... Anyway, here's the draft once again for those looking for some reading material: http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt But it's really a no-brainer: with straight PI we know that smarter routing is never going to help us for those prefixes. But if PI addresses are given out in _some_ aggregatable we at least have a chance that we can clean up the routing tables later. Geography makes sense to aggregate on as a next best thing when provider aggregation can't be used because it optimizes for one of the few network properties that are more or less constant: the speed of light. (With apologies to Brian for not having run my 100M BGP table simulations.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
From: Christian Huitema [EMAIL PROTECTED] only requires a layer of indirection. We can certainly engineer that! Yes, but we aren't. E.g. it would be really wonderful if we had some way of finding out what range(s) of addresses belonged to XYZ Corporation, so that the configuration of the firewall of their commercial partner, ABC Corporation, could contain a single entry for XYZ Corp's addresses, rather than list the actual addresses. As long as we are configuring things with actual addresses, it will remain incredibly painful to change them. Even worse, we're going in the *other* direction, and instead of adding another level of indirection, to provide new functionality, we're loading additional functionality (PI) onto the same old level of naming we already have. Architecturally-speaking, this design gets an 'F'. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
From: Tony Hain [EMAIL PROTECTED] Since there's no technical difference between PI and number portability, I expect approval of PI-space will lead to portability anyway. Yes, the current criteria for PI-space are rather limited, but since there's no particular technical rationale for picking /N versus /M, I expect to see a salami-slicing political debate in which people will demand smaller and smaller blocks be supported, because to do anything else is dumping on the little guy, while letting the big players have acess to something the small players don't. I happen to agree with you here, which is why I have been advocating a particular geo approach ... be scaled up and down as far as necessary to contain the routes. ... the IESG has not understood the necessity to have a working group to refine a globally acceptable approach. Perhaps I'm not understanding your point, but the whole point of my comment is that there's no bright technical line differentiation between one size and another, and we'll inevitably wind up being forced to support the smallest possible one. Perhaps the IESG's reluctance is because this now turns into something like the old (PC-incorrect) joke about the gentleman and the debutante in the railway - we've already decided what we are, now we're only haggling about the price (or block-size, as the case may be). Sigh, we're going to be paying the price for not (long ago) setting up a charging system for having a route be visible in the default-free zone. The existence of a default-free-zone was long ago relegated to myth status. There are different views of what this mythical entity contains, so by definition there is no single zone. I am fully aware that for a variety of reasons, including policy limitations, as well as different aggregation action boundaries (i.e. places where routes to X.1 ... X.n get discarded in favour of a single route to X), different in the 'core' (to use another somewhat nebulous term) routers will have somewhat different routing tables. My reference was more in the sense of 'routers which do not have a routing table which consists of a small number of destinations, and use a default for the rest' - i.e. routers which *do* have to have routing information for the vast majority of the destinations in the entire network. If we had a cost-structure which actually reflected reality (so that PI-address X, which has to have a routing table entry in every router which wants to be able to send traffic to it, had to pay for those routing table entries), we might have a little less enthusiasm for the PI-approach. PI is like spam - it looks attractive to the people using it, because it's free to them. The fact that it costs *other* people money is something they don't care about - it's not coming out of their pocket. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Noel Chiappa wrote: PI is like spam - it looks attractive to the people using it, because it's free to them. The fact that it costs *other* people money is something they don't care about - it's not coming out of their pocket. Where are these free routers and how do I get one? - Kevin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On Mon, 17 Apr 2006, Noel Chiappa wrote: PI is like spam - it looks attractive to the people using it, because it's free to them. The fact that it costs *other* people money is something they don't care about - it's not coming out of their pocket. Noel, While I might have chosen a different metaphor, I can agree with the basic point, yet I wonder: Would you agree with the thesis that *without* pervasive PI, the future of NAT (or some other mechanism for providing address autonomy to organizations) is absolutely guaranteed forever (even with v6)? To me, that seems obvious, so I'd be interested in counter arguments. It does make me wonder if there is any hope for resurrection of 8+8... -teg ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
If I the only choices available are widespread PI and widespread NAT, then we need to really change the way we approach things. Either of those is a very bad answer. Now, at least some of the folks supporting this PI assignment initiative have indicated that they do not believe it will be widespread (either because the barriers will still be high or because the demand for BGP based multi-homing is small, or maybe for some other reason.) If that assumption is correct, then the comparison with NAT is irrelevant. Yours, Joel M. Halpern At 06:57 PM 4/17/2006, Terry Gray wrote: On Mon, 17 Apr 2006, Noel Chiappa wrote: PI is like spam - it looks attractive to the people using it, because it's free to them. The fact that it costs *other* people money is something they don't care about - it's not coming out of their pocket. Noel, While I might have chosen a different metaphor, I can agree with the basic point, yet I wonder: Would you agree with the thesis that *without* pervasive PI, the future of NAT (or some other mechanism for providing address autonomy to organizations) is absolutely guaranteed forever (even with v6)? To me, that seems obvious, so I'd be interested in counter arguments. It does make me wonder if there is any hope for resurrection of 8+8... -teg ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Iljitsch van Beijnum wrote: ... Since this has been coming up from time to time for over a decade, why not look at it, document the results and be done much faster when it comes up again and again the following decade, I would think. That was why I proposed a bof, and will do so again. Noel Chiappa wrote: ... Perhaps I'm not understanding your point, but the whole point of my comment is that there's no bright technical line differentiation between one size and another, and we'll inevitably wind up being forced to support the smallest possible one. That was my point as well. Given that all uses of PI are as legitimate as any other, the issue boils down to finding a way to bucket the results into manageable pieces that will fit in known routers and protocols. Perhaps the IESG's reluctance is because this now turns into something like the old (PC-incorrect) joke about the gentleman and the debutante in the railway - we've already decided what we are, now we're only haggling about the price (or block-size, as the case may be). The first step on the path to deciding price is to do the AA thing and acknowledge that there is no single global perception of all possible routes (ie: there are already buckets). Once that is acknowledged, we know the system doesn't collapse in the presence of buckets, so the next step is to decide who plays which role in the scenario. The pragmatist says our job is to find the point of equally shared pain. The ISPs want all the pain to be at the edge, and randomly assigned PI puts all the pain in the middle. There are alternatives to be explored. Iljitsch and I have similar approaches where the basic difference is who gets to decide the blocks and on what frequency they might change. Either will work, but there may be others that a working group should evaluate for their trade-offs. Keith Moore wrote: ... One could argue that we already have. It's called MPLS... sort of. MPLS with globally-scoped tags, and a database of coarse (think subnet sized) identifer to locator mappings that is distributed via BGP. border routers look at the destination host identifier, find the set of locators that correspond to it, and pick the best locator given current routing conditions. My point was that the technology exists. Yours is that it is currently deployed and operated in a closed manner. I suspect that the difference was because closed was easier than opening it up to manage a global tag list, and that sufficient motivation would change that. Terry Gray wrote: ... It does make me wonder if there is any hope for resurrection of 8+8... The time for that was before the APIs were defined. At this point it would need to be 6+10 (though the e.g.b. control-mongering ISPs are pushing to reduce the amount of space that a sight can have to make it 7+9), but either way it is nothing more than shim6 being done by the edge routers rather than the end systems. The application wants persistence and the network wants the freedom to randomly over-write bits to improve its efficiency (never mind that the process of deciding and over-writing is inherently inefficient). Given that the application is closest to the end user, the end user doesn't care about efficiency unless they are given quantitative feedback about cost, and the globally distributed cost of a routing slot in a fictitious single routing zone is difficult to define, the winner should be obvious. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Terry/David, Terry Gray wrote: *without* pervasive PI, the future of NAT (or some other mechanism for providing address autonomy to organizations) is absolutely guaranteed forever (even with v6)? To me, that seems obvious Obvious it is to me too. Problem is: there are way too many people in here who have successfully renumbered their 4-host home network and never worked into a larger environment who think that because they successfully renumbered their home network in an hour the same can happen with an enterprise network. They've never been out in the real world, no wonder why they still wonder why the real world has embraced NAT. It does make me wonder if there is any hope for resurrection of 8+8... There is not. First, 8+8 had disadvantages. Second, even though GSE and later MHAP tried to reduce the inconvenience, the fact if the matter is that nothing is as simple as raw PI; any dual-space ID-LOC system introduces yet another layer of complexity, bugs, incompatibilities, etc. In the end, it's all about money and timing is important: 8+8 was written when a core router had less memory and processing power than the cell phone I carry. As of today, it costs less to go PI than to go 8+8, without the shortcomings of 8+8. No brainer. David Conrad wrote: The end point identifier's upper 48 (or whatever) bits is being network address translated into the routing locator (the lower 80 bits would be untouched). But to avoid the soul-searing EVIL (plain and simple, from beyond the 8th dimension) of NAT, you simply reverse the translation, restoring the upper 48 bits (which, conveniently, don't have to be carried around in the packet since the destination is pretty much guaranteed to know what end point identifier prefix it is at). The two EVILs cancel each other out. A while ago, I designed exactly what you are describing: http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt It's going the same place than 8+8 and GRE: in the grave. Nice idea, but too much politics and money involved in deploying. Back to raw PI. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF Jabber server changes
At the request of various IETF participants, the IETF Secretariat is offering Jabber service between meetings, on a trial basis, to observe what the usage and demand might be. We are planning to make the following changes to the IETF jabber server: 1). The domain name of the chat room server will be changed from rooms.jabber.ietf.org to jabber.ietf.org. Please note that as soon as this change is made, all connections to the IETF jabber chat rooms will have to specify jabber.ietf.org in the server field of the client software being used. 2). The chat room logs will be renamed. We were asked to have the chat room logs directories appear on the web page as roomname instead of roomname.jabber.ietf.org. Note that all previous chat room logs will continue to be available under the new room directory name. E.g. to see all the chat logs for the sip WG, you will point a browser to www.ietf.org/meetings/ietf-logs. You will then click on the directory line labeled sip, and will be able to see all past chat logs for that WG. Also note that the past chat room logs that were sent to us from xmpp.org will be added to the web site at this time. 3) The chat room logs will be pruned such that the only daily log files that will be retained on the web site will be those which have actual content, i.e. completely empty log files will be removed. 4) Rooms will be created for the IRTF working groups in the jabber.ietf.org domain. Specifically, the following rooms will be added to the available room list: rch, asrg, cfrg, dtnrg, end2end, gsec, iccrg, imrg, nmrg, p2prg, rr, siren, smrg, tmrg. We will make these changes on Tuesday, April 18 during the afternoon. Consequently the IETF jabber server will be off-line during that time. For planning purposes, assume the server will be unavailable between the hours of 2:00pm and 5:00pm EST. It is likely that the server will be returned to service prior to 5:00pm. Regards, The IETF Secretariat. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4472 on Operational Considerations and Issues with IPv6 DNS
A new Request for Comments is now available in online RFC libraries. RFC 4472 Title: Operational Considerations and Issues with IPv6 DNS Author: A. Durand, J. Ihren, P. Savola Status: Informational Date: April 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 29 Characters: 68882 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-dnsop-ipv6-dns-issues-12.txt URL:http://www.rfc-editor.org/rfc/rfc4472.txt This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehavior, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS. This memo provides information for the Internet community. This document is a product of the Domain Name System Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Constrained VPN Route Distribution' to Proposed Standard
The IESG has approved the following document: - 'Constrained VPN Route Distribution ' draft-ietf-l3vpn-rt-constrain-02.txt as a Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Margaret Wasserman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-rt-constrain-02.txt Technical Summary This document addresses scaling issues for VPN routing information maintained atroute reflectors. It extends the RFC2547bis approach using âCooperative Route Filteringâ between router reflectors for support multiple autonomous systems and asymmetric VPN topologies such as hub-and-spoke. The solution uses MP-BGP UPDATE messages to propagate Route Target membership information. Received RouteTarget membership information can then be used to restrict advertisement ofVPN NLRI to peers that have advertised their respective Route Targets, effectively building a route distribution graph. In this model, VPN NLRI routing informationflows in the inverse direction of Route Target membership information. This mechanism is applicable to any BGP NLRI that controls the distribution of routing information based on Route Targets, such as BGP L2VPNs [L2VPN] and VPLS [VPLS]. Working Group Summary There were several detailed issued which were raised when the document was submitted to the WG. Constructive comments led to modifications to the document which addressed the concerns that were raised. Protocol Quality In addition to L3VPN review, this document was reviewed by the IDR WG where it received review comments from Rick Wilder, Chandrashekhar Appanna, and Jeff Haas. Multiple implementations exist. Note to RFC Editor The upper left hand corner of the title page should include: Updates: draft-ietf-l3vpn-rfc2547bis-03 In section 2, please replace proposal with document in the following text: This proposal extends the RFC2547bis [3] ORF work to include support for multiple autonomous systems, and asymmetric VPN topologies such as hub-and-spoke. Also in section 2, please remove the [?] reference, new text is: This mechanism is applicable to any BGP NLRI that controls the distribution of routing information based on Route Targets such as VPLS [9]. Please change the title to: Constrained Route Distribution for BGP/MPLS IP VPNs Please replace the Abstract with: This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information. This information can be used to build a route distribution graph in order to limit the propagation of Virtual Private Network (VPN) Network Layer Reachability Information (NLRI) between different autonomous systems or distinct clusters of the same autonomous system. This document updates draft-ietf-l3vpn-rfc2547bis-03. [RFC Editor: please replace this Internet-Draft reference with an RFC number when it is assigned.] Please add a Terminology Section with the following acronyms expanded and defined and the informational reference to RFC4026: This document uses a number of terms and acronyms specific to Provider-Provisioned VPNs, including those specific to L2VPNs, L3VPNs and BGP. Definitions for many of these terms may be found in the VPN terminology document [RFC4026]. This section also includes some brief acronym expansion and terminology to aid the reader. AFI - Address Family Identifier (a BGP address type) BGP - Border Gateway Protocol BGP/MPLS VPN - A Layer 3 VPN implementation based upon BGP and MPLS. CE - Customer Edge (router) iBGP - Internal BGP; i.e., a BGP peering session that connects two routers within an autonomous system L2VPN - Layer 2 Virtual Private Network L3VPN - Layer 3 Virtual Private Network MP-BGP - Multi-Protocol Border Gateway Protocol MPLS - Multi-Protocol Label Switching NLRI - Network Layer Reachability Information ORF - Outbound Route Filtering PE - Provider Edge (router) RT - Route Target (i.e., a BGP extended community that conditions network layer reachability information with VPN membership) SAFI - Subsequence Address Family Identifier (a BGP address sub-type) VPLS - Virtual Private LAN Service VPN - Virtual Private Network Editor: Please include an informational reference to RFC 4026 in the referencessection. Please change the following text in section 6 From: A BGP speaker should generate the minimum set of BGP VPN route updates necessary to transition between the previous and current state of the route distribution graph that is derived from Route Target membership information. To: A BGP speaker should generate the minimum set of BGP VPN route updates (advertisements and/or withdrawls) necessary to transition between the previous and current state of the route distribution graph that is derived from Route Target membership information.
Protocol Action: 'BGP-MPLS IP VPN extension for IPv6 VPN' to Proposed Standard
The IESG has approved the following document: - 'BGP-MPLS IP VPN extension for IPv6 VPN ' draft-ietf-l3vpn-bgp-ipv6-07.txt as a Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgp-ipv6-07.txt Technical Summary This document describes a method by which a Service Provider may use its packet switched backbone to provide Virtual Private Network services for its IPv6 customers. This method reuses, and extends where necessary, the BGP/MPLS IP VPN method [2547bis] for support of IPv6. In particular, this method uses the same peer model as [2547bis], in which the customers' edge routers (CE routers) send their IPv6 routes to the Service Provider's edge routers (PE routers). BGP (Border Gateway Protocol, [BGP, BGP-MP]) is then used by the Service Provider to exchange the routes of a particular IPv6 VPN among the PE routers that are attached to that IPv6 VPN. Eventually, the PE routers distribute, to the CE routers in a particular VPN, the IPv6 routes from other CE routers in that VPN. As with IPv4 VPNs, a key characteristic of this peer model is that the (IPv6) CE routers within an (IPv6) VPN do not peer with each other and there is no overlay visible to the (IPv6) VPN's routing algorithm. A VPN is said to be an IPv6 VPN, when each site of this VPN is IPv6 capable and is natively connected over an IPv6 interface or sub- interface to the SP backbone via a Provider Edge device (PE). A site may be both IPv4-capable and IPv6-capable. The logical interface on which packets arrive at the PE may determine the IP version. Alternatively the same logical interface may be used for both IPv4 and IPv6 in which case a per-packet lookup at the Version field of the IP packet header determines the IP version. This document only concerns itself with handling of the IPv6 packets. As such the inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. In a similar manner to how IPv4 VPN routes are distributed in [2547bis], BGP and its extensions are used to distribute routes from an IPv6 VPN site to all the other PE routers connected to a site of the same IPv6 VPN. PEs use VPN Routing and Forwarding tables (VRFs) to separately maintain the reachability information and forwarding information of each IPv6 VPN. As it is done for IPv4 VPNs [2547bis], we allow each IPv6 VPN to have its own IPv6 address space, which means that a given address may denote different systems in different VPNs. This is achieved via a new address family, the VPN-IPv6 Address Family, in a fashion similar to the VPN-IPv4 address family defined in [2547bis] and which prepends a Route Distinguisher to the IP address. In addition to its operation over MPLS Label Switched Paths (LSPs), the IPv4 BGP/MPLS VPN solution has been extended to allow operation over other tunneling techniques including GRE tunnels, IP-in-IP tunnels [2547-GRE/IP], L2TPv3 tunnels [MPLS-in-L2TPv3] and IPsec- protected tunnels [2547-IPsec]. In a similar manner, this document allows support of an IPv6 VPN service over MPLS LSPs as well as over other tunneling techniques including GRE tunnels, IP-in-IP tunnels, L2TPv3 tunnels and IPsec-protected tunnels. This document allows support for an IPv6 VPN service over an IPv4 backbone as well as over an IPv6 backbone. The IPv6 VPN service supported is identical in both cases. Working Group Summary This document went smoothly through the WG process. Protocol Quality At least two vendors have developed to earlier versions of this draft. Jeffrey Haas and Pedro Marques both commented on the draft as it went through multiple revisions. RFC Editor Note: The document's references to draft-ietf-ipv6-unique-local-addr-09.txt need to be updated; one section refers to Section 10, which no longer exists. I believeit should refer to Section 4.7. Please search and replace on byte replacing it with octet throughout the document. Please remove the reference to [RFC2547bis] in the Abstract. There are citation inconsistencies, please work with the authors to clear theseup. See tracker for reference check tool output. Please add the following clarifying sentence at the end of Section 5: Recommendations and considerations for which of these supported address types should be used in a given IPv6 VPN environments are beyond the scope of this document ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
