From remi.despres at free.fr Mon Jan 4 10:34:37 2010 From: remi.despres at free.fr (=?iso-8859-1?Q?R=E9mi_Despr=E9s?=) Date: Mon, 4 Jan 2010 10:34:37 +0100 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: <4B344510.7030206@necom830.hpcl.titech.ac.jp> References: <4B30AA0F.5050804@ukraine.su> <4B30C3A5.2030304@necom830.hpcl.titech.ac.jp> <4B30DB88.3050807@ukraine.su> <4B33F49B.5010905@necom830.hpcl.titech.ac.jp> <4B344510.7030206@necom830.hpcl.titech.ac.jp> Message-ID: Le 25 d?c. 2009 ? 05:52, Masataka Ohta wrote : > > As a person who changed IPv6 address structure from 10+6 to 8+8, > trying to make IPv6 a little better than the worst, I know very > well how IPv6 fails to work. Not being such a person, I would be interested in learning in what "IPv6 fails", as you say. (Just stating that IPv6 doesn't help to solve problems!) Can you, please, provide a list of failures you identify for native IPv6 where it is available in addition to IPv4 (leaving out Teredo, 6to4 and ISATAP, which are not IPv6 per se). References to written material would be appreciated. I didn't work on 10+6 and 8+8, but my experience is that of a daily user of native IPv6. As such, I reach in IPv6 various Google and IETF servers, which I use intensively, without having done anything special. (I just enabled IPv6 in my OS which doesn't have IPv6 active by default). Servers that advertise only IPv4 addresses are reached in IPv4 as from anywhere. Note that if more and more hosts would have native IPv6 (in addition to IPv4), and more and more servers would advertise IPv6 addresses (in addition to IPv4), then: o less and less traffic would be IPv4 o NATs (still present for legacy hosts servers and/or service providers) would be less and less used and thus avoid port shortages o peer-to-peer applications would work better where IPv4 is available only through cascades of NATs. Regards, RD From mohta at necom830.hpcl.titech.ac.jp Tue Jan 5 09:35:40 2010 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 05 Jan 2010 17:35:40 +0900 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: References: <4B30AA0F.5050804@ukraine.su> <4B30C3A5.2030304@necom830.hpcl.titech.ac.jp> <4B30DB88.3050807@ukraine.su> <4B33F49B.5010905@necom830.hpcl.titech.ac.jp> <4B344510.7030206@necom830.hpcl.titech.ac.jp> Message-ID: <4B42F9DC.5030600@necom830.hpcl.titech.ac.jp> Remi Despres wrote: >>As a person who changed IPv6 address structure from 10+6 to 8+8, >>trying to make IPv6 a little better than the worst, I know very >>well how IPv6 fails to work. > Not being such a person, I would be interested in learning in what > "IPv6 fails", as you say. > (Just stating that IPv6 doesn't help to solve problems!) > Can you, please, provide a list of failures you identify for native > IPv6 where it is available in addition to IPv4 (leaving out > Teredo, 6to4 and ISATAP, which are not IPv6 per se). Though there are so many failures of IPv6, an example suitable for discussion here is a failure to aggregate routes. > References to written material would be appreciated. IPv6 address allocation policies are the written material. Never say there are ongoing effort to solve the problem, as I know similar efforts have failed several times, already. Another example is a problem of transport payload size. Please simply answer the following question: With 1280B of path MTU, how many bytes, do you think, are assured to be carried over UDP over IPv6 without fragmentation? Note that IPv6 optional headers can be indefinitely long. Note also that DNS (plain ones without DNSSEC) requires 512B must be carried over UDP. > o peer-to-peer applications would work better where IPv4 is > available only through cascades of NATs. I'm afraid you mean "better than" and peer-to-peer applications have difficulties to run over NAT, especially cascaded NAT, which is not the case with end to end NAT. Masataka Ohta From remi.despres at free.fr Tue Jan 5 12:05:32 2010 From: remi.despres at free.fr (=?iso-8859-1?Q?R=E9mi_Despr=E9s?=) Date: Tue, 5 Jan 2010 12:05:32 +0100 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: <4B42F9DC.5030600@necom830.hpcl.titech.ac.jp> References: <4B30AA0F.5050804@ukraine.su> <4B30C3A5.2030304@necom830.hpcl.titech.ac.jp> <4B30DB88.3050807@ukraine.su> <4B33F49B.5010905@necom830.hpcl.titech.ac.jp> <4B344510.7030206@necom830.hpcl.titech.ac.jp> <4B42F9DC.5030600@necom830.hpcl.titech.ac.jp> Message-ID: Masataka, Thanks for your answer. Comments below. Le 5 janv. 2010 ? 09:35, Masataka Ohta a ?crit : > Remi Despres wrote: > >>> As a person who changed IPv6 address structure from 10+6 to 8+8, >>> trying to make IPv6 a little better than the worst, I know very >>> well how IPv6 fails to work. > >> Not being such a person, I would be interested in learning in what >> "IPv6 fails", as you say. >> (Just stating that IPv6 doesn't help to solve problems!) >> Can you, please, provide a list of failures you identify for native >> IPv6 where it is available in addition to IPv4 (leaving out >> Teredo, 6to4 and ISATAP, which are not IPv6 per se). > > Though there are so many failures of IPv6, an example suitable for > discussion here is a failure to aggregate routes. Avoiding the need for provider independent prefixes is an important goal, but IPv4 misses this goal too. Note, besides, that the work I started on SAM (stateless map-and-encaps for simplified mesh-softwire topologies) is precisely expected to lead to a solution in IPv6. (Draft-despres-sam-03 and draft-despres-softwire-mesh-sam-01 are planned to be replaced by a better successor for IETF77). >> References to written material would be appreciated. > > IPv6 address allocation policies are the written material. > > Never say there are ongoing effort to solve the problem, as I know > similar efforts have failed several times, already. I agree that IPv6 address allocation policies still need evolution. But I also believe that router and host IPv6 behaviors should be complemented for these policies to fully take advantage of the IPv6 potential concerning multihoming and renumbering. > Another example is a problem of transport payload size. Please > simply answer the following question: > > With 1280B of path MTU, how many bytes, do you think, are > assured to be carried over UDP over IPv6 without > fragmentation? Since fragmentation is in IPv6 an end-to-end function, I don't see why it would be important to have a fixed value for this number. (A sender that needs no IPv6 option may send without fragmentation more payload bytes than another that needs some options, e.g. for IPsec. Why would this be a problem?) > Note that IPv6 optional headers can be indefinitely long. The format indeed permits it. Having formats that don't limit lengths is good to have, but doesn't imply that there exists no practical limit. In practice today, the fragmentation option having to be in the first packet (limited to 1280B if nothing better is guaranteed), and the length of options that follow being limited even for sophisticated uses (IPsec or mobility), there is AFAIK such a practical limit today. > Note also > that DNS (plain ones without DNSSEC) requires 512B must be carried > over UDP. No problem in IPv6, even if, due to a non typical number of options, datagrams would need to be fragmented. > >> o peer-to-peer applications would work better where IPv4 is >> available only through cascades of NATs. > > I'm afraid you mean "better than" and peer-to-peer applications have > difficulties to run over NAT, especially cascaded NAT, which is not > the case with end to end NAT. I meant that in IPv6 P2P always works, while in IPv4 it works only with limitations if via NATs. End to end NAT is in my understanding a proposal that eliminates these limitations if added to the current IPv4. But these limitations can also be eliminated by using IPv6. This works already where providers, like Free in France, offer native IPv6 in addition to NATed IPv4. IMHO, it would be useful at this stage to list IPv6 functions that can be used safely and usefully. This could result in the definition of an *IPv6 basic-user profile*. Regards, RD From mohta at necom830.hpcl.titech.ac.jp Tue Jan 5 14:00:46 2010 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 05 Jan 2010 22:00:46 +0900 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: References: <4B30AA0F.5050804@ukraine.su> <4B30C3A5.2030304@necom830.hpcl.titech.ac.jp> <4B30DB88.3050807@ukraine.su> <4B33F49B.5010905@necom830.hpcl.titech.ac.jp> <4B344510.7030206@necom830.hpcl.titech.ac.jp> <4B42F9DC.5030600@necom830.hpcl.titech.ac.jp> Message-ID: <4B4337FE.1010807@necom830.hpcl.titech.ac.jp> Remi Despres wrote: >>Though there are so many failures of IPv6, an example suitable for >>discussion here is a failure to aggregate routes. > Avoiding the need for provider independent prefixes is an important > goal, but IPv4 misses this goal too. > Note, besides, that the work I started on SAM (stateless map-and-encaps FYI, the architecturally correct solution, which is applicable both to IPv4 and IPv6, was given in draft-ohta-e2e-multihoming-00.txt issued on April 2000. > (Draft-despres-sam-03 and draft-despres-softwire-mesh-sam-01 > are planned to be replaced by a better successor for IETF77). FYI, selection of the proper address requires the concept of time out, which does not exist in connectionless IP layer, which means the problem must be solved in transport layer (TCP) or above (applications over UDP). NAT-like approaches to solve the problem at the IP layer are all broken. > I agree that IPv6 address allocation policies still need evolution. With 4B or 6B port numbers, the problem can be solved as address/port allocation polices of port restricted IPv4. > But I also believe that router and host IPv6 behaviors should >>Another example is a problem of transport payload size. Please >>simply answer the following question: >> >> With 1280B of path MTU, how many bytes, do you think, are >> assured to be carried over UDP over IPv6 without >> fragmentation? > Since fragmentation is in IPv6 an end-to-end function, I don't > see why it would be important to have a fixed value for this number. There is a reason why ISPs must filter ICMPs against fragmentation errors. What, do you think, will happen if your access and backbone MTU are 1500B and you send 1500B multicast packets to people many of which are using PPPoE? If ISPs filter ICMPs against multicast fragmentation errors, most ISPs will filter all the ICMPs. Worse, even if fragmentation had worked, there can be indefinitely lengthy optional headers *BEFORE* a fragmentation header that you can not even assume fragmentation possible. > (A sender that needs no IPv6 option may send without fragmentation > more payload bytes than another that needs some options, e.g. for > IPsec. Why would this be a problem?) Because, optional header is not always under the control of applications, as exemplified by MIPv6 headers. > Having formats that don't limit lengths is good to have, but > doesn't imply that there exists no practical limit. FYI, my proposal to IPv6 WG to limit the length to allow for 512B or 1024B DNS message size was voted down, which means the practical limit, conceived by IPv6 WG, can be as large as or even larger than 1280B. > In practice today, the fragmentation option having to be in > the first packet (limited to 1280B if nothing better is > guaranteed), and the length of options that follow being > limited even for sophisticated uses (IPsec or mobility), > there is AFAIK such a practical limit today. Please simply answer the following question: With 1280B of path MTU, how many bytes, do you think, are assured to be carried over UDP over IPv6 without fragmentation? If you can't, you may assume some practical upper limit on IPv6 optional header length and standardize it in IETF. Then, you can start deploying modified specification expecting that implementations of it will be widely deployed within the next 20 years. >>Note also >>that DNS (plain ones without DNSSEC) requires 512B must be carried >>over UDP. > No problem in IPv6, even if, due to a non typical number of > options, datagrams would need to be fragmented. With IPv4, header length of which is at most 60B long, fragmentation is always possible. With IPv6, you can expect nothing. > End to end NAT is in my understanding a proposal that eliminates > these limitations if added to the current IPv4. No, it's not an addition. It's a way to implement NAT, which requires no changes on IPv4 routers in public or private IP networks. > This works already where providers, like Free in France, offer > native IPv6 in addition to NATed IPv4. It's a lot of fun to see ISPs, not knowing how ICMPv6 works against multicast fragmentation errors, say they deploy IPv6. > IMHO, it would be useful at this stage to list IPv6 functions > that can be used safely and usefully. Thanks to indefinitely lengthy optional headers, no applications work safely over IPv6. Masataka Ohta From remi.despres at free.fr Tue Jan 5 17:21:37 2010 From: remi.despres at free.fr (=?iso-8859-1?Q?R=E9mi_Despr=E9s?=) Date: Tue, 5 Jan 2010 17:21:37 +0100 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: <4B4337FE.1010807@necom830.hpcl.titech.ac.jp> References: <4B30AA0F.5050804@ukraine.su> <4B30C3A5.2030304@necom830.hpcl.titech.ac.jp> <4B30DB88.3050807@ukraine.su> <4B33F49B.5010905@necom830.hpcl.titech.ac.jp> <4B344510.7030206@necom830.hpcl.titech.ac.jp> <4B42F9DC.5030600@necom830.hpcl.titech.ac.jp> <4B4337FE.1010807@necom830.hpcl.titech.ac.jp> Message-ID: <0F46B08E-D0AC-4AB8-8955-F38B60D96D71@free.fr> Le 5 janv. 2010 ? 14:00, Masataka Ohta a ?crit : > Remi Despres wrote: > >> Note, besides, that the work I started on SAM (stateless map-and-encaps > > FYI, the architecturally correct solution, which is applicable both > to IPv4 and IPv6, was given in draft-ohta-e2e-multihoming-00.txt > issued on April 2000. Thanks for the interesting reference. However, talking about THE solution seems to me too much: - The SAM approach (to be soon renamed Mesh-softwire lite - MSL) avoids your requirement that hosts run BGP, and support the full worldwide routing table. - Named based extensions of socket APIs seem IMHO to have more potential than multiple address APIs. >> (Draft-despres-sam-03 and draft-despres-softwire-mesh-sam-01 >> are planned to be replaced by a better successor for IETF77). > > FYI, selection of the proper address requires the concept of > time out, which does not exist in connectionless IP layer, which > means the problem must be solved in transport layer (TCP) or > above (applications over UDP). It is clear that UDP is adequate only if E2E paths are not too frequently broken, and if broken connections are acceptable if they are rare. To change connection addresses on the fly, if needed to avoid breaking connection when E2E paths break, using DCCP in place of UDP seems a natural approach (and using SCTP, Shim6, or Multipath TCP, in place of TCP). > NAT-like approaches to solve the problem at the IP layer are > all broken. Agreed. But note that the SAM-MSL approach is not in this category. >> I agree that IPv6 address allocation policies still need evolution. > > With 4B or 6B port numbers, the problem can be solved as address/port > allocation polices of port restricted IPv4. Such a drastic evolution, only justified to avoid IPv6, would be unreasonable. (IPv6 is available in router and host products, and successfully deployed in some subsets of the Internet.) >>> Another example is a problem of transport payload size. Please >>> simply answer the following question: >>> >>> With 1280B of path MTU, how many bytes, do you think, are >>> assured to be carried over UDP over IPv6 without >>> fragmentation? > >> Since fragmentation is in IPv6 an end-to-end function, I don't >> see why it would be important to have a fixed value for this number. > > There is a reason why ISPs must filter ICMPs against fragmentation > errors. What, do you think, will happen if your access and backbone > MTU are 1500B and you send 1500B multicast packets to people many > of which are using PPPoE? If ISPs filter ICMPs against multicast > fragmentation errors, most ISPs will filter all the ICMPs. In IPv6, fragmentation errors being an end-to-end matter, ISPs that don't support IPv6 multicast themselves are not concerned. E2E fragmentation is IMHO one of the significant pluses of IPv6. > Worse, even if fragmentation had worked, there can be indefinitely > lengthy optional headers *BEFORE* a fragmentation header that you > can not even assume fragmentation possible. > >> (A sender that needs no IPv6 option may send without fragmentation >> more payload bytes than another that needs some options, e.g. for >> IPsec. Why would this be a problem?) > > Because, optional header is not always under the control of > applications, as exemplified by MIPv6 headers. Applications are and must remain unaware of whether their datagrams are transmitted in single or multiple fragments. >> Having formats that don't limit lengths is good to have, but >> doesn't imply that there exists no practical limit. > > FYI, my proposal to IPv6 WG to limit the length to allow for > 512B or 1024B DNS message size was voted down, which means the > practical limit, conceived by IPv6 WG, can be as large as or > even larger than 1280B. ` The IP layer introduces per se no constraint on DNS-message lengths. This is not an IP layer issue. >> In practice today, the fragmentation option having to be in >> the first packet (limited to 1280B if nothing better is >> guaranteed), and the length of options that follow being >> limited even for sophisticated uses (IPsec or mobility), >> there is AFAIK such a practical limit today. > > Please simply answer the following question: > > With 1280B of path MTU, how many bytes, do you think, are > assured to be carried over UDP over IPv6 without > fragmentation? > > If you can't, you may assume some practical upper limit on IPv6 > optional header length and standardize it in IETF. Then, you can > start deploying modified specification expecting that > implementations of it will be widely deployed within the next > 20 years. Native IPv6 is deployed today and, for its users, works fine for a number of applications (without harm to other applications that use IPv4 as before). I don't understand this point about needing to wait. > >>> Note also >>> that DNS (plain ones without DNSSEC) requires 512B must be carried >>> over UDP. > >> No problem in IPv6, even if, due to a non typical number of >> options, datagrams would need to be fragmented. > > With IPv4, header length of which is at most 60B long, fragmentation > is always possible. With IPv6, you can expect nothing. I don't understand what you mean. > >> End to end NAT is in my understanding a proposal that eliminates >> these limitations if added to the current IPv4. > > No, it's not an addition. It's a way to implement NAT, which requires > no changes on IPv4 routers in public or private IP networks. To me, extending the specification of IPv4 NATs and of IPv4-capable hosts is a modification of the IPv4 protocol suite. But this is just a vocabulary question. The important fact is that existing products generally support IPv6 basic functions, and generally AFAIK don't support E2E-NAT. >> This works already where providers, like Free in France, offer >> native IPv6 in addition to NATed IPv4. > > It's a lot of fun to see ISPs, not knowing how ICMPv6 works against > multicast fragmentation errors, say they deploy IPv6. It's not that they "say" to have deployed it: their customers, of which I am, actually use it. The fact that they don't support multicast can be reason why their IPv6 service works nicely. (But note that they don't support multicast in IPv4 either.) I am not familiar enough with this issue to discuss it more. A good reference about it would be appreciated. >> IMHO, it would be useful at this stage to list IPv6 functions >> that can be used safely and usefully. > > Thanks to indefinitely lengthy optional headers, no applications > work safely over IPv6. This statement seems to me completely ideological! There exists today, and in the real world, applications that DO WORK safely over IPv6. Are you ignoring it? Or willing to deny it? If a host has a native IPv6 address, its real world OS (Windows, OS X, Linux etc) does not add options that might create problems. (AFAIK, the only option used is for fragmentation.) It's time, IMHO, to avoid fighting the lost battle against IPv6 being deployed and used. RD From mohta at necom830.hpcl.titech.ac.jp Tue Jan 5 18:56:04 2010 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 06 Jan 2010 02:56:04 +0900 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: <0F46B08E-D0AC-4AB8-8955-F38B60D96D71@free.fr> References: <4B30AA0F.5050804@ukraine.su> <4B30C3A5.2030304@necom830.hpcl.titech.ac.jp> <4B30DB88.3050807@ukraine.su> <4B33F49B.5010905@necom830.hpcl.titech.ac.jp> <4B344510.7030206@necom830.hpcl.titech.ac.jp> <4B42F9DC.5030600@necom830.hpcl.titech.ac.jp> <4B4337FE.1010807@necom830.hpcl.titech.ac.jp> <0F46B08E-D0AC-4AB8-8955-F38B60D96D71@free.fr> Message-ID: <4B437D34.3010600@necom830.hpcl.titech.ac.jp> Remi Despres wrote: In this mail, I assume readers have read the original paper on the end to end principle by Saltzer et. al. and understand the implications of "completely and correctly" mentioned in the paper. > However, talking about THE solution seems to me too much: > - The SAM approach (to be soon renamed Mesh-softwire lite - MSL) > avoids your requirement that hosts run BGP, As is discussed in my ID, BGP is not my requirement. > and support the full worldwide routing table. That is not my requirement, either, though small full routing table helps to guess the best address to try. > - Named based extensions of socket APIs seem IMHO to have more > potential than multiple address APIs. As was proven in my previous mail, as IP layer (hostnames belongs to IP layer) is connectionless and does not support notion of time out, proposals not involving transport layer of end systems are broken. They must, like legacy NAT, guess transport layer time out. The guesses, not using "knowledge and help" of end systems, are not done "completely and correctly" as is discussed in the original end to end paper of Saltzer et. al. > It is clear that UDP is adequate only if E2E paths are not too > frequently broken, and if broken connections are acceptable > if they are rare. Connection? UDP, in general, is connectionless and applications like vanilla DNS works with request and reply without establishing connection, at least not TCP-like connection. Still, note that RFC1035 requires DNS implement end to end multihoming. > To change connection addresses on the fly, If you think DNS an important application, never say connection. >>NAT-like approaches to solve the problem at the IP layer are >>all broken. > But note that the SAM-MSL approach is not in this category. Anything relying on incorrect and incomplete guesses on route failure is NAT-like and violates the end to end principle. >>With 4B or 6B port numbers, the problem can be solved as address/port >>allocation polices of port restricted IPv4. > Such a drastic evolution, only justified to avoid IPv6, would > be unreasonable. As changes required to support IPv6 is a lot more drastic, you successfully deny IPv6. > In IPv6, fragmentation errors being an end-to-end matter, In IPv6, fragmentation is end to end. However, as fragmentation errors are generated by intermediate routers, fragmentation handling of IPv6 is not at all end to end. As such, path MTUs guessed by end hosts are "incomplete and incorrect", which is why path MTU discovery performs poorly violating the end to end principle. For example, end hosts can not directly know path MTU increase, which is "incomplete and incorrect". > ISPs that don't support IPv6 multicast themselves are not concerned. The ISPs must filter fragmentation errors, to protect their customers from ICMP implosion caused by 1500B multicast packets sent from other ISPs with forged source addresses. > E2E fragmentation is IMHO one of the significant pluses of IPv6. E2E fragmentation relies on PMTUD. If only PMTUD, which is not end to end, had worked. > Applications are and must remain unaware of whether their datagrams > are transmitted in single or multiple fragments. Applications over UDP like DNS should be aware, just as TCP is aware. ` > The IP layer introduces per se no constraint on DNS-message lengths. Please simply answer the following question: With 1280B of path MTU, how many bytes, do you think, are assured to be carried over UDP over IPv6 without fragmentation? > Native IPv6 is deployed today and, for its users, works fine for > a number of applications (without harm to other applications that > use IPv4 as before). Then, you should be able to answer the question above. Please. >>With IPv4, header length of which is at most 60B long, fragmentation >>is always possible. With IPv6, you can expect nothing. > I don't understand what you mean. Read RFC791, how well IPv4 is designed with its fragmentation. > To me, extending the specification of IPv4 NATs and of IPv4-capable > hosts is a modification of the IPv4 protocol suite. That's not a useful definition. > The important fact is that existing products generally support > IPv6 basic functions, and generally AFAIK don't support E2E-NAT. That's not an important fact that port restricted IP, including but not limited to E2E NAT, is not supported by most equipment, because port restricted IP can be deployed locally and still interact with the rest of the world. On the other hand, IPv6 deployment requires IPv6 deployment at the network and at both ends, which is, as you can see even 15 years after RFC1883, impossible. > The fact that they don't support multicast can be reason why > their IPv6 service works nicely. See above for a possible ICMP implosion DOS attack. > I am not familiar enough with this issue to discuss it more. > A good reference about it would be appreciated. RFC2463 (ICMPv6 spec.). >>Thanks to indefinitely lengthy optional headers, no applications >>work safely over IPv6. > This statement seems to me completely ideological! Then, try to answer my simple question above. > There exists today, and in the real world, applications that > DO WORK safely over IPv6. People working on DNSSEC seriously (though DNSSEC is bogus) want to know how long messages can be safely sent over UDP over IPv6. Your answer to my question will be quite helpful for them. > Are you ignoring it? Or willing to deny it? I'm afraid you have been ignoring UDP and DNS, which are my examples to deny IPv6. > If a host has a native IPv6 address, its real world OS (Windows, > OS X, Linux etc) does not add options that might create problems. > (AFAIK, the only option used is for fragmentation.) As I already mentioned, optional headers are added with MIPv6. > It's time, IMHO, to avoid fighting the lost battle against IPv6 > being deployed and used. IPv6 was wrongly specified, vigorously implemented, partially deployed, partially used and totally failed, partly because of broken specification. That's all. Masataka Ohta From jim at rfc1035.com Tue Jan 5 19:01:39 2010 From: jim at rfc1035.com (Jim Reid) Date: Tue, 5 Jan 2010 18:01:39 +0000 Subject: [address-policy-wg] IPv6 PI for HOSTING In-Reply-To: <4B437D34.3010600@necom830.hpcl.titech.ac.jp> References: <4B30AA0F.5050804@ukraine.su> <4B30C3A5.2030304@necom830.hpcl.titech.ac.jp> <4B30DB88.3050807@ukraine.su> <4B33F49B.5010905@necom830.hpcl.titech.ac.jp> <4B344510.7030206@necom830.hpcl.titech.ac.jp> <4B42F9DC.5030600@necom830.hpcl.titech.ac.jp> <4B4337FE.1010807@necom830.hpcl.titech.ac.jp> <0F46B08E-D0AC-4AB8-8955-F38B60D96D71@free.fr> <4B437D34.3010600@necom830.hpcl.titech.ac.jp> Message-ID: <9A2D596F-A02C-479C-B5AC-2789FDEDE555@rfc1035.com> On 5 Jan 2010, at 17:56, Masataka Ohta wrote: > As is discussed in my ID, BGP is not my requirement. Can this discussion take place somewhere else? It does not now have anything relevant or appropriate for this list. From xavier at ripe.net Thu Jan 21 12:14:26 2010 From: xavier at ripe.net (Xavier Le Bris) Date: Thu, 21 Jan 2010 12:14:26 +0100 Subject: [address-policy-wg] 2009-03 "Run-out fairly" implemented Message-ID: <4B583712.4020109@ripe.net> [Apologies for duplicate e-mails.] Dear Colleagues, We are pleased to announce that the policy described in proposal 2009-03,"Run Out Fairly", has been implemented. Requests for IPv4 address space received on or after Friday, 22 January will be evaluated by the RIPE NCC Registration Services Department under the new policy. Full text of the policy proposal can be found at: http://ripe.net/ripe/policies/proposals/2009-03.html The following RIPE documents have been updated to reflect this policy implementation: http://www.ripe.net/ripe/docs/ripe-488.html http://www.ripe.net/ripe/docs/ripe-489.html http://www.ripe.net/ripe/docs/ripe-490.html http://www.ripe.net/ripe/docs/ripe-491.html Regards, Xavier Le Bris Registration Services From filiz at ripe.net Thu Jan 28 16:25:22 2010 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 28 Jan 2010 16:25:22 +0100 Subject: [address-policy-wg] New Draft Document: Autonomous System (AS) Number Assignment Policies Message-ID: <4EB94849-8F66-43C0-9111-CEC2FA03D11D@ripe.net> Dear Colleagues, At the RIPE 59 Meeting in Lisbon last October, the RIPE NCC announced that it would undertake a project to improve the language of various RIPE policy documents, without changing their substance or meaning. This project is aimed at improving the clarity and readability of RIPE Documents. For more information, see: http://www.ripe.net/ripe/updated-documents/ A draft of the first RIPE Document to be revised is now available: "Autonomous System (AS) Number Assignment Policies and Procedures". We have published the draft document in two layouts. The first layout contains only the proposed text, in full, and is available at: http://www.ripe.net/ripe/updated-documents/ASN-v1.html The second layout contains both the current text and the proposed text side by side, and is available at: http://www.ripe.net/ripe/updated-documents/ASN-v2.html At the top of both draft documents there is a summary of the proposed changes. There are two changes we would like to highlight because they constitute a slightly larger change. Paragraph 4.0 - Returning AS Numbers Excerpt from current version: "If an organisation has an AS Number that is no longer in use, it can be returned to the public pool of AS Numbers..." Excerpt from proposed draft: "If an organisation no longer uses the AS Number, it must be returned to the public pool of AS Numbers." The main difference is that the current version says the AS Number "can" be returned, while the draft version says the AS Number "must" be returned. The change was made to better reflect the intention of the policy and to be consistent. In other policy documents, for other Internet resources, the wording of the policy states "must". The other larger change is the addition of the following paragraph: Paragraph 5.0 - Validity of an Assignment This paragraph is copied from the IPv4 policy document ("IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"). As this seems to be a shared policy principle, applicable to all Internet resources, we feel it is appropriate to add this text to the AS policy document, both for clarity and consistency. Other smaller changes are listed at the top of document. Please review the text and send your feedback to the Address Policy Working Group mailing list. The period for review is four weeks and lasts until 26 February 2010. After the review period, the Address Policy WG chairs will conclude whether or not there is consensus on the draft document. Kind regards, Filiz Yilmaz Policy Development Manager RIPE NCC From shane at time-travellers.org Thu Jan 28 18:29:45 2010 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 28 Jan 2010 09:29:45 -0800 Subject: [address-policy-wg] 32-bit AS Number status? Message-ID: <4B61C989.8010604@time-travellers.org> All, I noticed that the proposed updated AS Number policy was sent to the address-policy-wg recently. There is a timeline for 32-bit AS Number in both the old and new versions, which says: "From 1 January 2010 the RIPE NCC will cease to make any distinction between 16-bit AS Numbers and 32-bit only AS Numbers, and will operate AS Number assignments from an undifferentiated 32-bit AS Number allocation pool." I'm not sure exactly what this means, but I think it is supposed to mean that people get 32-bit AS Numbers now. Did this happen? If it didn't, why not? Do we need to change "2010" to "2011"? Is it ever going to happen? If it did, was there any effect? I mean both from humans (angry LIRs, peasants marching on the castle with torches, riots in the streets), or on the Intertubes (ugly routing artifacts, mass reboots of boxes with old firmware, monitoring systems gone wild)? Just wondering. :) -- Shane From rhe at nosc.ja.net Thu Jan 28 18:56:17 2010 From: rhe at nosc.ja.net (Rob Evans) Date: Thu, 28 Jan 2010 17:56:17 +0000 Subject: [address-policy-wg] Re: [ncc-services-wg] 32-bit AS Number status? In-Reply-To: <4B61C989.8010604@time-travellers.org> References: <4B61C989.8010604@time-travellers.org> Message-ID: <4B61CFC1.2080905@nosc.ja.net> Shane, > I noticed that the proposed updated AS Number policy was sent to the > address-policy-wg recently. Note that this change is only supposed to clean up language, not change the meaning of any part of the policy. > I'm not sure exactly what this means, but I think it is supposed to mean > that people get 32-bit AS Numbers now. Did this happen? As I understood the policy, it means we think of the ASN space as a single pool of 32 bit numbers, but continue to assign numbers under 65000 (at the discretion of the RIRs?) until we run out. The original policy proposal meant all assignments would be >=65536 as of the start of this year, but that changed to this modified sense during the policy's discussion. Others may understand it differently to I. :) Cheers, Rob -- Rob Evans JANET(UK) Development Team Twitter: https://twitter.com/JANETDev/team Work tweets: https://twitter.com/internetplumber JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From scottleibrand at gmail.com Thu Jan 28 19:50:17 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 28 Jan 2010 10:50:17 -0800 Subject: [address-policy-wg] Re: [ncc-services-wg] 32-bit AS Number status? In-Reply-To: <4B61CFC1.2080905@nosc.ja.net> References: <4B61C989.8010604@time-travellers.org> <4B61CFC1.2080905@nosc.ja.net> Message-ID: <4B61DC69.8040502@gmail.com> On 1/28/2010 9:56 AM, Rob Evans wrote: > >> I'm not sure exactly what this means, but I think it is supposed to mean >> that people get 32-bit AS Numbers now. Did this happen? >> > As I understood the policy, it means we think of the ASN space as a > single pool of 32 bit numbers, but continue to assign numbers under > 65000 (at the discretion of the RIRs?) until we run out. > FWIW, that is indeed what ARIN is doing. -Scott From filiz at ripe.net Fri Jan 29 10:44:07 2010 From: filiz at ripe.net (Filiz Yilmaz) Date: Fri, 29 Jan 2010 10:44:07 +0100 Subject: [address-policy-wg] 32-bit AS Number status? In-Reply-To: <4B61C989.8010604@time-travellers.org> References: <4B61C989.8010604@time-travellers.org> Message-ID: <0E878365-0E54-4F6B-9038-14ABDDC25EEC@ripe.net> Dear Shane, During RIPE 58, Daniel Karrenberg has made a presentation, titled "32- bit ASN Take-Up Report, Policy Adjustments Needed?". You can find the presentation at the archives at http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf Slide 5 of the presentation relates to your question. The RIPE NCC proposed that the method of assigning ASNs that was employed in 2009 should continue after 1 January 2010. This means that all assignments will be for 32-bit only ASNs by default, unless a 16-bit ASN is specifically requested. The AP WG agreed with this proposal. You can find the records of this at: http://www.ripe.net/ripe/meetings/ripe-58/meeting-report.php and http://www.ripe.net/ripe/wg/address-policy/r58-minutes.html I hope this helps. Kind regards, Filiz Yilmaz Policy Development Manager RIPE NCC On 28 Jan 2010, at 18:29, Shane Kerr wrote: > All, > > I noticed that the proposed updated AS Number policy was sent to the > address-policy-wg recently. > > There is a timeline for 32-bit AS Number in both the old and new > versions, which says: > > "From 1 January 2010 the RIPE NCC will cease to make any distinction > between 16-bit AS Numbers and 32-bit only AS Numbers, and will operate > AS Number assignments from an undifferentiated 32-bit AS Number > allocation pool." > > I'm not sure exactly what this means, but I think it is supposed to > mean > that people get 32-bit AS Numbers now. Did this happen? > > If it didn't, why not? Do we need to change "2010" to "2011"? Is it > ever > going to happen? > > If it did, was there any effect? I mean both from humans (angry LIRs, > peasants marching on the castle with torches, riots in the streets), > or > on the Intertubes (ugly routing artifacts, mass reboots of boxes with > old firmware, monitoring systems gone wild)? > > Just wondering. :) > > -- > Shane > From hank at efes.iucc.ac.il Sat Jan 30 21:21:54 2010 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 30 Jan 2010 22:21:54 +0200 (IST) Subject: [routing-wg]Re: [address-policy-wg] 32-bit AS Number status? In-Reply-To: <0E878365-0E54-4F6B-9038-14ABDDC25EEC@ripe.net> References: <4B61C989.8010604@time-travellers.org> <0E878365-0E54-4F6B-9038-14ABDDC25EEC@ripe.net> Message-ID: On Fri, 29 Jan 2010, Filiz Yilmaz wrote: > Dear Shane, > > During RIPE 58, Daniel Karrenberg has made a presentation, titled "32-bit ASN > Take-Up Report, Policy Adjustments Needed?". > You can find the presentation at the archives at > http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf > > Slide 5 of the presentation relates to your question. The RIPE NCC proposed > that the method of assigning ASNs that was employed in 2009 should continue > after 1 January 2010. This means that all assignments will be for 32-bit only > ASNs by default, unless a 16-bit ASN is specifically requested. The AP WG > agreed with this proposal. Does the RIPE NCC consider a slide in a presentation as proper documentation for revised ASN assignment procedures? -Hank > > You can find the records of this at: > > http://www.ripe.net/ripe/meetings/ripe-58/meeting-report.php > and > http://www.ripe.net/ripe/wg/address-policy/r58-minutes.html > > I hope this helps. > > Kind regards, > > Filiz Yilmaz > Policy Development Manager > RIPE NCC > > > On 28 Jan 2010, at 18:29, Shane Kerr wrote: > >> All, >> >> I noticed that the proposed updated AS Number policy was sent to the >> address-policy-wg recently. >> >> There is a timeline for 32-bit AS Number in both the old and new >> versions, which says: >> >> "From 1 January 2010 the RIPE NCC will cease to make any distinction >> between 16-bit AS Numbers and 32-bit only AS Numbers, and will operate >> AS Number assignments from an undifferentiated 32-bit AS Number >> allocation pool." >> >> I'm not sure exactly what this means, but I think it is supposed to mean >> that people get 32-bit AS Numbers now. Did this happen? >> >> If it didn't, why not? Do we need to change "2010" to "2011"? Is it ever >> going to happen? >> >> If it did, was there any effect? I mean both from humans (angry LIRs, >> peasants marching on the castle with torches, riots in the streets), or >> on the Intertubes (ugly routing artifacts, mass reboots of boxes with >> old firmware, monitoring systems gone wild)? >> >> Just wondering. :) >> >> -- >> Shane >> >