RE: what problem is solved by proscribing non-64 bit prefixes?
I'm aware of several IEEE link layers and none uses 64bit addresses. IEEE tries to have them all 48bit. Even non-IEEE (like USB) tries to be 48bit. Have you ever heard of EUI-64? http://standards.ieee.org/regauth/oui/tutorials/EUI64.html One notable IEEE protocol which uses EUI-64 is Firewire (IEEE 1394). For more info see RFC 3146. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
RE: what problem is solved by proscribing non-64 bit prefixes?
Actually, you cannot just assign a /48 to each site. The RIR H-ratio requirements may make this infeasible. Further, each /48 (/56 for IANA) allocations must be registered with the RIR, which is an administrate headache. Finally, there is the issue of reverse lookup registration for sites. These are just the policy issues. I don't believe that /48 assignments have to be registered with the RIR unless it is a situation where an ISP is assigning the /48 to another entity. Within an enterprise, /48 assignments to a site do not need any RIR interaction. In addition, if you are a large organization, then the RIRs will give you a /32 ISP allocation which should be enough forever, except for a few of the very largest companies. Those companies should actually plan ahead and get a bigger than /32 allocation to begin with. The H-ratio should only ever be an issue for ISPs since their networks are expected to grow continuously and eventually outgrow any allocation. However, RIR rules are set by the networking community collectively and bad rules can be changed. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
RE: what problem is solved by proscribing non-64 bit prefixes?
In a typical IPv6 ADSL household landscape... An ADSL IPv6 operational deployment offers a /64 prefix at home. With that, I can't subnet _and_ use IPv6 stateless auto-configuration. In a typical IPv6 ADSL household landscape the ISP will assign you a /48 with plenty of subnetting space. In some regions there will be some ISPs who will only assign a /56 to residential sites, but that still gives you a reasonable amount of subnetting ability. Under RIR rules, an ISP can justify giving you a /48 if you ask them for it. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
RE: what problem is solved by proscribing non-64 bit prefixes?
When managing such a scheme alongside an IPv6 prefix which needs to be assigned to the same set of servers, which are all dual-stack, the *number* of prefixes, their *relative* numbering, and the host *addresses* within the prefixes, it is quickly apparent that use of only /64 prefixes makes for a management nightmare, particularly if renumbering of prefixes and/or servers occurs, e.g. re-balancing the VLSM arrangement itself in IPv4-land. Given that in IPv6, you can justify allocating a /48 to each separate site, which gives you 16 bits to mirror the IPv4 subnet hierarchy, while maintaining 64 bit interface sddresses, I don't see a technical issue here. And I would really recommend that you upgrade all of your management systems to fully support IPv6 instead of relying on tricks like generating an IPv6 address by applying a transform to an existing IPv4 address. Then you have no technical issue at all. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
RE: the role of the node requirements document
I totally appreciate Alain's concern for cable modem devices with limited memory for IPv6 but the problem is that IPv6 community decided as far back as 1998 with RFC 2401 that IPSec is mandatory for IPv6. The events of 1998 are irrelevant. The fact is that this website http://www.ipv6ready.org/about_phase2_test.html clearly does not consider IPsec to be part of the IPv6 core protocols and therefore lots of implementations will not have it. Cable boxes are not much different from general purpose computers running Linux. In fact, they may use Linux for all I know. In any case, they are complex devices and if you looked at an architecture diagram for them they would like rather like a network in a box with many functions on separate chips (or areas of an FPGA) all communicating with various internal protocols and busses. But IPv6 is not just for devices like that. It was also intended to be something that could be implemented on embedded devices that often use 8-bit CPUs with the IP stack written in carefully handcoded assembly language. TINI is an example of such a device but there are hundreds of them out there and manufacturers continue to introduce new 8-bit microcontrollers all the time. If you have any contacts with Yokogawa in Japan, they have a lot of experience in this area and will be able to give a better idea of how common it is to implement IPv6 without IPsec. WIDE people may also know more about this. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
RE: the role of the node requirements document
I totally appreciate Alain's concern for cable modem devices with limited memory for IPv6 but the problem is that IPv6 community decided as far back as 1998 with RFC 2401 that IPSec is mandatory for IPv6. The events of 1998 are irrelevant. The fact is that this website http://www.ipv6ready.org/about_phase2_test.html clearly does not consider IPsec to be part of the IPv6 core protocols and therefore lots of implementations will not have it. Cable boxes are not much different from general purpose computers running Linux. In fact, they may use Linux for all I know. In any case, they are complex devices and if you looked at an architecture diagram for them they would like rather like a network in a box with many functions on separate chips (or areas of an FPGA) all communicating with various internal protocols and busses. But IPv6 is not just for devices like that. It was also intended to be something that could be implemented on embedded devices that often use 8-bit CPUs with the IP stack written in carefully handcoded assembly language. TINI is an example of such a device but there are hundreds of them out there and manufacturers continue to introduce new 8-bit microcontrollers all the time. If you have any contacts with Yokogawa in Japan, they have a lot of experience in this area and will be able to give a better idea of how common it is to implement IPv6 without IPsec. WIDE people may also know more about this. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6
RE: RFC 4193
Is there any implementation available for RFC 4193 (Unique Local IPv6 Unicast Address) on a host machine? Since the Global ID in these address are to be randomly generated, there is no way to manual assign a local ipv6 address to an interface? You should only generate the Global ID once, for your entire site. Then use this Global ID in the same way that you use the /48 assigned by your ISP, except that you tell all your Internet gateway devices to block fc00::/7 traffic and announcements. This should not affect the way in which interface addresses are assigned and you could certainly use the same interface address with both the ULA prefix and the ISP-assigned prefix. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: Stupid ULA discussion
ULA is LOCAL. It has nothing to do with PI. People need address space to number the links between their SQL and web servers. This is completely orthogonal to address space used on the internet. Agreed! If it's routed at some point, this means we're all getting enough money to change our minds on the merits of routing unroutable space so by definition, we'll be happy with that. In other words, any arguments that say but people will take that address block and use it on the public Internet apply equally to people who use a 3FFE block or just pick some random address block that is not in use. The only thing that stops people from doing this is ISPs policing the BGP routes that they hear which will also stop ULA use. In a way, people are right when they have a gut feel that ULA-C addresses are just like PI addresses. But they forget that they are also like any other unicast IPv6 address. All addresses work everywhere on the Internet, except where they are filtered/policed and ULA-C addresses will be filtered just like any other kind of address which is technically usable, but defined by policy as unusable. And again: keep the RIRs out of this, this has nothing to do with their current business. Really, this is none of our business. When push comes to shove, the IANA is responsible for registering numbers and if they want to delegate the job to RIRs, then they will. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: IPv6 address notation for example IPv6 architectures
You are looking for 2001:0DB8::/32 What I'm looking for now is a 2nd documentation prefix, that would differ in the first bit. Such that nobody could say that this prefix X has an aggregation relationship with 2001:db8::/32. Such that I can picture a Router with two non-hierarchical non-aggregated prefixes on its two interfaces. You could use a ULA address such as fd67:039d:7a3a::/48 That differs in the first bit. If you don't like the one that that I suggested, you could try generating your own at http://www.sixxs.net/tools/grh/ula/ Note that the generator algorithm is random so even if you don't change the MAC address that you enter, you can just keep clicking on Generate until you get an address that looks nice enough. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: IPv6 address notation for example IPv6 architectures
I will however suggest it. For info, this is about discussion around addressing architectures for AUTOCONF WG. As long as it is for discussion there should be no worries about colliding with someone else's use of that /48. And there is no need to register these ULA addresses. In future, we may add another type of ULA address that is centrally registered, and it would probably be a good idea to reserve a block from that space for documentation purposes as well. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: New Version Notification for draft-mrw-6man-ulac-analysis-00
Not sure what you mean by solving this problem. Some people want ULA- C. Presumably, they'll be willing to pay reasonable registration costs. Find a few parties willing to run registries and be done with it. The IETF doesn't need to find anyone to run registries. The registry task is delegated to the IANA. In the case of IP addresses, the IANA has further delegated the task to 5 regional RIRs. I don't think that ULA-C or G addresses are important enough to deviate from this structure. The RIRs already have the capability to communicate with applicants in several languages and it would be expensive and complex for IANA to do this kind of work directly. One advantage of delegating this to the RIRs through IANA is that the IETF does not need to deal with the issue of ULA-C addresses becoming a cheap form of PI addresses since the control of that issue will be in the RIRs. If the network operators do not want ULA-C to become a cheap form of PI addresses, then they will maintain strict ULA filters and participate in their RIR's grass-roots democratic process. In fact, a final ULA-C or G RFC should really contain some language that explains this fact and explains why the IETF does not see the need to take any specific action on the cheap PI issue. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: New Version Notification for draft-mrw-6man-ulac-analysis-00
This sounds like provider independent which is a very different ballgame. The point of ULAs is not that they are independent of any particular provider, they're independent of any and all connectivity to the internet at large. I agree that a ULA-C RFC must state that these addresses are not the same as provider independent addresses and that they are intended for connectivity that does not involve the public Internet. I think it would be reasonable for the RFC to contain a definition of provider independent something like the following: Provider Independent addresses are global unicast addresses that have been allocated to an organization directly by one of the RIRs. As part of the agreement between the RIR and the organization receiving the allocation, these addresses are considered to be for the use of the receiving organization regardless of how they connect to the public Internet. I don't think this is widely held, but it's certainly vocally held. Totally agree on this. Since addresses are only usable when a rather large part of the internet accepts routes for them, it seems rather strange to make this assumption in the presence of explicit standards language that these addresses are NOT to be used in this way. I.e., the argument is that the entire internet is going to to something which is undesireable if these addresses are created. However, if the entire internet is doing it, wouldn't that action by definition be desireable (regardless of whether it's a good idea)? That is a mouthful, but it does seem sensible to assume that either the public Internet will NOT allow ULA-C addresses to be used as PI addresses, or, they will allow it, in which case this is what the operators of the public Internet want. In either case, the IETF only provides the signal as to what is appropriate. It cannot force operators to act one way or another. Does anyone know what is happening with the ULA-G draft? http://sa.vix.com/~vixie/ula-global.txt --Michael Dillon. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: New Version Notification for draft-mrw-6man-ulac-analysis-00
In practice, what are you going to do when you do a DNS lookup for some random domain name and you get a ULA address? Ignore it because you know it's unreachable? Try to send a packet anyway? You have to send a packet because that is the only way to discover if it is reachable or not. The address may be for a device just down the hall from you. Now you might want to configure your DNS proxy (resursive server) to not pass through records with ULA addresses unless they are from known sources with whom you have a prior arrangement. But that is a different issue. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: New Version Notification for draft-mrw-6man-ulac-analysis-00
Now you might want to configure your DNS proxy (resursive server) to not pass through records with ULA addresses unless they are from known sources with whom you have a prior arrangement. But that is a different issue. Now the DNS must know about routing? Why would the DNS need to know anything about routing? ULA addressing is intended for local use. If an organization wants to enforce that policy by putting filters in their routers which talk to the public Internet, they are free to do so. If they want to put filters in the DNS servers which talk to the public Internet, they are free to do so. The DNS filters are about policy, and have nothing to do with routing. You are the one who said that somebody might put ULA addresses in records that are visible to the Internet instead of running proper split-horizon for their internal DNS. If I want to protect my DNS and my systems from somebody elses misconfigurations, then filtering and proxying is the standard way to do it, regardless of whether we are talking about routing packets, DNS queries, http queries or telephone calls. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: Misunderstanding IPv6 (Was: IPv6 Books)
Have you read the analysis pieces on how, Powerpoint doomed the Columbia (space shuttle)? http://www.washingtonpost.com/wp-dyn/content/article/2005/08/2 9/AR2005082901444.html No but I have read the original report of the investigating committee into the Challenger disaster and I remember the cluttered slide which mentioned the O-ring problem. That's why I am not suggesting that the IETF start producing slideware, but instead suggesting that we need a summary prose RFC. It doomed the Columbia, and killed seven astronauts. Not to mention Challenger which also killed astronauts. It matters when people make claims about IPv6 exhaustion based on 2000::3 I hope that isn't how you are characterizing my proposal, or the underlying premise. Did I mention your name? If I recall correctly it was Geoff Huston who raised concerns about IPv6 exhaustion which led to ARIN changing its policies to recommend that ISPs assign /56 blocks to small site users. What I *am* concerned about, is maintaining 1 prefix per ASN, to prevent routing table bloat. As long as the time of multiple IPv6 prefixes per ASN is delayed until IPv4 networks start disappearing from the global routing table, we are OK. I expect to see this begin in 5 years. Rational folks can disagree on how much this needs to be contained. The vendors seem confident that there is no near-term issue here. Basically, this boils down to whatever the WG chair, AD, and consensus of the WG say it is. Precisely. It has to be discussed in the WG for consensus to form, one way or another. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: IPv6 Books (Re: An example of what is wrong with the IETF's IPv6 documentation)
Maybe a wiki or other online / real-time solution would be best, but this will require someone to manage it and people who have a clue to monitor (moderate) it, and most of these people are either doing it or are working on improving it ( i.e. writing RFCs). I think this is the reason why ARIN set up the wiki at http://www.getipv6.info and I have been contributing to this wiki along with a few others. Mostly I have taken comments from mailing lists, such as Brian Carpenter's specific recommandation of two books as being up to date. But it would help if more of the people in IETF who really know IPv6 would go to the wiki and contribute. In particular, there is a page on adressing plans that is very light, more of a strawman than anything else. The wiki *is* being managed by ARIN staff so that SPAM/defacementr attempts are quickly removed. Ideally, the above-mentioned wiki would evolve into an authoritative reference source to other materials on the web and in print. I have started this page http://www.getipv6.info/index.php/Book_Reviews in order to collect such references. Please feel free to add any other books to the page. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: IPv6 Books (Re: An example of what is wrong with the IETF's IPv6 documentation)
Also online: http://www.ip6.com/us/book/index.html (first hit for google (ipv6 book) btw. I've already mentioned that one on http://www.getipv6.info but I can't say that it is recommended unless I learn more about it. I trust Brian Carpenter's recommendation due to his history with the IETF and I think I trust the French book because it is a wiki and Mohsen claims it is being kept up to date. I'm not sure that I trust the other books in your list, especially since you reference Huitema's book which is part of the problem. I have Huitema's book among others, and that is one of the reasons why I don't feel confident that I understand IPv6 well enough to write a draft of Guidelines for RIRs or Guidelines for ISPs. Perhaps there is a newer edition, but is it new enough? Was it, or any of the other books on your list, vetted by enough eyes to be trusted? The advantage of an RFC is that it does undergo some serious vetting by people who went through the process of creating IPv6 and understand how it works. Books written by IPv4 experts are particularly problematic, because how do we know that the author is not blinded by invalid IPv4 assumptions? The 'correct' one for you thus depends on what you are looking for of course ;) Indeed. I'm not looking for a book at all, but an RFC which summarizes the current state of IPv6 that can be used as an authoritative source to win arguments with people who are still stuck in IPv4 thinking. At this point, I have to trawl through dozens of RFCs looking for this information, or else use one of the books Brian recommended and hope that the fact of his recommendation holds some weight. People are just beginning to seriously deploy IPv6, many just in lab test environments. A lot of mistakes are being made because too many people think of IPv6 as IPv4 with more bits. Practical experience is of course the real way to learn to use it. Books are good references though and tend to read easier than RFCs. It takes years to get the practical experience, and even more years to unlearn bad habits. As for readability, an overview RFC is not likely to be as hard to read as a protocol specification. The real issue here is, does the IETF's responsibility end with giving the vendors the specs that they need, or does the IETF have a responsibility to RIRs, network operators, enterprise network managers, and end users? --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: IPv6 Books (Re: An example of what is wrong with the IETF's IPv6 documentation)
Next to that they also have technical reviewers and nowadays in the age of the Internet there are sites where reviews are given about the books and you can base your opinion on that too. I've seen enough inaccuracies in books that I don't really trust the technical review process of publishers, and the website reviews require a certain volume of reviewers in order to converge to a reasonably accurate result. I don't believe any IPv6 books have reached the volume of sales that would result in consensus on review sites. I'm not sure that I trust the other books in your list, especially since you reference Huitema's book which is part of the problem. As I stated, it is the old bible, it is from 1996 or so after all. As such it is FAR from current but still it is a great book, just a wee bit outdated. I think that you and I have a fundamental disagreement on how technical material would be presented. I would prefer to hide wee bit outdated books, just as I don't say anything about Classful addressing when teaching people what an IPv4 address is. VLSM and CIDR is the state of the art, and classful adressing only deserves mention as an afterthought to explain why on earth so many people still talk about Class C blocks. People don't need to know about TLAs, and the wonderful goals of IPNG which were later discarded along the way. They need to know how IPv6 works and how to implement it today. They need to be able to design a sensible addressing plan that maintains the IPv6 architecture and will not require renumbering large parts of their network in a few years to accommodate growth. They need to understand that it is a sin to undersize a subnet block which is the reverse of the situation with IPv4. If you have an IPv6 book collection that that and also IPng Internet Protocol Next Generation by Scott Bradner and Allison Mankin is definitely a must on the shelf. Yet another book that I have on my bookshelf which led me to require an IPv6 reeducation. Books need to be edited and published which takes quite some time and people are not going to redo them everyday. Though, as I noted, most of them have websites which will contain errata fixups and also new chapters or extra material to cover that gap though. Run into a bookstore, browse through them and then decide. It is also a matter of taste and what you want. It takes more than some browsing to judge whether the author really is up to date and not mired in IPv4 thinking or past glories of the IPNG that never was. Indeed. I'm not looking for a book at all, but an RFC which summarizes the current state of IPv6 that can be used as an authoritative source to win arguments with people who are still stuck in IPv4 thinking. Ehmm, you are trying to make an argument against people while you actually don't know what you are talking about? :) I'm not so arrogant as to claim I am all-knowing. That doesn't help win technical arguments. And although I can deal with my own educational needs by plodding through RFCs and books etc., that doesn't help me find a concise overview of the CURRENT state of the IPv6 art to recomment to others, so that they too, can win technical arguments, or see the error of their ways. Really, that won't work. A summary won't help there either, you will need to know really what you want to talk about. Do it, then you know and then you can win arguments. That is if your only target is to always win in those things, sometimes the other party actually makes a very completely valid point... I don't think you understand the situation. There are loads of people with many years of deep IPv4 experience under their belt. They have gotten used to understanding networks and being right when they make design tradeoffs. The vast majority of these people have a very slim understanding of IPv6 and no experience implementing or running it. Yet they will be expected to design and deploy IPv6 networks that take us through the transition period. You can't tell these people to stop what they are doing, and go back to school. This is the audience for the kind of summary that I proposed. In the RIR sphere it will stop people from supporting policies which recommend *ALL* ISPs to assign a /120 to *ALL* customers unless they can justify more space. To my mind, that is not IPv6 and yet in order to argue against such a policy, people have had to trawl through IPv6 RFCs to see if it is clearly written somewhere that assignments should be a /48 except if you know for sure that there will only ever be one subnet in which case a /64 is appropriate. Even then, the RFCs for IPv6 are known to be full of deprecated material, non-standards material, and so forth, that a lot of people doubt whether or not assigning a /48 is the right thing to do. If we had an RFC with Guidelines for RIRs it would not only say that a /48 is right, but it would also explain why it is right and how it fits into a wholistic
RE: Misunderstanding IPv6 (Was: IPv6 Books)
So you are letting people 'design' networks who can't even be bothered to read up? Can you inform me of the places where that is, so that I can avoid them? You seem to think that the world is nice and neat and tidy. That people don't do things unless a more informed person lets them do it. Unfortunately, the world is not like that. And really, what is so hard about giving a /64 per LAN, counting a bit how many subnets you have in this neighborhood and that region and applying some simple arithmetic? Because when that neighborhood needs to expand beyond what you were able to foresee, then you need to restructure both the neighborhood and the region. But if you had stuck to the model of giving a /48 per site, and a /64 per LAN, then you would never suffer this problem. Fortunately the RIRs still in most cases require people to actually submit a network plan before getting an allocation from them. But the network plan counts /48 subnets, not /64s. Fortunately also those very same RIRs do provide excellent guidance when people don't get it. Given that one RIR has already introduced a policy that allocates /56 to small sites, I can see no reason to trust that RIRs are necessarily better informed. The fact that they give excellent advice on IPv4 does not imply that they are capable of giving similarly excellent advice on IPv6. They need to understand that it is a sin to undersize a subnet block which is the reverse of the situation with IPv4. I have one very simple solution to your problem: Write and publish a book or website about this ;) Why add yet another website to the mix? ARIN has set up an educational wiki for IPv6 so I am satisfied to just contribute to that. Because it is a wiki, many people can contribute and errors can be corrected, or conflicting theories can be clearly explained. You will quickly find out that: - not many people will use it - that it is outdated the moment you are done That is not true of wikis. - that the same arguments you raise against those books you are trying to claim are 'inaccurate' also go for your site. If a wiki is inaccurate, then it can be corrected. But you do want the summary so you can win it without actually knowing why those decisions where made, which actually would allow you to argument why they where made, though by other people and thus allow you to make a stronger case? :) It doesn't matter how strong your case is if people don't understand it. The more that you require the other person to learn and understand, the harder it is to convince them of something or displace a mistaken idea. Referring to an IETF standards document is a shortcut for this. Thus you claim to have the answers but are unable to write them down? I've never claimed to have the answers. Also since when are RFC's even remotely the 'current state' anyway? They tend to take a long time to become actual RFC's and vendors tend to do things just a bit different. That's why I am highlighting the fact that now, when we are finally beginning to reach exponential growth of IPv6 deployment, we need to have an RFC that reflects the current state of IPv6. Then they should also know that sometimes they are wrong. They should also know that things change. And that sometimes they need to read a book or a some other material on it. And if they don't know this, and you only have 15 minutes of their time, how do you convince them that they really need to take the time to read the book? Where is the authoritative summary that can be used to make this argument? The current RIR policies are simple: - /48 for end-sites - /64 when you know very sure that that end-site will have only ever one single network behind it. Wrong. The current policies depend on region and in one region, it includes /56 for small sites. There is also a proposal under discussion that would recommend /120 for smallest sites. This has been the same already for the last, what, 5 years++? :) Keeping your head in the sand will not fix the problem. There is a growing number of people tinkering with IPv6 policies and architecture whose goal is to conserve IPv6 address space, just as IPv4 address space is conserved. Since when is anycast an exclusive IPv6 property? Anycast is a routing trick. Nothing more, nothing less. In IPv4, anycast is a routing trick. In IPv6 it is part of the addressing architecture. 1/8th of the total space is currently allocated for unicast. Does that matter? You are only supposed to use the space that gets assigned/allocated to you from a RIR. It matters when people make claims about IPv6 exhaustion based on 2000::3 Actually answer that he doesn't know what he is talking about and go/redirect to a place where they do. tip: [EMAIL PROTECTED] already exists for more than 10 years now and a lot of people have found great help there. Don't be afraid to ask! Are you suggesting that the best we can do to
RE: An example of what is wrong with the IETF's IPv6 documentation
The following thread from ARIN's Public Policy Mailing List is an example of what is wrong with the IETF's documentation of IPv6. I look forward to seeing your draft. Unfortunately, I was not involved in the creation of IPv6, nor did I follow it as RFCs were released and then deprecated, so I don't fully understand it myself. This is a piece of work that needs to be taken on by some of the people who were immersed in the creation of IPv6. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: dickson-v6man-new-autoconf
Of course, once you don't reserve a /44 for each customer, because a /48 is plenty for nearly everybody, the 12 bits turn into 16, making Brian's concerns far less concerning, and probably no concern at all. Well said. I do not support extending 6MAN's mandate to include this draft. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
An example of what is wrong with the IETF's IPv6 documentation
The following thread from ARIN's Public Policy Mailing List is an example of what is wrong with the IETF's documentation of IPv6. People are struggling to understand just how IPv6 works, not at the implementation level of detail, but at a higher level. What is mandatory, what is optional? What are the basic principles, what is the fundamental architecture? Some people argue that IPv6 is merely IPv4 with more bits, therefore all the rules and constraints of IPv4 must necessarily be applied. There is no IETF document that provides the right kind of high-level view of IPv6, and no document that provides guidelines for RIRs. In the absence of such guidance, it appears as though people who plan to alloocate /120's to customers are right, and Brian Dickson is the authoritative voice of the IETF who understands IPv6 most clearly. Most people who make decisions about addressing plans in the RIRs or in ISPs, do not have the time to wade through dozens of RFCs trying to figure out what is NOT DEPRECATED and what is the IPv6 STANDARD. I believe that the 6MAN group should add to its charter two documents: IPv6 guidelines for RIRs and IPv6 Overview for ISPs. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Dickson Sent: 22 October 2007 22:42 To: ARIN PPML Subject: Re: [ppml] IPv6 assignment - proposal for change to nrpm Leo Bicknell wrote: In a message written on Mon, Oct 22, 2007 at 09:31:36AM -0400, Azinger, Marla wrote: 3177 is a recommendation from 2001 and not a standar of any kind. I'm afraid many people are not looking at the right RFC's and/or considering what all needs to be changed if the /64 boundary is to be updated. I'm fairly sure this is not an exhaustive list, /64 is referenced in many locations in different IPv6 RFC's, many of which are standards track. * http://www.faqs.org/rfcs/rfc2373.html IP Version 6 Addressing Architecture Status: Standards Track Section 2.5.1: Interface IDs are required to be 64 bits long... Section 2.5.7: Aggregatable Global Unicast Addresses Section 2.5.8: Local-Use IPv6 Unicast Addresses RFC 2373 was obsoleted by 3531 which was obsoleted by 4291. 2.5.8 is gone, but AGUA is still roughly the same (all but 000 require use of EUI-64 modified), and ditto 2.5.1 * http://www.faqs.org/rfcs/rfc2374.html An IPv6 Aggregatable Global Unicast Address Format Status: Standards Track Section 3.1 makes it clear the lower 64 bits are an interface identifier for I also point out section 3.4 makes a recomendation we continue to use a slow start method: It is recommended that organizations assigning NLA address space use slow start allocation procedures similar to [RFC2050]. 2374 was obsoleted by 3587. * http://www.faqs.org/rfcs/rfc2450.html Proposed TLA and NLA Assignment Rule Status: Informational Section 3: IPv6 Aggregatable Global Unicast Address Format This bit was itself in RFC 2374, which was obsoleted by RFC 3587. * http://www.faqs.org/rfcs/rfc2460.html Internet Protocol, Version 6 (IPv6) Specification Status: Standards Track Section 3: Specifically referrs to 2373 (ADDRARCH) 4291 obsoletes 3531 which obsoleted 2373. (I don't know why 2460 hasn't been updated with the new references...) * http://www.rfc-editor.org/rfc/rfc3177.txt IAB/IESG Recommendations on IPv6 Address Allocations to Sites Status: Informational Section 3: Recomendations This was informational only, from 2001, and IMHO no longer as relevant as it once was. So, by my count, that is 4291 and 3587. My IETF draft also lists 2464 (Ethernet), 4941 (privacy), and 4862 (autoconfiguration). Most other IPv6 RFCs inherit from those few, and mostly the choice is rather axiomatic. Two small changes, basically, in a backward-compatible manner, is meant to be as minimally-disruptive as is possible. (Think surgery to remove a burst appendix or inflamed tonsils.) Anyone interested can see the draft at: http://www.ietf.org/internet-drafts/draft-dickson-v6man-new-au toconf-00.txt My draft even includes the necessary patch for Linux, about 17 lines in total, mostly the result of the necesssary line length provisions for an RFC. (It was 10 lines originally.) Brian ___ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([EMAIL PROTECTED]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at [EMAIL PROTECTED] if you experience any issues. I don't think it is necessary to discuss the quoted text, just be aware of how hard it is to pin down how IPv6 works and find authoritative IETF documents to back up an assertion. --Michael Dillon
RE: Virtualization And IPv6 : Part Of IPv6 Address For Virtual Hosts
Alternatively, you could create a virtual network/link within the physical host, This is precisely what machine virtualization already does. And many setups involve a set of physical hosts providing resources, and a set of virtual machines consuming resources. A management system migrates the virtual machines from host to host as it tries to make the best use of the resources. At any given point in time, the only way to truly know what virtual machines are on a given physical host is to ask the physical host. Since the virtual machines use virtual network interfaces provided by the physical host, this physical host can see MAC addresses and IP addresses. As a management problem, this can be easily solved by an agent which runs on the physical hosts therefore I don't think the IETF needs to do work on this problem. What would be good is for more people to implement pure IPv6 networks on their virtual machine infrastructure and write about it. Since virtualization increases the number of IP addresses consumed per physical machine, it could lead to IPv4 exhaustion happening sooner rather than later. By using pure IPv6 on the virtual machines there is effectively no limit to the number of addresses that can be used, and if someone wants to implement some kind of structured numbering system in their /64 subnet, the bits are freely available to do this. This USENIX paper: http://www.usenix.org/events/usenix06/tech/menon/menon_html/index.html Optimizing Network Virtualization in Xen provides some information on how one of the more popular virtualization environments handles networking. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: prefix length determination for DHCPv6
A fixed length network portion is also simpler and easier to administer and operate if you have the opportunity, which is why I'm an advocate for /48s for nearly everybody. Leaving the problems of dealing with the complexity of variable length prefixes to the expert employees of the network service providers, not their customers, makes good sense to me. Again, I think people who've worked with Novell IPX or Appletalk would also agree. Then you need to get involved in setting RIR policy because this concept of the fixed /48 network size is already starting to disappear. Nobody from the IETF was available to explain why the designers of IPv6 intended for /48 to be the fixed length network size when ARIN passed a policy to allow ISPs to allocate /56s to consumer customers. Even though the ARIN decision was not a bad one, unless better understanding of the IPv6 design is communicated, then the /48 boundary will fade away and everyone will have to renumber their networks when they change providers. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: Closure of IPv6 WG and creation of IPv6 Maintenance WG
The sole purpose of this group is in the maintenance of the core IPv6 protocol specifications and *not* in the development of new solutions or changes to the specifications. For example, the deployment of new transition tools is out of scope of this working group. Proposals for work beyond the scope of this working group should be sent to relevant ADs. The language in this email is quite clear. Interestingly, it is missing from the charter text. I see that there are two kinds of new work that could come up, and the charter should make it clear which new work falls within the charter, and should be submitted to the WG for approval, and which new work should not be submitted to the WG, but to other ADs. For instance if ULA-C fails to meet consensus and in a few months, someone comes up with a ULA-W proposal, that does not involve protocol changes and should go to the WG for approval. But if someone comes up with a new routing proposal which separates locaters and identifiers, that does involve protocol changes and should go to other ADs. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
As far as why site has been abused to mean administrative domain, that comes from the IETF and RIRs being very ISP-centric, as I said; a single downstream connection denotes a single site regardless of how complex the internal network behind it is or how many other locations it serves. Or maybe it doesn't, depending on who's talking; that's the problem. I have always believed that the definition of a site in IPv6 is tied in with the idea that if every site has a /48 subnet assignment, then migration to a different provider only requires changing the prefix bits. The existing subnet topology hidden inside the /48 remains unchanged. By this definition an apartment or family home is a site. An office in big buidling is a site. A company building is a site. A campus-like collection of buildings is a site. Here is where definitions need to be precise and relate back to original goals. A single company may own several buildings and those buildings may be next to each other. I believe that each separate building should be considered to be a site. A campus is more than a collection of buildings because it is difficult, or impossible to separate one building from the group. On a campus there is centralization of utilities, even going so far as to connect all buildings by tunnel systems and heat all buildings via hot water from a central steam plant. Why is the definition of a site so important? Because a site is mobile. It can change providers and it can change ownership indpendent of neighboring sites. By that definition, airplanes, trucks and train carriages are also sites. They are just mobile more frequently than sites in buildings. I think it is important for the IETF to have clear documentation of the interconnectedness of sites, /48 prefixes, mobility, and freedom of choice. At least one RIR now allows ISPs to assign shorter /56 prefixes to consumer sites, i.e. family homes and apartments. This is not necessarily a bad thing since it is rare for a family home to turn into an office without significant infrastructure change. But if there is to be a special size for the family home, it too should be the same worldwide. And it too should be documented by the IETF. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
It is more about creating a address space that can be used for OTHER thing than the DFZ-way of thinking Internet we have now. Up until now, I've been on the fence regarding ULA-centrally-registered address space, but after several comments in the past two days, I now support defining these addresses. Other factors that I think help make the case: 1) The RIR system is already in place to deal with DFZ grey areas. If we delegate the central registry function to the RIRs, they can deal with the details of how such addresses are handed out (automatically or on demand), charges for maintaining the registry and ip6.int services, and sorting out the issues of non-aggregation and global routing table entries. 2) These ULA addresses provide an additional layer of security in a layered security model. If I use my PI addresses for secret internal infrastructure, I must block those ranges in my firewall. Networks which I connect to will likely not block these ranges, so I have one layer of security. If I use ULA addresses, then the vast majority of other networks will block the entire ULA range, thus giving me an additional layer of security. If I need to use ULA addreses to talk to a peer, we can both punch holes in our filters/firewalls. 3) ULA addresses reduce the administrative burden. If I use some PI addresses for secret internal infrastructure, I must repeatedly update filters at the edge to block traffic to these ranges. If I use ULA addresses, then I simply block the entire ULA range and never need to update filters. In general, it seems to me that the benefits fall on the enterprise network side, and the possibly disadvantages fall on the ISP side. The IETF needs to provide technology that supports all users of IPv6. Since there are other mechanisms outside the IETF to deal with the ISPs' issues, I think we need to go ahead with ULA centrally-registered. Paul's draft which assigns 12 bits to each RIR seems to be the right thing since it clearly delineates which RIR is responsible for each subset range, and therefore if an RIR policy dictates special handling for certain ULA addresses, there is a simple technical means to accomplish this. I'm not sure what the status of Paul's document is since the drafts directory only contains this one: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-02.txt Is Paul's superceding that or is there a merge in process? --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
The question here still remains though: how really different is this from PI. In effect it is non-DFZ-PI space that is being defined here. PI (Provider Independent) is not a relevant term to refer to addresses that are allocated to end-user organizations for use in their own networks. There is no provider in such a scenario, therefore the addresses are neither provider-independent nor provider-dependent. In fact, they are local to the end-user network which is why people have been referring to them as Unique Local Addresses (ULA). It appears that we are accumulating enough changes from the original ULA that it is not correct to refer to them as ULA addresses that are centrally registered. However, they are Unique, and they are Local. Perhaps ULRA (Unique Local Registered Addresses) is sufficiently different from ULA that people will not accidentally look to RFC 4193 for advice? --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: [ppml] Why ULA-* will not harm the DFZ
2. Or release space FC00::/8 for another type of use (becuase sitting on the shelf is wasteful) This is a good example of ossified IPv4 thinking. IPv6 is different from IPv4. It is not just IPv4 with more address bits. It is not wasteful to leave IPv6 address ranges sitting on the shelf any more than it is wasteful to assign a /48 prefix to a homeowner. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
At this point it is plain to see that ULA-C is nothing but PI address space, because the IETF is in no position to enforce otherwise. So please, let's just call it what it is. The IETF is not in a position to enforce the special handling of ULA-C addresses however, IANA via the RIRs is in such a position. The C in ULA-C refers to a central registry. It is likely that IANA will appoint the RIRs to handle that function. Since the RIRs only allocate numbers to organizations who sign a contract with the RIR, this places the RIR in a legal position to enforce any special rules that may be attached to ULA-C addresses. The IETF can state its intent that ULA-C address ranges should not be announced on the Internet or routed across the Internet outside of tunneling technologies. The RIRs can then enforce that intent. If the membership of the RIRs decide that it is valuable to allow ULA-C addresses to be used on the Internet and that they can handle the increase of entries in the global routing table, then those members can collectively override the IETF's intent. Essentially, the IETF is placing control over the route announcement question in the hands of those who are actually impacted by the question. If there is any dispute over the specifics of how this is handled, the RIRs are the forum in which it should be worked out. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt
consider an ipv6-reachable light switch in my house. does anyone still think that it can have end to end connectivity, so that if i want to monitor it or control it while on vacation, i'll send IPSEC-signed datagrams from my hotel room to do so? that i'll subject it to every DDoS attack, stack smash attack, IPSEC key guessing attack, plus any other attacks i can't think of or which havn't been invented yet? or do we think that it'll sit in fe80:: and be talked to only by some local (hardened) proxy? or that at best it'll have a ULA-G address, reachable by my household security company's local embedded network but no further? This isn't the use-case that matters because, as you pointed out, light-switches are likely to be hidden behind a master-controller of some sort. The important use-case is devices which need to behave like a telephone set, i.e. raise an alarm when there is an incoming connection attempt and establish a connection upon request of the local user or some device that proxies for the local user. Of course this telephone-set device may be an actual VoIP telephone with attached answering machine. Or it could be something entirely different such as a medical monitoring device, a home security device which is polled at random intervals, or a blackberry-like device, etc. etc. on the other hand, i like where you went with this, so i'll quote it all in hopes that those who didn't read it the first time will read it now: On the other hand, PA is a form of lock-in. Renumbering is painful, if the scope of the renumbering is large. If a PA assignment is directly to an end user, e.g. an enterprise, this in theory isn't likely to be a large scope, or is at least manageable. It is when the PA assignments are further subassigned, that the scope becomes a significant issue, and the pain (of renumbering) grows. yea, verily. tell it, brother! Agreed. This is a problem that still needs to be addressed by the IETF. In IPv4 the excuse was that the number space was limited. But in IPv6 we no longer need to impose one model on everyone. I'm working on a draft that presents one possibility. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
My main question about ULA-C still stands: how is it different from PI? To understand the difference between PI and ULA-C you need to understand the difference between the public Internet and an IP internetwork. Any set of networks that use the Internet Protocols are an IP internetwork. However there is only one public Internet and that is the subset of IP internetworks which have chosen to connect together so that end hosts can communicate without prior arrangements. PI addresses are public Internet addresses which end hosts can use to communicate without prior arrangements. ULA-C addresses can only be used to communicate between end hosts where both ends have made prior arrangements to enable communication between the two ULA-C blocks from which the end-hosts are numbered. Any IP internetwork managed by a single authority can make use of ULA-C addresses because the single authority presumably is in charge of making things work. When two or more authorities who manage internetworks wish to enable inter-authority (inter-AS) communication, they need to make specific arrangements either bilaterally or unilaterally. These arrangements are a lot like Internet peering arrangements although, technically, it is not necessary to use ASes and BGP4 to do this, just hook things up with circuits or tunnels. What is missing in this ULA-C picture is transit. On the public Internet there is the assumption that packets will be carried across as many autonomous networks as necessary to reach their destination. However, when the source address or destination address is ULA-C, the transit assumption breaks down. There is no assumed interconnectivity with ULA-C addresses which makes them quite different from PI addresses. There will be some groups of organizations who find the requirement for making prior arrangements to be very useful. They may not want any packets from sources who have not signed a mutual agreement. These Community Of Interest Networks exist today in the IPv4 world and they are thriving. Examples are the auto industry with ANX and ENX, the air transport industry with Aeronet and the global financial services industry with RadianzNet. I am not suggesting that any of these existing networks would use ULA-C but that they represent real-world use-cases for globally unique registered address space that is explicitly *NOT* routed on the public Internet. The big question here is whether ULA-C presents any advantage over simply using PI and selectivly shutting off the characteristics which are not desirable. For instance, if you never announce your PI prefix on the Internet, then you will never receive any packets without prior arrangement. --Michael Dillon P.S. if anyone has other examples besides automotive, air transport and financial services idustries, I would be interested in hearing about them. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
A site is a network of computers with a single administration, this can mean indeed a major corporation (who maybe even require multiple /48's which is why rfc4193 is a bit off to cover those cases) Where has the IETF redefined the meaning of the word site? In plain English, this word refers to a distinct physical location such as an office or building or campus. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: AfriNIC, ULA-C, why not just get PI space
those in the AfriNIC region who want globally unique, registered space but do not plan to announce the IPv6 PI address space have no method of getting any such space. if anyone reads this differently than i do, please educate me. Do the RIRs actually refuse to allocate addresses to organizations outside their region? If not, then anyone in Africa who needs IPv6 PI can simply go registry shopping. Of course, the reason AfriNIC is *Afri* NIC is to support organizations in Africa. As such, I'm sure it has mechanisms by which organizations in Africa can influence AfriNIC policies. There is really no need to worry about this sort of thing at a global level. Besides, the IETF designs protocols, not RIR policy mechanisms. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
First, s/laptop/platform - where, a platform could be something relatively small (like my laptop) or something quite a bit larger (like a cruise ship). Any points in-between (planes, trains, automobiles, etc.) also meet the description. But, all of them are platforms and all of them are also sites. Don't forget things like the containers full of suitcase that they load into airplanes. Or packing crates full of produce stored in a warehouse, moved into a shipping container, loaded on a truck, transferred to a ship, transferred to a train, loaded on another truck, and unloaded in another warehouse cooler. Or medical devices with built-in computers somewhat analogous to car engine computers, i.e. an insulin drip device which needs to be docked at the pharmacy for data analysis before they refill the insulin tank. Basically, IPv6 will be used for stuff which was sci-fi a few years ago, not just the same old things as IPv4. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt
4) can the ULA-C's be kept out of the DFZ? Since the IETF has no control whatsoever over the DFZ, then the answer has to be, no. The DFZ is the core of the public Internet, one of many internetworks which use IETF protocols. If the operators of the private networks who have formed the DFZ, decide that they don't want ULA-C prefixes in the DFZ, then they won't be there. But that is up to the network operators, not up to the IETF. The IETF's role is not limited to only specifying technology that is useful for the public Internet. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt
I would support Paul proposal, but with one small change. Paul proposes a delegation hierarchy in the ULA-C space: should be replaced with this one: | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | ++-+--+-+-+--+ | Prefix |L| Reserved | RIR Num | LIR Num | User Num | ++-+--+-+-+--+ Something that has been overlooked is the number of bits in each section. How was this number determined? Is it the right number of bits for each level? Is there a technical reason for sticking with octet boundaries here? Does there need to be an actual boundary between the RIR and LIR section at all? I think that the RIR section has too many bits (there are 5 of them) and the LIR section has too few. It seems to me that the boundary between RIR and LIR should be left unspecified. IANA can allocate chunks of whatever size is needed to RIRs as those needs arise. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt
where in my diffs do i restrict RIRs to the current set of RIRs? it's expected that there may be more RIRs in the future. Is this a backdoor attempt to make it possible for sovereign nations to acquire their own IP allocations as proposed by Houlin Zhao of the ITU? --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt
Oddly enough, what I recommend for now is - put ULA-C on the back burner. I generally agree with what Brian has said here and I especially support his recommendation to push this to the backburner and let it stew for a while. We really need more clarity on use-cases for this before going further. And, we need to get a broader perspective, i.e. more people looking at the issues. Make travel plans to attend the next IANA meeting, and in the meantime, join the IANA mailing lists. Voice your concern over PI space issues, and the making available of small PI blocks to all comers. In particular, the whole issue of PI versus ULA-C has not been clearly stated. What does ULA-C bring to the table that cannot be done with PI addresses? If the answer is nothing, then ULA-C is not needed at all. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt and NAT
I'd be more sympathetic to arguments like this if we RFC 4864 didn't insist on recommending the deployment of stateful packet filters in IPv6 that break most of the things NAT breaks in IPv4. It seems to me that you're making the assumption that the only scenario IPv6 will be deployed in is one where end-nodes always have an upstream stateful firewalling device. Even if the stateful firewalling algorithm is being executed by an upstream device, the fact that the IPv6 destination address is globally known means that the device knows exactly which internal device is the intended destination of the packet. This makes it easier for additional software on the upstream device to do something intelligent that will not break connectivity in the way that IPv4 NAT/PAT does. For instance, there could be an application on the end host that receives notifications from the upstream device so that the user can accept the packet flow. Or there could be a bit of software on the upstream device that recognizes this particular packet as belonging to a known protocol which should be allowed through. Some of this already exists in IPv4 such as application layer gateways, but some is yet to be developed. IPv6 brings a fundamental difference, that the end hosts can use globally unique addresses and that the upstream gateways do not need to do any address translation in order to apply stateful firewalling. Once this becomes more widely understood, then some creative solutions like the host notification mentioned above, could be implemented. Also, firewalling is a process. It has already been pointed out that the process could take place on the end hosts. It can also be distributed between the end host and an upstream gateway. Or even partly distributed to a 3rd party host inside the perimeter by diverting the packet flow such as is often done with proxy caching. Because of the broad possibilities it is hard to make absolute statements about what effect firewalls will have on any particular protocol. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt and NAT
Firewalls don't get upgraded to support SCTP and DCCP because applications are all limping along with TCP and UDP. Egg: meet chicken. Sounds like a good area for standardization so that this state of affairs is not carried forward into IPv6. And especially, if there is a standard way for upstream gateways with stateful filtering to talk to end hosts with stateful filtering, then the two of them can agree to divide the work such that the DCCP-related code runs on the end host. If NAT between PA and ULA-C unicast addresses solves a problem for somebody, without breaking anything important that isn't already broken by something else we've already done, then why shouldn't we be pragmatic and define a mostly sensible way for them to do it? No. End hosts that need to communicate on the Internet should have globally unique IPv6 addresses end-to-end. ULA is for end hosts that do not need to communicate beyond the boundaries of an administrative domain. And since IPv6 allows multiple addresses per end-host, those hosts who need to be schizophrenic can use both ULA and globally unique addresses. Network Address Translation does not seem to offer anything new here. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt - avoid policy costs
This is the place for me to say that I believe the draft is wrong in delegating this as an RIR policy matter. Like existing ULAs, ULA-C should be treated as *technical* address space, and we should specify that assignments will be made and recorded by a single instance of a robot, operated by a trusted party. Designation of that trusted party could certainly be a matter for IANA to negotiate with the community. In my earlier comment I mentioned that the RIRs should stock a supply of already-generated ULA-C addresses so that the applicants did not have to wait while 5 RIRs worked out whether or not there was a conflict. Add that to Brian's comment above and you have a scenario where IANA runs the robot, ensures global uniqueness (just like they do with IP addresses) and allocates a supply of ULA-C addresses to an RIR when their supply runs low. Since running the robot and maintaining the database of already-generated ULA-C addresses is a minor technical matter requiring very little technical infrastructure, it seems reasonable for the RFC to specify that IANA should do this. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
In my opinion, this means that the router of the future needs to look a little different, and this has implications for other subsystems. Much of this could conceivably be hidden with DNS, Since when do IP networks require DNS to function. We run a global IPv4 network with over 10,000 customer sites in over 20 countries, and there is virtually no DNS on this network at all. After all, it's an IP network, i.e. its job is forwarding IP packets. As to why DNS is not used, it has something to do with unneccesarily trusting third parties to figure out your packet destinations and the added complexity of DNS. It turns out to be simpler and more flexible to just use IP addresses directly. If you need to fail-over communications to a disaster-recovery site, or merely to a backup server, you can configure two or four IP addresses in the application and let the app sort out where to send packets. DNS should not be overloaded with so many new functions that it becomes a requirement of running an IP network. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
IMHO, if reverse DNS is provided, it should be required that the authoritative DNS servers have non-ULA addresses. Not only that, but since the goal of ULA-C addresses is to provide something similar to what site-local was going to be, perhaps the RIRs should operate authoritative reverse DNS servers for the entire ULA-C space to ensure that reverse DNS for ULA-C addresses is permanently broken on the public Internet. Of course, anyone who wants to run their own internal reverse DNS in their own private network, or networks, should feel free to do so. Is the goal of this document merely to define the ULA-C address range well enough to throw it into the lake and see if it sinks or swims? Or is there some requirement to provide a more workable form of site-local addresses? --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
draft-ietf-ipv6-ula-central-02
In this draft it has some requirements for generating ULA-C prefixes and then in 7.0 it requires the RIRs to publish an RFC documenting how they will implement these requirements. I think it would be better not to require the RIRs to also go through the RFC process after a ULA-C RFC has been issued, if it ever gets to that point. One possible solution is to downgrade this to simply require the RIRs to publish an RIR document explaining how they implement section 3.2. But a better way is for the ULA-C document to include this. I note that any algorithm for checking (and registering) a generated prefix in the 5 RIR databases could easily be done in advance so that each RIR keeps a supply of unique ULA-C prefixes on hand based on their forecast rate of requests for such addresses. That means that an applicant does not have to wait for turnaround time of the uniqueness test. As far as protocols for communication between the RIRs, this should also be specified in the ULA-C document, however it should not develop any new protocols, merely specify that something like XML-RPC or REST be used, and the semantics of the transaction which should be atomic, i.e. test uniqueness and register in one transaction. This transaction should provide some kind of positive response so that there is no possibility of a false positive. And since it will likely be most heavily used to register batches of unique ULA-C prefixes, it should allow for a single transaction to register the entire batch (or at least as many are actually unique). Race conditions can occur here but it is not necessary for a protocol or application to resolve these since this can be done by some manual exception process. As long as conflicting prefixes (ones which have not passed all 5 RIR checks) are removed from all the databases regularly, that is sufficient. --- Michael Dillon Capacity Management, 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 Internet: [EMAIL PROTECTED] Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.btradianz.com One Community One Connection One Focus IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
