From jay at impulse.net Mon Mar 1 05:36:08 2010 From: jay at impulse.net (Jay Hennigan) Date: Mon, 01 Mar 2010 02:36:08 -0800 Subject: [arin-ppml] reformed pastafarians Message-ID: <4B8B9898.5070901@impulse.net> Those of you who have been following Pastafarianism on the web for many years will probably recognize The Venganza Org publication. This was likely the first attempt to make a web portal for FSM people, and this pioneering effort helped to inspire many other sites to do likewise. Venganza set itself apart as a place where devout and sincere FSM and Pastafarians could intelligently discuss controversial doctrines in a positive light, at a time when the anti-FSM forces were very powerful on the web. The publication has been active off and on ever since that time. If you are not familiar with it, you might want to have a look at it. This site broke new ground at the time that it was started. http://www.venganza.org/ For those who are already familiar with The Venganza Org, you might be interested to know that the editors and contributors have recently started work on some historical information regarding the publication, which provides many links to related websites. You can have an advance look, and see as it evolves. http://reformed-pastafarianism.org/ Some of you may even like to contribute something; help us fix broken links, contribute a news item, editorial, or personal story. If you were a part of the activity that spawned The Reformed Pastafarian, you might like to submit your link for inclusion on our contributors page. Ramen, linguine From spiffnolee at yahoo.com Mon Mar 1 11:48:24 2010 From: spiffnolee at yahoo.com (Lee Howard) Date: Mon, 1 Mar 2010 08:48:24 -0800 (PST) Subject: [arin-ppml] which RIR, ARIN or LACNIC? In-Reply-To: <292AF25E62B8894C921B893B53A19D973974B77CBE@BUSINESSEX.business.ad> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net> <292AF25E62B8894C921B893B53A19D973974B77CBC@BUSINESSEX.business.ad> <58E881F4-EE3C-4556-98BE-05CA63C9F982@gmail.com> <292AF25E62B8894C921B893B53A19D973974B77CBE@BUSINESSEX.business.ad> Message-ID: <242203.62868.qm@web63303.mail.re1.yahoo.com> The ARIN service region is delineated: https://www.arin.net/knowledge/rirs/ARINcountries.html The full list is at https://www.arin.net/knowledge/rirs/countries.html Lee ________________________________ From: Skeeve Stevens To: Scott Leibrand Cc: "arin-ppml at arin.net" Sent: Fri, February 26, 2010 8:45:43 PM Subject: Re: [arin-ppml] RIPE/ITU That is a little confusing.... So counties in that region can choose which RIR they want to deal with? -- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there? > -----Original Message----- > From: Scott Leibrand [mailto:scottleibrand at gmail.com] > Sent: Saturday, 27 February 2010 12:41 PM > To: Skeeve Stevens > Cc: michael.dillon at bt.com; arin-ppml at arin.net > Subject: Re: [arin-ppml] RIPE/ITU > > Keep in mind that the English-speaking Caribbean is served by ARIN > rather than LACNIC. > > Scott > > On Feb 26, 2010, at 5:37 PM, Skeeve Stevens > wrote: > > > Re the Caribbean, is it being suggested that LACNIC is not doing its > > job for that region? > > > > ...Skeeve > > > > -- > > Skeeve Stevens, CEO/Technical Director > > eintellego Pty Ltd - The Networking Specialists > > skeeve at eintellego.net/ www.eintellego.net > > Phone: 1300 753 383, Fax: (+612) 8572 9954 > > Cell +61 (0)414 753 383 / skype://skeeve > > www.linkedin.com/in/skeeve ; facebook.com/eintellego > > -- > > NOC, NOC, who's there? > > > > > >> -----Original Message----- > >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml- > >> bounces at arin.net] On > >> Behalf Of michael.dillon at bt.com > >> Sent: Saturday, 27 February 2010 4:10 AM > >> To: arin-ppml at arin.net > >> Subject: Re: [arin-ppml] RIPE/ITU > >> > >> > >>> Although I am indeed thankful to the ITU for keeping us poor > >>> and under privileged developing countries well stocked in > >>> IPv6 numbers, I would much prefer that ARIN consider > >>> structural modifications to allow for sub regional registries > >>> under present structure > >> > >> You might want to look into APNIC's NIR model which is exactly > >> that, and then make a formal proposal. I wouldn't expect you > >> to simply copy APNIC, but in making a proposal, I think you > >> should understand the alternatives. Also, I believe RIPE has > >> done something similar for the Russia and the ex-USSR countries, > >> partly because of the economic gap and partly because of legal > >> restrictions on signing contracts with foreign organizations. > >> > >> This is a good idea, and as a side effect, if you get all > >> the Caribbean networking people talking around the same > >> table on a regular basis, you will be able to react faster > >> and in a more coordinated fashion when disaster strikes. > >> Like the next hurricane, and the one after that... > >> > >> I don't see any connection between what you are suggesting > >> and the ITU's activities, and it is probably best if ARIN > >> considers your sub-registry proposal on its own merits. > >> > >> --Michael Dillon > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dogwallah at gmail.com Mon Mar 1 22:00:18 2010 From: dogwallah at gmail.com (McTim) Date: Tue, 2 Mar 2010 06:00:18 +0300 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> Message-ID: All, On Sun, Feb 28, 2010 at 1:40 AM, Milton L Mueller wrote: > John, > > If what you have said in this thread is an indication of your strategy and tactics for the Geneva meeting, I'd respectfully suggest a trip back to the drawing board. Your plan, apparently, is to tell the ITU and its member states to come to _your_ meetings, to your home field, to participate in _your_ game. Good luck with that. Looks to me as if you're going to one of their meetings..... Just to remind anyone interested, the APNIC Community Consultation on this issue is happening today (in about 3 hours from now) http://meetings.apnic.net/29/program/consultation Remote participation: http://meetings.apnic.net/29/remote It seems there will be ITU representation there. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From farmer at umn.edu Mon Mar 1 22:17:35 2010 From: farmer at umn.edu (David Farmer) Date: Mon, 01 Mar 2010 21:17:35 -0600 Subject: [arin-ppml] RIPE/ITU In-Reply-To: References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4B8C834F.6000106@umn.edu> Isn't it tomorrow, it is Tuesday about 11:15 in Kuala Lumpur right now. The presentation is suppose to be Wednesday at 14:00 local time. And the International Fiber presentation is on right now. McTim wrote: > All, > > On Sun, Feb 28, 2010 at 1:40 AM, Milton L Mueller wrote: >> John, > >> If what you have said in this thread is an indication of your strategy and tactics for the Geneva meeting, I'd respectfully suggest a trip back to the drawing board. Your plan, apparently, is to tell the ITU and its member states to come to _your_ meetings, to your home field, to participate in _your_ game. Good luck with that. Looks to me as if you're going to one of their meetings..... > > Just to remind anyone interested, the APNIC Community Consultation on > this issue is happening today (in about 3 hours from now) > > http://meetings.apnic.net/29/program/consultation > > Remote participation: > http://meetings.apnic.net/29/remote > > It seems there will be ITU representation there. > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From scottleibrand at gmail.com Mon Mar 1 22:18:04 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 01 Mar 2010 19:18:04 -0800 Subject: [arin-ppml] RIPE/ITU In-Reply-To: References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4B8C836C.9000607@gmail.com> On Mon 3/1/2010 7:00 PM, McTim wrote: > > All, > > Just to remind anyone interested, the APNIC Community Consultation on > this issue is happening today (in about 3 hours from now) > > http://meetings.apnic.net/29/program/consultation > > Remote participation: > http://meetings.apnic.net/29/remote > > It seems there will be ITU representation there. > Is that today? At http://meetings.apnic.net/29/remote I see: Wed 3 Mar 14:00^*** APNIC Community Consultation - IPv6 & ITU And it looks like it's Tue Mar 2 11:18 right now in KL... -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From dogwallah at gmail.com Mon Mar 1 22:23:41 2010 From: dogwallah at gmail.com (McTim) Date: Tue, 2 Mar 2010 06:23:41 +0300 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <4B8C834F.6000106@umn.edu> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <4B8C834F.6000106@umn.edu> Message-ID: HI David, Yes, apologies, I had it in my calendar for the 2nd...it is indeed on Wednesday. Terema kasih banyak. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel On Tue, Mar 2, 2010 at 6:17 AM, David Farmer wrote: > Isn't it tomorrow, it is Tuesday about 11:15 in Kuala Lumpur right now. ?The > presentation is suppose to be Wednesday at 14:00 local time. > > And the International Fiber presentation is on right now. > > McTim wrote: >> >> All, >> >> On Sun, Feb 28, 2010 at 1:40 AM, Milton L Mueller wrote: >>> >>> John, >> >> >>> >>> If what you have said in this thread is an indication of your strategy >>> and tactics for the Geneva meeting, I'd respectfully suggest a trip back to >>> the drawing board. Your plan, apparently, is to tell the ITU and its member >>> states to come to _your_ meetings, to your home field, to participate in >>> _your_ game. Good luck with that. Looks to me as if you're going to one of >>> their meetings..... >> >> Just to remind anyone interested, the APNIC Community Consultation on >> this issue is happening today (in about 3 hours from now) >> >> http://meetings.apnic.net/29/program/consultation >> >> Remote participation: >> http://meetings.apnic.net/29/remote >> >> It seems there will be ITU representation there. >> > > > -- > =============================================== > David Farmer ? ? ? ? ? ? ? Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE ? ? ?Phone: 612-626-0815 > Minneapolis, MN 55414-3029 ? Cell: 612-812-9952 > =============================================== > From tedm at ipinc.net Tue Mar 2 01:12:56 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 01 Mar 2010 22:12:56 -0800 Subject: [arin-ppml] radical mormons In-Reply-To: <20100301041548.C1FBED5C0D5@gnu-darwin.org> References: <20100301041548.C1FBED5C0D5@gnu-darwin.org> Message-ID: <4B8CAC68.4050708@ipinc.net> proclus at gnu-darwin.org wrote: > Those of you who have been following mormonism on the web > for many years will probably recognize The Radical Mormon > publication. Guys, it's not April 1st, yet!! Ted From owen at delong.com Tue Mar 2 21:26:42 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 3 Mar 2010 10:26:42 +0800 Subject: [arin-ppml] Updated 2010-2 (v1.3) -- minor language clarification Message-ID: <19E478EF-EB9F-4ADF-BC44-D838019E0ADC@delong.com> There is a minor change to 4.3.6.2 which clarifies that the returns required would only be the smaller blocks and not blocks with prefix lengths <= /22. I believe this change merely clarifies the original intent of the policy and does not change that intent or the policy in a significant way. Thanks to Bill Herrin for pointing out the hole in the original language. Owen TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 1. Policy Proposal Name: /24 End User Minimum Assignment Unit 2. Proposal Originator a. name: Owen DeLong b. email: owen at delong.com c. telephone: 408-890-7992 d. organization: Hurricane Electric 3. Proposal Version: 1.3 4. Date: 12 January, 2010 5. Proposal type: new 6. Policy term: permanent 7. Policy statement: Replace section 4.3.2.2 of the NRPM with the following: 4.3.2.2 Multihomed Connection For multi-homed end-users who demonstrate an intent to announce the requested space in a multihomed fashion to two or more distinct ASNs not owned or controlled by the end-user, the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose so long as that is feasible. Renumber the existing paragraph under the 4.3.6 to 4.3.6.1 Utilization requirements for additional Assignment Add the following paragraph 4.3.6.2 4.3.6.2 Additional assignments for small multi-homers Any end-user that possesses an assignment smaller than /22 under any part of section 4.3 shall not be able to get an additional assignment unless they agree to return all existing 4.3 assignments with a /23 or longer prefix within 12 months of receiving a new assignment. The new assignment shall be sized to accommodate their existing utilization in addition to their justified additional growth space under section 4.3.6.1. The common cases for this are expected to be a /24 returned after receipt of a /23, or a /23 returned after receipt of a /22. 8. Rationale: This policy attempts to incorporate the recent and historical discussions of policy for multi-home users on PPML. The intent is to provide as fair a process as possible for multi-homed organizations down to the smallest feasible size while still preserving some control over growth in the routing table. It has been repeatedly noted that /24 multi-homers exist today with PA space and still occupy a routing table slot, so, it is unlikely that moving this boundary to /24 would significantly impact the routing table. By requiring smaller assignments to renumber and return, rather than add more small blocks to their assignments, this policy seeks to further reduce the chances of unnecessary growth in the routing table and encourage good aggregation where possible. Does this apply only to end users? Yes, this policy applies only to end users. This policy does not represent a good solution for organizations that are delegating space to other entities. If a case can be made that such a policy is needed for ISPs, then, the author is happy to work with interested parties to craft such a policy, but, this policy would be unnecessarily onerous on ISPs, and, as an ISP policy could be somewhat onerous to their peers and/or upstream providers. What about resources obtained from policies other than 4.3 or outside of ARIN? Such resources would not be counted for excluding an organization from this policy. The intent is to limit IPv4 micro-allocations for multi-homed end-user organizations under this policy to a single assignment unless each such assignment is /22 or larger. This is to prevent unnecessary routing table growth. This is a tradeoff, and, not the ideal solution for smaller end-user organizations, however, author believes that this is the best policy likely to gain consensus at this time and believes that it is incrementally far better for such organizations than current policy. If I grow, I have to renumber? Not necessarily... If you have a /24 under this policy, and you want to grow that, then, you will likely need to renumber. Depending on ARIN resource management and timing, ARIN may simply be able to give you the /23 that includes your /24. More likely, you will get a new /23, have 1 year to renumber into that and return your /24. At most, you would be subject to two such renumbering cycles under this policy (24->23 and 23->22) before you meet the criteria for other policies which do not require renumbering. Other policies don't include renumbering provisions, why this one? The policy which allows multi-homed organizations to get a /22 was originally written at /24. That policy was shouted down and /22 was the compromise achieved to gain community consensus for anything smaller than /20. Author hopes that this compromise will allow many organizations to get resources they need with minimal impact while assuring the community that doing so will not cause an explosion in the routing table. 9. Timetable for implementation: Immediate END OF TEMPLATE -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at ibctech.ca Tue Mar 2 22:44:06 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 02 Mar 2010 22:44:06 -0500 Subject: [arin-ppml] Updated 2010-2 (v1.3) -- minor language clarification In-Reply-To: <19E478EF-EB9F-4ADF-BC44-D838019E0ADC@delong.com> References: <19E478EF-EB9F-4ADF-BC44-D838019E0ADC@delong.com> Message-ID: <4B8DDB06.7030908@ibctech.ca> On 2010.03.02 21:26, Owen DeLong wrote: > There is a minor change to 4.3.6.2 which clarifies that the returns > required would only be the smaller blocks and not blocks with prefix > lengths <= /22. > I believe this change merely clarifies the original intent of the policy > and does not change that intent or the policy in a significant way. I support this `administrative' change. Steve From ocl at gih.com Wed Mar 3 05:27:52 2010 From: ocl at gih.com (Olivier MJ Crepin-Leblond) Date: Wed, 03 Mar 2010 14:27:52 +0400 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org>, <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu>, <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4B8E39A8.6090900@gih.com> Milton: Le 01/03/2010 08:46, Milton L Mueller a ?crit : > > As I've said, it's all about the policies. If the ITU or anyone else wants to discuss and promote more reasonable policies I'm all for it. ITU can serve as a useful countervailing force to the RIR monopoly, just as it has with ICANN. > > > Your use of the word "monopoly" gives me a twitch every time I hear it. :-) You, as well as Dr. Suresh Ramadass imply a commercial monopoly - by saying that another source of IP addresses would benefit the consumer. I've said it during the IPv6 session at IGF Sharm el Sheikh and I'll say it again: the current RIR structure is not a commercial monopoly, because the resource it dispenses is a *managed* resource. It is managed for one main reason: to ensure one single Internet, an Internet that is as stable as can be, and as manageable as can be. It has worked very well so far, and I think you'll find a lot of people who'll agree with the view that keeping the Internet as stable as possible, is a good thing. I cannot see a valid reason why one would try to change a system that's working in its core mission: stability. If it ain't broke, don't fix it. Now if you're speaking about institutional monopoly, then yes, an institutional monopoly is in place, specifically for the reason I have explained above. That's what managed resources as all about. I would compare this with a country's court system, a country's military, or even with the United Nations - after all, they all serve a purpose as an institutional monopoly, don't they? With a managed commodity, too many cooks spoil the broth. Warmest regards, Olivier -- Olivier MJ Cr?pin-Leblond, PhD http://www.gih.com/ocl.html From BillD at cait.wustl.edu Wed Mar 3 07:50:57 2010 From: BillD at cait.wustl.edu (Bill Darte) Date: Wed, 3 Mar 2010 06:50:57 -0600 Subject: [arin-ppml] RIPE/ITU References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org>, <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu>, <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> Message-ID: +1 -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Olivier MJ Crepin-Leblond Sent: Wed 3/3/2010 4:27 AM To: Milton L Mueller Cc: John Curran; arin-ppml at arin.net Subject: Re: [arin-ppml] RIPE/ITU Milton: Le 01/03/2010 08:46, Milton L Mueller a ?crit : > > As I've said, it's all about the policies. If the ITU or anyone else wants to discuss and promote more reasonable policies I'm all for it. ITU can serve as a useful countervailing force to the RIR monopoly, just as it has with ICANN. > > > Your use of the word "monopoly" gives me a twitch every time I hear it. :-) You, as well as Dr. Suresh Ramadass imply a commercial monopoly - by saying that another source of IP addresses would benefit the consumer. I've said it during the IPv6 session at IGF Sharm el Sheikh and I'll say it again: the current RIR structure is not a commercial monopoly, because the resource it dispenses is a *managed* resource. It is managed for one main reason: to ensure one single Internet, an Internet that is as stable as can be, and as manageable as can be. It has worked very well so far, and I think you'll find a lot of people who'll agree with the view that keeping the Internet as stable as possible, is a good thing. I cannot see a valid reason why one would try to change a system that's working in its core mission: stability. If it ain't broke, don't fix it. Now if you're speaking about institutional monopoly, then yes, an institutional monopoly is in place, specifically for the reason I have explained above. That's what managed resources as all about. I would compare this with a country's court system, a country's military, or even with the United Nations - after all, they all serve a purpose as an institutional monopoly, don't they? With a managed commodity, too many cooks spoil the broth. Warmest regards, Olivier -- Olivier MJ Cr?pin-Leblond, PhD http://www.gih.com/ocl.html _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.daniel at gmail.com Wed Mar 3 08:13:40 2010 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Wed, 3 Mar 2010 09:13:40 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 57, Issue 3 In-Reply-To: References: Message-ID: <8aeeaff61003030513p4c63e9d9gcba25c1d87f1f8c5@mail.gmail.com> I am extremely happy to have a community resource managed by the community as institution and monopoly Milton. I really do not know what is meant by more reasonable policies, and !! a countervailing force??? !! My original post was misunderstood by someone on this list who has since been advised that it was a disguised appeal for assistance in supporting countervailing force in my (small) region where we may not have the strength and resources to resist the might of a huge commercial monopolist waiting to gobble us up by any means possible....and just to push the point home to you, I was not referring to an RIR. RD Milton: > > Le 01/03/2010 08:46, Milton L Mueller a ?crit : > > > > As I've said, it's all about the policies. If the ITU or anyone else > wants to discuss and promote more reasonable policies I'm all for it. ITU > can serve as a useful countervailing force to the RIR monopoly, just as it > has with ICANN. > > > > > > > > Your use of the word "monopoly" gives me a twitch every time I hear it. :-) > You, as well as Dr. Suresh Ramadass imply a commercial monopoly - by > saying that another source of IP addresses would benefit the consumer. > I've said it during the IPv6 session at IGF Sharm el Sheikh and I'll say > it again: the current RIR structure is not a commercial monopoly, > because the resource it dispenses is a *managed* resource. > It is managed for one main reason: to ensure one single Internet, an > Internet that is as stable as can be, and as manageable as can be. It > has worked very well so far, and I think you'll find a lot of people > who'll agree with the view that keeping the Internet as stable as > possible, is a good thing. I cannot see a valid reason why one would try > to change a system that's working in its core mission: stability. If it > ain't broke, don't fix it. > > Now if you're speaking about institutional monopoly, then yes, an > institutional monopoly is in place, specifically for the reason I have > explained above. That's what managed resources as all about. I would > compare this with a country's court system, a country's military, or > even with the United Nations - after all, they all serve a purpose as an > institutional monopoly, don't they? > > With a managed commodity, too many cooks spoil the broth. > > Warmest regards, > > Olivier > > -- > Olivier MJ Cr?pin-Leblond, PhD > http://www.gih.com/ocl.html > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20100303/a3100646/attachment.html > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 57, Issue 3 > **************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Mar 3 09:42:26 2010 From: bill at herrin.us (William Herrin) Date: Wed, 3 Mar 2010 09:42:26 -0500 Subject: [arin-ppml] Updated 2010-2 (v1.3) -- minor language clarification In-Reply-To: <19E478EF-EB9F-4ADF-BC44-D838019E0ADC@delong.com> References: <19E478EF-EB9F-4ADF-BC44-D838019E0ADC@delong.com> Message-ID: <3c3e3fca1003030642n3eace648wc5b5f9de13b1bfd2@mail.gmail.com> On Tue, Mar 2, 2010 at 9:26 PM, Owen DeLong wrote: > There is a minor change to 4.3.6.2 which clarifies that the returns required > would only be the smaller blocks and not blocks with prefix lengths <= /22. > 1. Policy Proposal Name: /24 End User Minimum Assignment Unit Thanks Owen. I SUPPORT both the tweak and the proposal as a whole. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Wed Mar 3 10:06:42 2010 From: bill at herrin.us (William Herrin) Date: Wed, 3 Mar 2010 10:06:42 -0500 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <4B8E39A8.6090900@gih.com> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> Message-ID: <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> > Le 01/03/2010 08:46, Milton L Mueller a ?crit : >> As I've said, it's all about the policies. If the ITU or >anyone else wants to discuss and promote more >reasonable policies I'm all for it. ITU can serve as >a useful countervailing force to the RIR monopoly, >just as it has with ICANN. Hi Milton, I don't see how it helps to have entities compete at the process of giving away a combination of a free-pool resource (IPv6 addresses) and other peoples' money (the routing slots they use). If ITU wants in the IR game that badly, I'd like to see them take on something that the RIRs aren't already dealing with. Perhaps they could draft an RFC and global policy requesting that IANA delegate fc00::/8 to ITU. Whether they ever see an expanded role in IP address management would, of course, then depend on how open and cost-effective a job they do with that off-Internet pool. ITU seems to have talked themselves down from wanting to control ICANN to wanting to control IANA to wanting to be a competitive IR under IANA. They have a little ways to go yet before they come close to talking sense. I could be mistaken, but it seems to me there's essentially no chance of the ARIN community supporting a global proposal to make ITU a competitive IR for public Internet addresses. I would also be surprised if the other regions welcome ITU treading on their turf. Pushing the issue seems to me like an awful lot of effort for ITU to go to just to make a political statement that's as likely as not to backfire and remind everybody why upon the end of NSF funding for the InterNIC a decade and change ago, ITU was not invited to step up. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From frnkblk at iname.com Wed Mar 3 10:51:40 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Wed, 3 Mar 2010 09:51:40 -0600 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> Message-ID: This part of the discussion touches on some of the fundamental questions I have about ITU-T's interest in IP address allocation: (a) what does the ITU-T see as the problem with the current system? (b) who are the concerns persons/groups that are telling the ITU-T that there is a problem, and why aren't their letters/concerns shared on the ITU-T's website? (c) have those persons/groups raised the concerns with the applicable RIR(s)? (d) if it's a matter of underrepresentation (i.e. under-developed countries aren't asking for resources because they're not able to or don't currently need do), why doesn't the ITU-T recommend an appropriate policy to each of the RIRs or write an IETF draft that addresses the issue(s)? (e) why doesn't the ITU-T visit and work with the existing address allocation bodies, namely the RIR(s), rather than work outside the current process? Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Wednesday, March 03, 2010 9:07 AM To: Milton L Mueller; John Curran; arin-ppml at arin.net Subject: Re: [arin-ppml] RIPE/ITU > Le 01/03/2010 08:46, Milton L Mueller a ?crit : >> As I've said, it's all about the policies. If the ITU or >anyone else wants to discuss and promote more >reasonable policies I'm all for it. ITU can serve as >a useful countervailing force to the RIR monopoly, >just as it has with ICANN. Hi Milton, I don't see how it helps to have entities compete at the process of giving away a combination of a free-pool resource (IPv6 addresses) and other peoples' money (the routing slots they use). If ITU wants in the IR game that badly, I'd like to see them take on something that the RIRs aren't already dealing with. Perhaps they could draft an RFC and global policy requesting that IANA delegate fc00::/8 to ITU. Whether they ever see an expanded role in IP address management would, of course, then depend on how open and cost-effective a job they do with that off-Internet pool. ITU seems to have talked themselves down from wanting to control ICANN to wanting to control IANA to wanting to be a competitive IR under IANA. They have a little ways to go yet before they come close to talking sense. I could be mistaken, but it seems to me there's essentially no chance of the ARIN community supporting a global proposal to make ITU a competitive IR for public Internet addresses. I would also be surprised if the other regions welcome ITU treading on their turf. Pushing the issue seems to me like an awful lot of effort for ITU to go to just to make a political statement that's as likely as not to backfire and remind everybody why upon the end of NSF funding for the InterNIC a decade and change ago, ITU was not invited to step up. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From jcurran at arin.net Wed Mar 3 14:46:09 2010 From: jcurran at arin.net (John Curran) Date: Wed, 3 Mar 2010 14:46:09 -0500 Subject: [arin-ppml] Fwd: [arin-announce] APNIC Community Consultation "IPv6 Address Management and ITU" session completed References: <327AA565-971F-43D1-82D2-976A3D4F4186@arin.net> Message-ID: PPML participants - For your information and consideration. Apologies for the cross-post, but this matter has the potential for changes to the policy process itself. Thank you! /John === Begin forwarded message: From: John Curran > Date: March 4, 2010 3:41:35 AM GMT+08:00 To: "arin-announce at arin.net" > Subject: [arin-announce] APNIC Community Consultation "IPv6 Address Management and ITU" session completed ARIN Community - The previously mentioned APNIC community consultation regarding "IPv6 Address Management and ITU" was completed earlier today in Kuala Lumpur, Malaysia. For those interested in the outcome, a "raw" transcript and session summary statement are available here: I'd like to thank APNIC for hosting this session as it is important to discuss these issues publicly in timely manner so that input can be brought to the the March 15-16 ITU IPv6 study group meeting in Geneva. By having a public discussion of these important issues, APNIC (as an ITU-D sector member) can submit the outcome for further consideration in this process. While the ITU IPv6 study group is a closed meeting, I have received an invitation to participate on March 15-16 in Geneva on ARIN's behalf as an "invited expert", and at that session I will focus on the comments covered in the public consultation held today. If you have additional input on this topic that you would like to have considered, please do the following: 1) If your company has a public policy representative involved in the ITU (generally due to being a supporting member of the ITU), please introduce me to them asap so that we may coordinate as appropriate. 2) Become familiar with the outcomes of the APNIC session, and send any additional comments to "IPv6 at apnic.net" and myself. The APNIC community consultation process continues till Friday 5 March, 9 AM local meeting time [UTC + 8:00]. I will continue to take comments beyond that point till ITU IPv6 meeting start and do my best to convey the input received. As you can tell, we're attempting to be as accommodating as possible to the ITU as they explore the issues in this area, and their processes are significantly different than ours regarding how input is received and considered. At this point, ARIN considers it very important to support these educational efforts, and hope that it will result in better overall understanding of the success that is today's Internet Registry System. I hope this email helps the community understand where we are in this interesting process. Thank you for your support! /John John Curran President and CEO American Registry for Internet Numbers === From: Member Services > Date: Wed, Feb 24, 2010 at 8:53 AM Subject: [arin-announce] Be Heard! APNIC Community Consultation Next Week To: arin-announce at arin.net Internet address management may be on the brink of change. The ITU (International Telecommunications Union) is studying the creation of an alternative International Internet Registry model to operate in parallel to the existing RIR model. In collaboration with the NRO, APNIC is hosting a special session at APNIC 29 / APRICOT 2010 to give the global Internet community an opportunity to discuss the issues and ramifications of the alternative model proposed by the ITU. APNIC invites all Members of the global Internet Community to participate at: IPv6 Address Management and ITU - Is an "additional parallel structure" required? Where: APNIC 29, Kuala Lumpur, Malaysia When: 14:00 - 15:30 (UTC +8), Wednesday, 3 March 2010 APNIC is an ITU-D sector Member and will attend the ITU IPv6 Working Group meeting in March that has been commissioned to study this issue in depth. APNIC will be reporting feedback from our Consultation to ensure community feedback is heard. ... = _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Mar 3 17:40:55 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 4 Mar 2010 06:40:55 +0800 Subject: [arin-ppml] RIPE/ITU In-Reply-To: References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> Message-ID: According to the ITU presentation by Xiaoya yesterday: a) IPv4 early adopter advantage/late adopter disadvantage should not be repeated in IPv6. b) "Developing Nations" - The ITU did not specify which ones. c) Was not covered by the ITU presentation. d) From the presentation, it sounded like the ITU may submit their desire to become an additional registry through the global policy process if that's what they decide to do. The ITU was clear that nothing has yet been decided, they are "considering" this matter. The ITU representative did express surprise and dismay at the level of "overreaction" from the community at the APNIC meeting. e) To at least some extent, they did so yesterday. I think the meeting yesterday was a very good beginning and that it was a useful and productive discussion. I still think that the idea of the ITU possible CIR model as currently described would be extremely destructive to the good of the internet and likely harmful to the very countries that the ITU is claiming they are attempting to benefit. However, I will say that the ITU does seem to be making an attempt to reach out and open a dialog. There's a _LOT_ of cultural difference between the ITU organization and the RIR communities. The ITU has extremely structured membership and is very much oriented to being a forum for governments, although industry "sector" members are permitted for $20,000/year. ITU meetings are strictly limited to members. While I believe that the RIR system is vastly better at representing the interests of all stakeholders, I also accept that it is a very unfamiliar and difficult concept for someone with a strong regulatory background to grasp. I think that the discussion yesterday was a good beginning to bridging that gap. I hope that the ITU will continue to make efforts to keep an open dialogue with the RIR communities. I think that one potentially ideal outcome of this process would be for the ITU to merely recognize the current RIR structure as the proper forum for internet number resource policies and refer their interested members to that forum. I have no idea how amenable the ITU might be to such an idea. I think the best hope of a good outcome will be the result of continued dialogue. Owen On Mar 3, 2010, at 11:51 PM, Frank Bulk - iName.com wrote: > This part of the discussion touches on some of the fundamental questions I > have about ITU-T's interest in IP address allocation: > (a) what does the ITU-T see as the problem with the current system? > (b) who are the concerns persons/groups that are telling the ITU-T that > there is a problem, and why aren't their letters/concerns shared on the > ITU-T's website? > (c) have those persons/groups raised the concerns with the applicable > RIR(s)? > (d) if it's a matter of underrepresentation (i.e. under-developed countries > aren't asking for resources because they're not able to or don't currently > need do), why doesn't the ITU-T recommend an appropriate policy to each of > the RIRs or write an IETF draft that addresses the issue(s)? > (e) why doesn't the ITU-T visit and work with the existing address > allocation bodies, namely the RIR(s), rather than work outside the current > process? > > Frank > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of William Herrin > Sent: Wednesday, March 03, 2010 9:07 AM > To: Milton L Mueller; John Curran; arin-ppml at arin.net > Subject: Re: [arin-ppml] RIPE/ITU > >> Le 01/03/2010 08:46, Milton L Mueller a ?crit : >>> As I've said, it's all about the policies. If the ITU or >> anyone else wants to discuss and promote more >> reasonable policies I'm all for it. ITU can serve as >> a useful countervailing force to the RIR monopoly, >> just as it has with ICANN. > > Hi Milton, > > I don't see how it helps to have entities compete at the process of > giving away a combination of a free-pool resource (IPv6 addresses) and > other peoples' money (the routing slots they use). > > If ITU wants in the IR game that badly, I'd like to see them take on > something that the RIRs aren't already dealing with. Perhaps they > could draft an RFC and global policy requesting that IANA delegate > fc00::/8 to ITU. Whether they ever see an expanded role in IP address > management would, of course, then depend on how open and > cost-effective a job they do with that off-Internet pool. > > > ITU seems to have talked themselves down from wanting to control ICANN > to wanting to control IANA to wanting to be a competitive IR under > IANA. They have a little ways to go yet before they come close to > talking sense. > > I could be mistaken, but it seems to me there's essentially no chance > of the ARIN community supporting a global proposal to make ITU a > competitive IR for public Internet addresses. I would also be > surprised if the other regions welcome ITU treading on their turf. > > Pushing the issue seems to me like an awful lot of effort for ITU to > go to just to make a political statement that's as likely as not to > backfire and remind everybody why upon the end of NSF funding for the > InterNIC a decade and change ago, ITU was not invited to step up. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mueller at syr.edu Wed Mar 3 20:08:09 2010 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 3 Mar 2010 20:08:09 -0500 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <4B8E39A8.6090900@gih.com> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org>, <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu>, <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> Message-ID: <75822E125BCB994F8446858C4B19F0D701C78E5DEE@SUEX07-MBX-04.ad.syr.edu> -----Original Message----- From: Olivier MJ Crepin-Leblond [mailto:ocl at gih.com] >Your use of the word "monopoly" gives me a twitch every time I hear it. :-) Good. >I've said it during the IPv6 session at IGF Sharm el Sheikh and I'll say >it again: the current RIR structure is not a commercial monopoly, >because the resource it dispenses is a *managed* resource. All resources are managed. The issue is how. >It is managed for one main reason: to ensure one single Internet, an >Internet that is as stable as can be, and as manageable as can be. It >has worked very well so far, [blah, blah] why one would try >to change a system that's working in its core mission: stability. If it >ain't broke, don't fix it. Here's what amusing (and unconvincing) about your argument. The real issue in this debate is the role of nation-states in governing internet resources. And what do you compare the RIRs to? >I would >compare this with a country's court system, a country's military, or >even with the United Nations - after all, they all serve a purpose as an >institutional monopoly, don't they? Boy did you walk right into it. You see, my friends, what you have going on here is a large segment of the world's governments asking themselves why a nonprofit, self-formed group of technicians is assuming transnational regulatory and governance powers that, in the past, were held by national governments. That's what this is about. So when you say things like that, you only confirm - and inflame - those perceptions. I am not justifying or supporting those perceptions, I am simply telling you that they exist, and trying to break through the insularity of this community in figuring out how to deal with it. Put another way, if you consider the RIRs to be exclusive governance authorities comparable to a country's legal/judiciary system, why the hell shouldn't governments have a controlling role? I'll be looking forward to your answer to that. --MM From jcurran at arin.net Wed Mar 3 20:18:15 2010 From: jcurran at arin.net (John Curran) Date: Wed, 3 Mar 2010 20:18:15 -0500 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C78E5DEE@SUEX07-MBX-04.ad.syr.edu> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <75822E125BCB994F8446858C4B19F0D701C78E5DEE@SUEX07-MBX-04.ad.syr.edu> Message-ID: <66BD93EE-85D8-4E04-A4D4-F0A8D915BC4D@arin.net> On Mar 4, 2010, at 9:08 AM, Milton L Mueller wrote: > > Boy did you walk right into it. You see, my friends, what you have going on here is a large segment of the world's governments asking themselves why a nonprofit, self-formed group of technicians is assuming transnational regulatory and governance powers that, in the past, were held by national governments. Milton - When I check my coat, the attendant gives me a tag with a number on it. The numbers are generally unique to the establishment, given out freely or as part of a service bundle for a nominal fee, and aren't given out without need for one. Are the coat check operators assuming "transnational regulatory and governance powers", and if not, why do you feel that governments are thinking that of the Internet Registry System? /John From owen at delong.com Wed Mar 3 20:25:26 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 4 Mar 2010 09:25:26 +0800 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C78E5DEE@SUEX07-MBX-04.ad.syr.edu> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org>, <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu>, <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <75822E125BCB994F8446858C4B19F0D701C78E5DEE@SUEX07-MBX-04.ad.syr.edu> Message-ID: > >> I would >> compare this with a country's court system, a country's military, or >> even with the United Nations - after all, they all serve a purpose as an >> institutional monopoly, don't they? > Put another way, if you consider the RIRs to be exclusive governance authorities comparable to a country's legal/judiciary system, why the hell shouldn't governments have a controlling role? > Because governments are limited to national boundaries and the internet is not. Because governments, generally, do a poor job of including stakeholders in the decision making process. Especially when compared to the all-inclusive bottom- up community consensus based process used in the RIR system. Because the RIR process, while inclusive, is necessarily slow in comparison to the speed of innovation on the internet. For stability, that's a good thing. However, the processes of international accords among multiple governments that would be required for the governments to assume a controlling role would not be merely slow, they would be glacial. Because we have a working system in place with operational history and governments have little or no experience with the vital details of the policies in question and even less understanding of the implications of various changes to those policies. I'm sure there are probably more reasons, but, those are the ones that come to mind off the top of my head. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Wed Mar 3 20:51:46 2010 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 3 Mar 2010 20:51:46 -0500 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> Message-ID: <75822E125BCB994F8446858C4B19F0D701C78E5DEF@SUEX07-MBX-04.ad.syr.edu> -----Original Message----- >ITU seems to have talked themselves down from wanting to control ICANN >to wanting to control IANA to wanting to be a competitive IR under >IANA. This is an astute observation. It should tell you something about the politics and about who has power and who doesn't in this game, which is one reason why I refuse to be intimidated by the ITU bogeyman and insist on looking at the larger issues, including a critical assessment of the ICANN/RIR regime. I don't see how - from a purely technical standpoint - ITU as IR under IANA is any more threatening than Comcast or Verizon as competitive IRs under IANA or an Indian nation IR under IANA. There is room for diversity in the policies applied to conservation and aggregation and there are also potential drawbacks. But from a political standpoint, there is a threat. The threat comes from the fact that nation-states have certain forms of regulatory power that, imho, we don't want conjoined with address allocation because it could lead to exclusivity rather than competition/diversity in address allocation policies, and more centralized and controlling internet policies. In other words, the problem is NOT that the ITU wants to be a competitive registry under IANA. It IS that we can't trust nation-states to be open and competitive in their approach to this, especially the ones driving these initiatives at the ITU. This is the underlying political issue that I've been trying to get ya'll to focus on, but it seems that most of you prefer to indulge in group solidarity and bonding routines. OK, have fun. Paint your faces blue, dance in a circle around a bonfire, chant "RIRs good, ITU bad" together. Gnash your teeth and make threatening gestures to "the other," if it makes you feel better. Just be aware that the people in the ITU community are doing the same thing. They consider you to be "the other." And to the rest of us, this is just a turf battle between two tribes that we don't feel part of. I would have expected slightly more sophisticated responses from the people in this community. I would like to see a recognition of the fact that the issue is national governments, not the ITU per se, which is merely responding to pressures from member states; a clearer articulation of why the ip addressing system should be independent of national governments; an embrace of principles of neutral, non political, open and transparent administration of critical resources, an embrace of Internet freedom, etc., etc. I don't see it. I feel no loyalty to your Tribe. What is see is just a turf battle, and the same kind of lousy rationalizations for monopoly power that the telephone companies used in the bad old days. And hey, what is it that makes the ITU and all it stands for so bad, I wonder? If it is not monopolistic power, what is it, other than that they are not you? >I could be mistaken, but it seems to me there's essentially no chance >of the ARIN community supporting a global proposal to make ITU a >competitive IR for public Internet addresses. I would also be >surprised if the other regions welcome ITU treading on their turf. et tu, Herrin, nothing more than a turf battle? --MM From mysidia at gmail.com Wed Mar 3 20:55:34 2010 From: mysidia at gmail.com (James Hess) Date: Wed, 3 Mar 2010 19:55:34 -0600 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C78E5DEE@SUEX07-MBX-04.ad.syr.edu> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <75822E125BCB994F8446858C4B19F0D701C78E5DEE@SUEX07-MBX-04.ad.syr.edu> Message-ID: <6eb799ab1003031755j44657854r6adca9f30fa5c929@mail.gmail.com> On Wed, Mar 3, 2010 at 7:08 PM, Milton L Mueller wrote: > > All resources are managed. The issue is how. An example of a resource that is unmanaged, is LAN capacity. There is no outside entity determining how much bandwidth you need in your LAN. You don't normally need to fill out an application and send off to a registry to justify your need for buying gigabit switches instead of Coax and 10Base5 network kit. But in the case of IP Address space, the resource is _centrally_ managed. And hierarchically distributed, in a manner that meets certain technical needs of the internet. Including needs related to necessary uniqueness of IP network prefixes, aggregability, and effective filtering. "Fairness" as in equality is not a criteria in distribution of IP addresses. RIRs don't give Bob 65,535 IP addresses when he only needs 100, just because Joe got that many IPs, the registries not only centrally manage IP addresses, but they are supposed to assign everyone what they can justify, not artificially equalized (up or down) amounts to arbitrarily make assignments "fair" by some definition. Assigning Bob a network with 65,535 IPs, just because he is a "developing person", and still only needs 100 IPs, is wasteful, and wholly unwarranted. If networks in developing nations have (in the aggregate) not obtained the use of comparable amounts of IP addresses, it was NOT that they were "denied" access to IPs they needed. It is that they didn't really have a justified need for the same amount of IPs, or didn't apply to their regional registry. Perhaps we should next discuss the small number of domain names and Luxury automobiles in developing nations (Even if there are no buyers, how heinous that there aren't exactly the same number available for sale as in the developed countries!). > nonprofit, self-formed group of technicians is assuming transnational regulatory >and governance powers that, in the past, were held by national governments. >That's what this is about. So when you say things like that, you only confirm > - and inflame - those perceptions. I am not justifying or supporting those >perceptions, I am simply telling you that they exist, and trying to break through >the insularity of this community in figuring out how to deal with it. The thing is, the internet is not a government resource. The very essence of the internet is community. > Put another way, if you consider the RIRs to be exclusive governance authorities comparable to a country's legal/judiciary system, why the hell shouldn't governments have a controlling role? The RIRs are not comparable to a legal system or a judiciary system. The RIRs don't have any direct authority over network operators, except de-facto authority. It is more like the level of authority the governance of a professional society has over its members. -- -J From jcurran at arin.net Wed Mar 3 21:22:17 2010 From: jcurran at arin.net (John Curran) Date: Wed, 3 Mar 2010 21:22:17 -0500 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C78E5DEF@SUEX07-MBX-04.ad.syr.edu> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C78E5DEF@SUEX07-MBX-04.ad.syr.edu> Message-ID: <84928067-DF71-464D-86D4-6FD33866878D@arin.net> On Mar 4, 2010, at 9:51 AM, Milton L Mueller wrote: > > And to the rest of us, this is just a turf battle between two tribes that we don't feel part of. > > I would have expected slightly more sophisticated responses from the people in this community. I would like to see a recognition of the fact that the issue is national governments, not the ITU per se, which is merely responding to pressures from member states; a clearer articulation of why the ip addressing system should be independent of national governments; an embrace of principles of neutral, non political, open and transparent administration of critical resources, an embrace of Internet freedom, etc., etc. I don't see it. I feel no loyalty to your Tribe. Milton - The RIR community has repeatedly: 1) Expressed a willingness to work on any problem that the ITU can express in a clear problem statement 2) Actually demonstrated neutral, non-political open and transparent administration of Internet number resources You suggest that this is an issue of "national goverments, not the ITU per se" and it's with respect to the "role of nation-states in governing internet resources." If your assertion is correct, an actual discussion of that issue in *any* forum would be appropriate. Again, the RIR community, ICANN, or ISOC would be fine, or perhaps the WSIS or IGF communities if that is a forum which would be more comfortable to others. As it is, the RIR community is being asked to respond to Terms of Reference which cite concerns of about IPv6 conservation and equitable access to resources for developing countries... One shouldn't be surprised that many in the Internet community are confused by these pretenses for starting discussions... How can we express a more sophisticated response based on "recognition of the fact that the issue is national governments" when not a single party has come forth to discuss this in a open manner, and the actual tasks given to us by the ITU don't even mention the underlying problem you feel we need to address? /John John Curran President and CEO ARIN From joelja at bogus.com Thu Mar 4 01:28:43 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 03 Mar 2010 22:28:43 -0800 Subject: [arin-ppml] RIPE/ITU In-Reply-To: References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> Message-ID: <4B8F531B.3080205@bogus.com> On 03/03/2010 02:40 PM, Owen DeLong wrote: > According to the ITU presentation by Xiaoya yesterday: > > a) IPv4 early adopter advantage/late adopter disadvantage should > not be repeated in IPv6. The essential irony that early v6 adopters got their prefixes 10 years ago should be lost on no-one. While that may have conferred some first mover advantage, what it mostly was in my experience was a non-recoverable expense. Maintaining a consistently liberal assignment policy (which I think the current one is actually) seems like the path to conferring similar privileges to ipv6 newcomers as those requesting prefix assignments in the recent past. > b) "Developing Nations" - The ITU did not specify which ones. > c) Was not covered by the ITU presentation. > d) From the presentation, it sounded like the ITU may submit > their desire to become an additional registry through the > global policy process if that's what they decide to do. The > ITU was clear that nothing has yet been decided, they are > "considering" this matter. The ITU representative did > express surprise and dismay at the level of "overreaction" > from the community at the APNIC meeting. > e) To at least some extent, they did so yesterday. I think the > meeting yesterday was a very good beginning and that > it was a useful and productive discussion. > > I still think that the idea of the ITU possible CIR model as currently > described would be extremely destructive to the good of the internet > and likely harmful to the very countries that the ITU is claiming they > are attempting to benefit. However, I will say that the ITU does seem > to be making an attempt to reach out and open a dialog. > > There's a _LOT_ of cultural difference between the ITU organization > and the RIR communities. The ITU has extremely structured > membership and is very much oriented to being a forum for > governments, although industry "sector" members are permitted > for $20,000/year. ITU meetings are strictly limited to members. > > While I believe that the RIR system is vastly better at representing > the interests of all stakeholders, I also accept that it is a very > unfamiliar and difficult concept for someone with a strong > regulatory background to grasp. > > I think that the discussion yesterday was a good beginning to > bridging that gap. I hope that the ITU will continue to make efforts > to keep an open dialogue with the RIR communities. I think that one > potentially ideal outcome of this process would be for the ITU > to merely recognize the current RIR structure as the proper > forum for internet number resource policies and refer their > interested members to that forum. > > I have no idea how amenable the ITU might be to such an idea. > > I think the best hope of a good outcome will be the result of > continued dialogue. > > Owen > > On Mar 3, 2010, at 11:51 PM, Frank Bulk - iName.com wrote: > >> This part of the discussion touches on some of the fundamental questions I >> have about ITU-T's interest in IP address allocation: >> (a) what does the ITU-T see as the problem with the current system? >> (b) who are the concerns persons/groups that are telling the ITU-T that >> there is a problem, and why aren't their letters/concerns shared on the >> ITU-T's website? >> (c) have those persons/groups raised the concerns with the applicable >> RIR(s)? >> (d) if it's a matter of underrepresentation (i.e. under-developed countries >> aren't asking for resources because they're not able to or don't currently >> need do), why doesn't the ITU-T recommend an appropriate policy to each of >> the RIRs or write an IETF draft that addresses the issue(s)? >> (e) why doesn't the ITU-T visit and work with the existing address >> allocation bodies, namely the RIR(s), rather than work outside the current >> process? >> >> Frank >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of William Herrin >> Sent: Wednesday, March 03, 2010 9:07 AM >> To: Milton L Mueller; John Curran; arin-ppml at arin.net >> Subject: Re: [arin-ppml] RIPE/ITU >> >>> Le 01/03/2010 08:46, Milton L Mueller a ?crit : >>>> As I've said, it's all about the policies. If the ITU or >>> anyone else wants to discuss and promote more >>> reasonable policies I'm all for it. ITU can serve as >>> a useful countervailing force to the RIR monopoly, >>> just as it has with ICANN. >> >> Hi Milton, >> >> I don't see how it helps to have entities compete at the process of >> giving away a combination of a free-pool resource (IPv6 addresses) and >> other peoples' money (the routing slots they use). >> >> If ITU wants in the IR game that badly, I'd like to see them take on >> something that the RIRs aren't already dealing with. Perhaps they >> could draft an RFC and global policy requesting that IANA delegate >> fc00::/8 to ITU. Whether they ever see an expanded role in IP address >> management would, of course, then depend on how open and >> cost-effective a job they do with that off-Internet pool. >> >> >> ITU seems to have talked themselves down from wanting to control ICANN >> to wanting to control IANA to wanting to be a competitive IR under >> IANA. They have a little ways to go yet before they come close to >> talking sense. >> >> I could be mistaken, but it seems to me there's essentially no chance >> of the ARIN community supporting a global proposal to make ITU a >> competitive IR for public Internet addresses. I would also be >> surprised if the other regions welcome ITU treading on their turf. >> >> Pushing the issue seems to me like an awful lot of effort for ITU to >> go to just to make a political statement that's as likely as not to >> backfire and remind everybody why upon the end of NSF funding for the >> InterNIC a decade and change ago, ITU was not invited to step up. >> >> Regards, >> Bill Herrin >> >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From farmer at umn.edu Thu Mar 4 02:03:13 2010 From: farmer at umn.edu (David Farmer) Date: Thu, 04 Mar 2010 01:03:13 -0600 Subject: [arin-ppml] RIPE/ITU In-Reply-To: References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <4B8C834F.6000106@umn.edu> Message-ID: <4B8F5B31.7070902@umn.edu> McTim wrote: > HI David, > > Yes, apologies, I had it in my calendar for the 2nd...it is indeed on Wednesday. > > Terema kasih banyak. > No problem, and thanks for the early reminder anyway. So, I stayed up most of last night watching the session. A few observations I took away from the session. I think Sharil Tamizi made some good comments about seeing through different lenses, "There's a government lens, there's a private sector lens. There's a civil society lens, and there's a business lens. So, in our discussion here, I hope that you also keep those various perspectives in mind so that when you come to the question time, this is something that we can engage in a meaningful debate and discussion." Xiaoya Yang made another comment, "I also want to mention that a fact that it's very difficult for government representative to participate in the Internet policy discussion. Because, as you could acknowledge if I'm representing our government, I cannot speak on my individual behalf." This made me realize that what we in the Internet community consider as an open participatory process, may not actually be open to everyone. As technical people our organizations generally allow us a great deal of latitude to express our individual opinions. This is generally not the case for government bureaucrats, especially in the realm of international diplomacy. I'm not sure what to do about this, but we probably shouldn't just ignore it. I found the argument that a reservation of a large block of IPv6 addresses is necessary for developing countries unconvincing. There was no evidence presented that the current system has any danger of creating an IPv6 scarcity. Whereas, if large blocks of IPv6 addresses begin to be reserved for various constituencies such a scarcity is more likely to be created. If this constituency receives a reservation, other equally deserving constituencies will not be far behind. Such administrative actions are far more likely to create a scarcity than any actual allocation activity. It seems contradictory to me that CIRs would be created by the ITU in such a way that their policies would be subordinate to the current RIRs. It was stated that the paper that discussing that CIRs could be created without adverse impact on the global routing table assumed that CIRs would have to follow the RIR's policies. If this is really the case, then NIRs seem like a more appropriate way to serve the intended purpose of the CIRs. If CIRs are intended to have policies independent of the RIRs then the conclusions of the paper must be called into question. There were statements that competition to the RIRs or among the RIRs could reduce costs for ISP and the they could then invest more in IPv6 deployment. This may or may not be true, no evidence to support this was presented. However, the typical annual fee for an IPv6 /32 allocation to an ISP seems to be a small to minuscule fraction of the implementation or operational cost of an IPv6 network. While fees are always an issue, it seems hard to believe that even the complete elimination of all IPv6 RIR fees could significantly impact the cost structure of implementing IPv6 for an ISP. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From bill at herrin.us Thu Mar 4 02:38:21 2010 From: bill at herrin.us (William Herrin) Date: Thu, 4 Mar 2010 02:38:21 -0500 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C78E5DEF@SUEX07-MBX-04.ad.syr.edu> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C78E5DEF@SUEX07-MBX-04.ad.syr.edu> Message-ID: <3c3e3fca1003032338w36278e64w572515c8ae039962@mail.gmail.com> On Wed, Mar 3, 2010 at 8:18 PM, John Curran wrote: > On Mar 4, 2010, at 9:08 AM, Milton L Mueller wrote: >>You see, my friends, >>what you have going on here is a large segment of the >>world's governments asking themselves why a nonprofit, >>self-formed group of technicians is assuming >>transnational regulatory and governance powers >>that, in the past, were held by national governments. > > When I check my coat, the attendant gives me a tag with > a number on it. The numbers are generally unique to the > establishment, given out freely or as part of a service > bundle for a nominal fee, and aren't given out without > need for one. Read those two paragraphs again John. Process is important but we do ourselves no favors by failing to appreciate 30,000 foot view. On Wed, Mar 3, 2010 at 8:51 PM, Milton L Mueller wrote: >>I could be mistaken, but it seems to me there's essentially no chance >>of the ARIN community supporting a global proposal to make ITU a >>competitive IR for public Internet addresses. I would also be >>surprised if the other regions welcome ITU treading on their turf. > > et tu, Herrin, nothing more than a turf battle? Milton, It will be what ITU makes of it. If ITU pursues the position that they're better able to solve the world's network number issues than the RIRs then it's nothing more than a turf battle and ITU's effort almost certainly fizzles. If ITU wants a seat at the table without a turf battle, they should focus their efforts on something that doesn't seriously overlap existing RIR responsibilities, such as ULA. If ITU wants to back off further and initiate policy discussions in the various regions about things like unequal distribution of addresses then it won't be a turf battle. But before they can get any traction at all on unequal distribution, they'll first have to explain why we should expect addressing to become a persistent zero-sum game. Because it hasn't been a zero-sum game to date and unless it becomes a zero-sum game, unequal distribution is the kind of specious argument that the RIRs' policy development processes are designed to weed out. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From maem at nic.ad.jp Thu Mar 4 02:57:40 2010 From: maem at nic.ad.jp (MAEMURA Akinori) Date: Thu, 4 Mar 2010 16:57:40 +0900 Subject: [arin-ppml] Fwd: [arin-announce] APNIC Community Consultation "IPv6Address Management and ITU" session completed In-Reply-To: References: <327AA565-971F-43D1-82D2-976A3D4F4186@arin.net> Message-ID: <201003041657.CII13079.FNNB@nic.ad.jp> John, Thank you very much both for advising ARIN community of this and for your input and participation in the session. I am really happy to have that session very fruitful with a lot of input not only from the panel but from the floor - I cannot count the number of people who stood in front of the floor microphone. Since this issue is fairly controversial, I had had a concern the session might heat up and become emotional. However it was not the case. The lot of inputs were made unruffledly, articulating the reasons of their argument. Colleagues in ARIN region, As John advised as followed, APNIC is accepting your input. I encourage you to let us have your input. Even in case you will not do it, please check what was discussed there, as it should be very informative for you to think about this issue. Kind Regards, MAEMURA Akinori, APNIC EC In message "[arin-ppml] Fwd: [arin-announce] APNIC Community Consultation "IPv6Address Management and ITU" session completed" "John Curran " wrote: | | | PPML participants - | | For your information and consideration. Apologies for the cross-post, | but this matter has the potential for changes to the policy process itself. | | Thank you! | /John | | === | | Begin forwarded message: | | From: John Curran > | Date: March 4, 2010 3:41:35 AM GMT+08:00 | To: "arin-announce at arin.net" > | Subject: [arin-announce] APNIC Community Consultation "IPv6 Address Management and ITU" session completed | | ARIN Community - | | The previously mentioned APNIC community consultation regarding | "IPv6 Address Management and ITU" was completed earlier today | in Kuala Lumpur, Malaysia. | | For those interested in the outcome, a "raw" transcript and session | summary statement are available here: | | | | I'd like to thank APNIC for hosting this session as it is important to | discuss these issues publicly in timely manner so that input can be | brought to the the March 15-16 ITU IPv6 study group meeting in | Geneva. By having a public discussion of these important issues, | APNIC (as an ITU-D sector member) can submit the outcome for | further consideration in this process. | | While the ITU IPv6 study group is a closed meeting, I have received | an invitation to participate on March 15-16 in Geneva on ARIN's behalf | as an "invited expert", and at that session I will focus on the comments | covered in the public consultation held today. If you have additional | input on this topic that you would like to have considered, please do | the following: | | 1) If your company has a public policy representative involved in the | ITU (generally due to being a supporting member of the ITU), | please introduce me to them asap so that we may coordinate | as appropriate. | | 2) Become familiar with the outcomes of the APNIC session, and | send any additional comments to "IPv6 at apnic.net" and myself. | The APNIC community consultation process continues till Friday | 5 March, 9 AM local meeting time [UTC + 8:00]. I will continue | to take comments beyond that point till ITU IPv6 meeting start | and do my best to convey the input received. | | As you can tell, we're attempting to be as accommodating as possible | to the ITU as they explore the issues in this area, and their processes | are significantly different than ours regarding how input is received and | considered. At this point, ARIN considers it very important to support | these educational efforts, and hope that it will result in better overall | understanding of the success that is today's Internet Registry System. | | I hope this email helps the community understand where we are in | this interesting process. | | Thank you for your support! | /John | | John Curran | President and CEO | American Registry for Internet Numbers | | === | | From: Member Services > | Date: Wed, Feb 24, 2010 at 8:53 AM | Subject: [arin-announce] Be Heard! APNIC Community Consultation Next Week | To: arin-announce at arin.net | | | Internet address management may be on the brink of change. The ITU (International Telecommunications Union) is studying the creation of an alternative International Internet Registry model to operate in parallel to the existing RIR model. | | In collaboration with the NRO, APNIC is hosting a special session at APNIC 29 / APRICOT 2010 to give the global Internet community an opportunity to discuss the issues and ramifications of the alternative model proposed by the ITU. | | APNIC invites all Members of the global Internet Community to participate at: IPv6 Address Management and ITU - Is an "additional parallel structure" required? | | Where: APNIC 29, Kuala Lumpur, Malaysia | When: 14:00 - 15:30 (UTC +8), Wednesday, 3 March 2010 | | APNIC is an ITU-D sector Member and will attend the ITU IPv6 Working Group meeting in March that has been commissioned to study this issue in depth. APNIC will be reporting feedback from our Consultation to ensure community feedback is heard. | ... | = _______________________________________________ | ARIN-Announce | You are receiving this message because you are subscribed to | the ARIN Announce Mailing List (ARIN-announce at arin.net). | Unsubscribe or manage your mailing list subscription at: | http://lists.arin.net/mailman/listinfo/arin-announce | Please contact info at arin.net if you experience any issues. | | | | | _______________________________________________ | PPML | You are receiving this message because you are subscribed to | the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). | Unsubscribe or manage your mailing list subscription at: | http://lists.arin.net/mailman/listinfo/arin-ppml | Please contact info at arin.net if you experience any issues. | | From jcurran at arin.net Thu Mar 4 03:14:23 2010 From: jcurran at arin.net (John Curran) Date: Thu, 4 Mar 2010 03:14:23 -0500 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <3c3e3fca1003032338w36278e64w572515c8ae039962@mail.gmail.com> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C78E5DEF@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca1003032338w36278e64w572515c8ae039962@mail.gmail.com> Message-ID: On Mar 4, 2010, at 3:38 PM, William Herrin wrote: > Read those two paragraphs again John. Process is important but we do > ourselves no favors by failing to appreciate 30,000 foot view. Bill - I appreciate the view expressed in prior two paragraphs, but that appreciation doesn't give any understanding into the reasoning behind that view. The RIR's are not engaged in "transnational regulatory and governance powers": we perform "technical administration of numbering resources". That's a fairly wide gap in perspective, and in order to make any real progress in mutual understanding, it's going to be necessary to examine that difference in viewpoint and the reasoning of each party behind it. Hence, the comparison to coat room tags was to help focus the discussion on what is so different about Internet numbering resources which makes administration of them equivalent to assuming "transnational regulatory and governance powers"... /John John Curran President and CEO ARIN From info at arin.net Thu Mar 4 07:54:44 2010 From: info at arin.net (Member Services) Date: Thu, 04 Mar 2010 07:54:44 -0500 Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment Registration Requirements - Revised Message-ID: <4B8FAD94.2040509@arin.net> The proposal originator submitted a revised version of the proposal. The AC will review this proposal at their next regularly scheduled meeting and decide how to utilize the proposal. Their decision will be announced to the PPML. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Standardize IP Reassignment Registration Requirements Proposal Originator: Chris Grundemann Proposal Version: 3.0 Date: 03-MAR-2010 Proposal type: New Policy term: Permanent Policy statement: ## Definitions ## - Add: 2.3. Organizational Information When required, organization Information must include at a minimum: Legal name, city, state, zip code equivalent and at least one valid technical or abuse POC; inclusion of street address is highly encouraged. The POC shall be designated by the organization and must include at least one verifiable email address, inclusion of a phone number is highly encouraged. 2.12. Residential Customer End-users who are individual persons and not organizations and who recieve service at a place of residence are considered residential customers. ## IPv4 ## - Rename 4.2.3.7. "Reassignment information" to "Registration" and add text: ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including assignment histories, showing their efficient use. - Rename 4.2.3.7.1. "Customer organization information" to "Reassignment Information" and replace text with: Each IPv4 assignment containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. - Strike sections 4.2.3.7.2., 4.2.3.7.4. and 4.2.3.7.5. - Renumber section 4.2.3.7.3. to 4.2.3.7.2., rename to "Assignments visible within 7 days" and replace text with: All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment. - Renumber and replace 4.2.3.7.6. Residential Customer Privacy with: 4.2.3.7.3. Residential Subscribers 4.2.3.7.3.1. Residential Market Area ISPs that assign address space to the infrastructure to which their customers connect rather than to individual subscribers must register assignment information regarding each market area holding such an address block. Market area reassignments shall be registered with the network name used to identify each market area. Any assignment to specific end-users holding /29 and larger blocks still requires registration. A >50% utilization rate shall be considered efficient for market area reassignments from the ISPs most recent allocation. 4.2.3.7.3.2. Residential Customer Privacy To maintain the privacy of their residential customers, an organization with downstream residential customers holding /29 and larger blocks may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS directory record for that block. - Strike section 4.2.6. "Cable Address Space Policy" ## IPv6 ## - Replace Section 6.5.5. with: 6.5.5. Registration ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including assignment histories, showing their efficient use. 6.5.5.1. Reassignment information Each IPv6 assignment containing a /56 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. 6.5.5.2. Assignments visible within 7 days All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment. 6.5.5.3. Residential Subscribers 6.5.5.3.1. Residential Market Area ISPs that assign address space to the infrastructure to which their customers connect rather than to individual subscribers must register assignment information regarding each market area holding such an address block. Market area reassignments shall be registered with the network name used to identify each market area. Any assignment to specific end-users holding /56 and larger blocks still requires registration. A >50% utilization rate shall be considered efficient for market area reassignments from the ISPs most recent allocation. 6.5.5.3.2. Residential Customer Privacy To maintain the privacy of their residential customers, an organization with downstream residential customers holding /56 and larger blocks may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. Rationale: #New and Improved! Specific changes in this version (based on Staff and PPML comments): 1) Added section 2.12. to define residential customers. There is no current definition of residential customers and this has reportedly been an on-going problem for ARIN and it?s customers. 2) 4.2.3.7. and 6.5.5. were re-written to include current text in order to aid ARIN staff when requesting detailed utilization information as part of the normal request process. 3) 4.2.3.7.1. and 6.5.5.1. were re-written to simplify policy by combining the /29 and /56 rules as well as the WHOIS directory visibility requirements directly in a single statement (thanks to Owen DeLong for the suggestion). 3) Several sections were struck do to the clarity and detail gained in revision 3, above. 4) The "7-day" provision was renamed and rewritten for clarity (thanks again to Owen DeLong for the wording). 5) 4.2.3.7.3.1 & 6.5.5.3.1 were re-written for clarity based on many comments on and off list. #Short Rational: This proposal intends to do several things: 1) Bring IPv4 and IPv6 policy more in line with each other to make the NRPM easier to understand and comply with - at least as it relates to reassignment information. 2) Specifically define what organizational information is required to be added to WHOIS when reassignments are made to client organizations. 3) To specifically state that a client organization may designate the POC of their choice for any/all WHOIS entries in policy. This includes designating an upstream POC as their own prefered POC (which allows for simple reassignments). 4) Expands the priviledges previously reserved solely for IPv4 cable ISPs to all ISPs/LIRs with residential/dhcp-type subscribers. 5) Specifically define the term "residential customer." #Expanded Rational: 1) This policy restructures the reassignment and registration sections of the IPv4 and IPv6 policies. a) The IPv4 section is renamed "registration." b) The IPv4 policy is shortened and rewritten for clarity. c) The IPv6 policy is totally rewritten in a format that matches the IPv4 policy. * These structural changes are meant to make it easier to compare the two sections. I believe that having the IPv6 and IPv4 policies written in completely different formats and structures (as they are in many cases now) confuses the issues and makes it very hard to understand what is different and what is the same across the two sections. Bringing them into a similar format should help ease the migration to IPv6 as folks can quickly and easily understand the differences and the similarities. 2) This policy adds a definition of "organizational information" which is used in the existing policy but not currently defined anywhere in the NRPM. a) The definition states that specific addresses are not required for client organizations but asks that they be included when possible. b) The definition states that a POC is required but can be designated by the client organization - it spells out that the client org can choose to use their upstream as a POC. c) The definition requires that the POC have a valid email address but only suggests that it include a phone number. * This definition is meant to address the customer confidentiality concerns that have been brought up recently (by specifically removing the requirement to publish client addresses and telephone numbers), with the smallest negative impact to whois usefulness (retains a valid POC w/ email contact). 3) This policy takes the privileges granted specifically to IPv4 cable operators in section 4.2.6. "Cable Address Space Policy" and grants them to all ISPs who serve residential areas. a) It allows all ISPs with residential coverage to register/swip/rwhois an entire market area. b) It retains the existing residential customer privacy policy for all customers with larger IP blocks. * This change removes the need for any ISP to enter residential customers into whois at all. 4) This policy also extends the >50% utilization rate, currently granted only to IPv4 cable operators, to all ISPs with a residential footprint. * This change will make it easier for ISPs serving residential areas to get the addresses they need - this is key for FTTH operators as well as fixed-wireless and other residential ISPs. *The 50% mark on the most recent allocation is because you can quickly distribute most of your address space across your provisioning footprint, leaving nothing left for growth while the lease count of the provisioned customers catches up to the blocks allocated. (Dan Alexander's words) 5) Current policy references "residential customers" but there is no current definition of residential customers in the NRPM. This has reportedly been an on-going problem for ARIN and it?s customers. Timetable for implementation: Immediate From bill at herrin.us Thu Mar 4 08:39:56 2010 From: bill at herrin.us (William Herrin) Date: Thu, 4 Mar 2010 08:39:56 -0500 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <20100304093548.GA7100@vacation.karoshi.com.> References: <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C78E5DEF@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca1003032338w36278e64w572515c8ae039962@mail.gmail.com> <20100304093548.GA7100@vacation.karoshi.com.> Message-ID: <3c3e3fca1003040539k15368751u985fc4c626fe34dc@mail.gmail.com> On Thu, Mar 4, 2010 at 4:35 AM, wrote: > On Thu, Mar 04, 2010 at 03:14:23AM -0500, John Curran wrote: >> The RIR's are not engaged in "transnational regulatory and governance >> powers": we perform "technical administration of numbering resources". > > ? ? ? ?its not as if each of the RIRs individually or any > ? ? ? ?set of them collectivly is either soveriegn or the > ? ? ? ?result of a treaty negotiation ... there is no basis > ? ? ? ?on which one can claim "transnational regulatory and > ? ? ? ?goverence pwoers" for an RIR. Bill, As for basis, ARIN and the other RIRs hold contracts with IANA that are essentially exclusive within geographic parameters except when we accept a change. And IANA has been the authoritative source for numbers used on the Internet since it was brought into being for that purpose, well before there was a commercial Internet. Excepting accidents every ISP accedes to that. And practically speaking, there's nowhere else you can go for IP addresses that will be honored on the Internet. And we apply strict, frequently arcane rules as to who can have our IP addresses at all and how many they can have. So I think Milton's description of an RIR as "a nonprofit, self-formed group of technicians [with] transnational regulatory and governance powers" is insightful, if incomplete. Obviously there are important things about the RIRs that statement doesn't capture. It doesn't capture the bottom-up nature of the rulemaking process. I doesn't capture the degree to which its public-initiated and public-advanced. But the description offers a starting point from which a group of people used to classic government-based regulation would be able to build a comprehensible understanding of how ARIN fits into the Internet's big picture. More to the point, it yields an immediately comprehensible reason why an ITU competitive registry is a non-starter: because multiple regulators in the same regulatory space doesn't work out well. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From lear at cisco.com Thu Mar 4 09:03:49 2010 From: lear at cisco.com (Eliot Lear) Date: Thu, 04 Mar 2010 15:03:49 +0100 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C78E5DEF@SUEX07-MBX-04.ad.syr.edu> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C78E5DEF@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4B8FBDC5.5070509@cisco.com> Dear Professor Mueller, On 3/4/10 2:51 AM, Milton L Mueller wrote: > But from a political standpoint, there is a threat. The threat comes from the fact that nation-states have certain forms of regulatory power that, imho, we don't want conjoined with address allocation because it could lead to exclusivity rather than competition/diversity in address allocation policies, and more centralized and controlling internet policies. In other words, the problem is NOT that the ITU wants to be a competitive registry under IANA. It IS that we can't trust nation-states to be open and competitive in their approach to this, especially the ones driving these initiatives at the ITU. I think this is a very well put point, and one that deserves to be explored more out in the open. One of the questions I have is how national priorities and values would be applied to CIRs, and how those priorities and values might conflict with those espoused by the RIR (and this) community. Eliot From mysidia at gmail.com Thu Mar 4 09:52:38 2010 From: mysidia at gmail.com (James Hess) Date: Thu, 4 Mar 2010 08:52:38 -0600 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <3c3e3fca1003040539k15368751u985fc4c626fe34dc@mail.gmail.com> References: <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C78E5DEF@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca1003032338w36278e64w572515c8ae039962@mail.gmail.com> <20100304093548.GA7100@vacation.karoshi.com.> <3c3e3fca1003040539k15368751u985fc4c626fe34dc@mail.gmail.com> Message-ID: <6eb799ab1003040652h21dcc440sf4a021cca604d42c@mail.gmail.com> On Thu, Mar 4, 2010 at 7:39 AM, William Herrin wrote: > accept a change. And IANA has been the authoritative source for > numbers used on the Internet since it was brought into being for that > purpose, well before there was a commercial Internet. Excepting > accidents every ISP accedes to that. And practically speaking, there's Yes, but why does every ISP accede to that? Do they fear the government will come in and shut them down or fine/jail them for not using only IP addresses they got re-assigned by a RIR or LIR? Or do they accede to it, because it is an accordance with community standards, and the community would not be willing to connect to their network, if they failed to follow the accepted standards....... and won't route those IPs for them anyways? :) > nowhere else you can go for IP addresses that will be honored on the > Internet. And we apply strict, frequently arcane rules as to who can > have our IP addresses at all and how many they can have. We apply strict, arcane rules, but the rules pertain to the technical network design circumstances under which IP addresses are assigned. We don't apply rules like "Companies in country X get Y number of IP prefixes or Z number of IP addresses" Neither to limit the IP addresses a country may get, nor to force them to get or have reserved IP addresses they don't need. -- -J From bill at herrin.us Thu Mar 4 14:16:12 2010 From: bill at herrin.us (William Herrin) Date: Thu, 4 Mar 2010 14:16:12 -0500 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <6eb799ab1003040652h21dcc440sf4a021cca604d42c@mail.gmail.com> References: <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C78E5DEF@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca1003032338w36278e64w572515c8ae039962@mail.gmail.com> <20100304093548.GA7100@vacation.karoshi.com.> <3c3e3fca1003040539k15368751u985fc4c626fe34dc@mail.gmail.com> <6eb799ab1003040652h21dcc440sf4a021cca604d42c@mail.gmail.com> Message-ID: <3c3e3fca1003041116v55abb945s73cd24d7540bfda4@mail.gmail.com> On Thu, Mar 4, 2010 at 9:52 AM, James Hess wrote: > On Thu, Mar 4, 2010 at 7:39 AM, William Herrin wrote: >> accept a change. And IANA has been the authoritative source for >> numbers used on the Internet since it was brought into being for that >> purpose, well before there was a commercial Internet. Excepting >> accidents every ISP accedes to that. And practically speaking, there's > > Yes, but why does every ISP accede to that? > Do they fear the government will come in and shut them down or > fine/jail them for not using only IP addresses they got re-assigned by > a RIR or LIR? James, They rightly fear their peers and transits will shut them off or at least tightly filter them if they offer a competing announcement for space ARIN assigned to someone else. But they accede to it because they system doesn't work unless someone plays the registry role and IANA and the RIRs are more than good enough at the job to avoid any groundswell movement for replacement. Which in the abstract is the same process by which governments form and maintain. >> nowhere else you can go for IP addresses that will be honored on the >> Internet. And we apply strict, frequently arcane rules as to who can >> have our IP addresses at all and how many they can have. > > We apply strict, arcane rules, ?but the rules pertain to ?the > technical network design circumstances under which IP addresses are > assigned. Name one regulatory agency whose rules don't heavily pertain to technical considerations within their knowledge domain. The authority we successfully exercise is the authority we have. In many respects, the precise source of that authority is academic. ARIN successfully exercises regulatory-like authority over Internet address assignment in North America. A nonprofit, self-formed group of technicians with transnational regulatory powers. "When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck." -James Whitcomb Riley Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From leo.vegoda at icann.org Thu Mar 4 14:31:02 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 4 Mar 2010 11:31:02 -0800 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <3c3e3fca1003040539k15368751u985fc4c626fe34dc@mail.gmail.com> References: <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C78E5DEF@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca1003032338w36278e64w572515c8ae039962@mail.gmail.com> <20100304093548.GA7100@vacation.karoshi.com.> <3c3e3fca1003040539k15368751u985fc4c626fe34dc@mail.gmail.com> Message-ID: <4F729213-E00D-4797-B602-948190790E5C@icann.org> On 4 Mar 2010, at 5:39, William Herrin wrote: [...] > As for basis, ARIN and the other RIRs hold contracts with IANA that In fact, there is an exchange of letters between ICANN and the NRO but not a set of contracts. You can read the letters, which are quite short, on our web site at: http://www.icann.org/correspondence/akplogan-to-twomey-23mar09.pdf and http://www.icann.org/correspondence/twomey-to-akplogan-17apr09.pdf Regards, Leo Vegoda From bill at herrin.us Thu Mar 4 15:32:18 2010 From: bill at herrin.us (William Herrin) Date: Thu, 4 Mar 2010 15:32:18 -0500 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <4F729213-E00D-4797-B602-948190790E5C@icann.org> References: <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C78E5DEF@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca1003032338w36278e64w572515c8ae039962@mail.gmail.com> <20100304093548.GA7100@vacation.karoshi.com.> <3c3e3fca1003040539k15368751u985fc4c626fe34dc@mail.gmail.com> <4F729213-E00D-4797-B602-948190790E5C@icann.org> Message-ID: <3c3e3fca1003041232l345eb675x168bb97f6103e78e@mail.gmail.com> On Thu, Mar 4, 2010 at 2:31 PM, Leo Vegoda wrote: > On 4 Mar 2010, at 5:39, William Herrin wrote: >> As for basis, ARIN and the other RIRs hold contracts with IANA that > > In fact, there is an exchange of letters between ICANN and the >NRO but not a set of contracts. You can read the letters, which >are quite short, on our web site at: Hi Leo, Actually, this is more along the lines of what I had in mind when I wrote that: http://www.nsf.gov/news/news_summ.jsp?cntn_id=102819 http://www.ripe.net/info/resource-admin/news/icanndraft-announce20020409.html#2.2 http://www.ripe.net/info/resource-admin/news/icanndraft-announce20020409.html#6.3 If my google-fu was working today, I'd find the actual documents the NSF approved instead of just references to them... Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Thu Mar 4 15:53:29 2010 From: bill at herrin.us (William Herrin) Date: Thu, 4 Mar 2010 15:53:29 -0500 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <4F729213-E00D-4797-B602-948190790E5C@icann.org> References: <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C78E5DEF@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca1003032338w36278e64w572515c8ae039962@mail.gmail.com> <20100304093548.GA7100@vacation.karoshi.com.> <3c3e3fca1003040539k15368751u985fc4c626fe34dc@mail.gmail.com> <4F729213-E00D-4797-B602-948190790E5C@icann.org> Message-ID: <3c3e3fca1003041253r30c44adeo698b27c72433909c@mail.gmail.com> On Thu, Mar 4, 2010 at 2:31 PM, Leo Vegoda wrote: > On 4 Mar 2010, at 5:39, William Herrin wrote: >> As for basis, ARIN and the other RIRs hold contracts with IANA that > > In fact, there is an exchange of letters between ICANN and the >NRO but not a set of contracts. You can read the letters, which >are quite short, on our web site at: Hi Leo, Actually, this is more along the lines of what I had in mind when I wrote that, not any recent documents: http://www.nsf.gov/news/news_summ.jsp?cntn_id=102819 http://www.ripe.net/info/resource-admin/news/icanndraft-announce20020409.html#2.2 http://www.ripe.net/info/resource-admin/news/icanndraft-announce20020409.html#6.3 If my google-fu was working today, I'd find the actual documents the NSF approved in 1997 instead of just references to them... Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Thu Mar 4 20:41:51 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 5 Mar 2010 09:41:51 +0800 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <6eb799ab1003040652h21dcc440sf4a021cca604d42c@mail.gmail.com> References: <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C78E5DEF@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca1003032338w36278e64w572515c8ae039962@mail.gmail.com> <20100304093548.GA7100@vacation.karoshi.com.> <3c3e3fca1003040539k15368751u985fc4c626fe34dc@mail.gmail.com> <6eb799ab1003040652h21dcc440sf4a021cca604d42c@mail.gmail.com> Message-ID: <96EA4ECA-E0D4-4B86-AF7F-30D4B347AC37@delong.com> On Mar 4, 2010, at 10:52 PM, James Hess wrote: > On Thu, Mar 4, 2010 at 7:39 AM, William Herrin wrote: >> accept a change. And IANA has been the authoritative source for >> numbers used on the Internet since it was brought into being for that >> purpose, well before there was a commercial Internet. Excepting >> accidents every ISP accedes to that. And practically speaking, there's > > Yes, but why does every ISP accede to that? > Do they fear the government will come in and shut them down or > fine/jail them for not using only IP addresses they got re-assigned by > a RIR or LIR? > > Or do they accede to it, because it is an accordance with community standards, > and the community would not be willing to connect to their network, > if they failed to follow the accepted standards....... and won't > route those IPs for them anyways? :) > Obviously the latter, which, IMHO, is superior to the former. Owen From mueller at syr.edu Fri Mar 5 05:55:08 2010 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 5 Mar 2010 05:55:08 -0500 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <4B8F5B31.7070902@umn.edu> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <4B8C834F.6000106@umn.edu> , <4B8F5B31.7070902@umn.edu> Message-ID: <75822E125BCB994F8446858C4B19F0D701C79C6D33@SUEX07-MBX-04.ad.syr.edu> David: >This made me realize that what we in the Internet community consider as >an open participatory process, may not actually be open to everyone. As >technical people our organizations generally allow us a great deal of >latitude to express our individual opinions. This is generally not the >case for government bureaucrats, especially in the realm of >international diplomacy. I'm not sure what to do about this, but we >probably shouldn't just ignore it. good observation. the light begins to dawn! I'm not sure what to do about it either, but I will say that ICANN's solution to this problem - the creation of a Govermental Advisory Committee with "special" powers over "public policy" - is NOT a good idea. this segregates governments into a silo and makes them advocates for governmental powers per se. In these discussions within ICANN, we have repeatedly pointed out that governmental representatives participate effectively in IETF, so a true bottom up model is feasible. But they are dealing with more technical issues than policy issues. for the bottom up model to work it takes a major cultural and institutional change in governments. >Whereas, if large blocks of IPv6 addresses begin to >be reserved for various constituencies such a scarcity is more likely to >be created. If this constituency receives a reservation, other equally >deserving constituencies will not be far behind. Such administrative >actions are far more likely to create a scarcity than any actual >allocation activity. I agree, and that's actually one of the main motivations why the second report ITU commissioned - the one I did - considered the topic of TABLs or transferable blocks. If indeed an initial reservation creates a misallocation, then a TABL system would allow blocks to be transferred easily to those who need them and away from those who don't. The TABL proposal was actually a quite convervative in that it proposed to leave "needs-based allocations" in place for most of the v6 space but created this little safety valve of a section of the space that could be traded. >CIRs would have to follow the RIR's policies. If this is really the >case, then NIRs seem like a more appropriate way to serve the intended >purpose of the CIRs. If CIRs are intended to have policies independent >of the RIRs then the conclusions of the paper must be called into question. This is a slippery area. How do RIRs manage to have different, more locally-suited policies without causing the same problems? What is the difference between CIRs and NIRs? >implementation or operational cost of an IPv6 network. While fees are >always an issue, it seems hard to believe that even the complete >elimination of all IPv6 RIR fees could significantly impact the cost >structure of implementing IPv6 for an ISP. It's not the fees per se, it's the policies, which impose costs and barriers that, as you suggest, may be far more important than the annual fee. The idea is that if RIRs develop policies that are needlessly restrictive an alternative IR would try something different. --MM From mueller at syr.edu Fri Mar 5 05:58:22 2010 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 5 Mar 2010 05:58:22 -0500 Subject: [arin-ppml] RIPE/ITU In-Reply-To: References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C78E5DEF@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca1003032338w36278e64w572515c8ae039962@mail.gmail.com>, Message-ID: <75822E125BCB994F8446858C4B19F0D701C79C6D34@SUEX07-MBX-04.ad.syr.edu> ________________________________________ From: John Curran [jcurran at arin.net] >The RIR's are not engaged in "transnational regulatory and governance >powers": we perform "technical administration of numbering resources". I've dealt with this before: Milton Mueller and Brenden Kuerbis, Regional Address Registries, Governance and Internet Freedom (November 26, 2008). Internet Governance Project. Paper IGP08-005. Available at http://internetgovernance.org/pdf/RIRs-IGP-hyderabad.pdf From BillD at cait.wustl.edu Fri Mar 5 06:36:59 2010 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 5 Mar 2010 05:36:59 -0600 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C79C6D33@SUEX07-MBX-04.ad.syr.edu> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu><70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net><45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org><75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu><612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net><75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu><4B8C834F.6000106@umn.edu>, <4B8F5B31.7070902@umn.edu> <75822E125BCB994F8446858C4B19F0D701C79C6D33@SUEX07-MBX-04.ad.syr.edu> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller > Sent: Friday, March 05, 2010 4:55 AM > To: David Farmer > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] RIPE/ITU > > David: > > > >CIRs would have to follow the RIR's policies. If this is really the > >case, then NIRs seem like a more appropriate way to serve > the intended > >purpose of the CIRs. If CIRs are intended to have policies > independent > >of the RIRs then the conclusions of the paper must be called > into question. > > This is a slippery area. How do RIRs manage to have > different, more locally-suited policies without causing the > same problems? What is the difference between CIRs and NIRs? I think the difference is that NIRs look up the the RIR.... CIRs as I understand it look outside the RIR system. Current system causes the possible inconsistencies and disruption to be limited to 5 RIRs who can coordinate/negotiate more easily that the number of CIRs that would exist. > > >implementation or operational cost of an IPv6 network. > While fees are > >always an issue, it seems hard to believe that even the complete > >elimination of all IPv6 RIR fees could significantly impact the cost > >structure of implementing IPv6 for an ISP. > > It's not the fees per se, it's the policies, which impose > costs and barriers that, as you suggest, may be far more > important than the annual fee. The idea is that if RIRs > develop policies that are needlessly restrictive an > alternative IR would try something different. Something different could be hundreds of times multiplied and address shopping becomes a nightmare > > --MM > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From farmer at umn.edu Fri Mar 5 19:42:53 2010 From: farmer at umn.edu (David Farmer) Date: Fri, 05 Mar 2010 18:42:53 -0600 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C79C6D33@SUEX07-MBX-04.ad.syr.edu> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <4B8C834F.6000106@umn.edu> , <4B8F5B31.7070902@umn.edu> <75822E125BCB994F8446858C4B19F0D701C79C6D33@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4B91A50D.1000008@umn.edu> Milton L Mueller wrote: > David: > >> This made me realize that what we in the Internet community consider as >> an open participatory process, may not actually be open to everyone. As >> technical people our organizations generally allow us a great deal of >> latitude to express our individual opinions. This is generally not the >> case for government bureaucrats, especially in the realm of >> international diplomacy. I'm not sure what to do about this, but we >> probably shouldn't just ignore it. > > good observation. the light begins to dawn! I'm not sure what to do about it either, but I will say that ICANN's solution to this problem - the creation of a Govermental Advisory Committee with "special" powers over "public policy" - is NOT a good idea. this segregates governments into a silo and makes them advocates for governmental powers per se. In these discussions within ICANN, we have repeatedly pointed out that governmental representatives participate effectively in IETF, so a true bottom up model is feasible. But they are dealing with more technical issues than policy issues. for the bottom up model to work it takes a major cultural and institutional change in governments. I've been thinking about this for a couple days, I'm not necessarily sure big changes are required in government or in the way we do things either. It may really only take some subtle changes, more in the way we each think about things, we need to help each other understand there is a roles for both parties to play here. Then maybe some tweaks in our process could help too. I'll point out that our PDP is not unlike a notice-and-comment rulemaking process that is common in many governments. But, our PDP has been turbo charged with Internet technologies like email and remote meeting participation over chat and video streaming, etc... Rather than only using 19th century technologies like face-to-face meetings and letters. So maybe we need to work with governments to get them a little more comfortable using Internet technologies in the policy making processes. Something somewhat related, many governments are being pushed by there citizenry into e-government projects, so maybe this could help them. And, then maybe we need to make a few more provisions for the use of 19th century technology in our processes. The tweaks in our process could be as simple as providing an opportunity for formal written comments to be submitted relating to Draft Policies that are up for adoption consideration at public policy meetings. Such formal comments could maybe be included in the meeting materials, and maybe a summary provided as part of the presentation prior to the floor discussion of each Draft Policy. Then maybe a final opportunity for formal written comments again in the Last Call step of the process. And, who knows it might not just be governments that would make formal comments, maybe some companies or even individuals would like to provide this type of input into the process. Fundamentally, I believe a change of this kind is in harmony with an open, transparent, multi-stakeholder bottom-up policy process. I've heard that similar kinds of formal statements have been made in the past, maybe we just need to explicitly include this in the PDP. Then, make sure that governments know they can make formal comment in these ways if that works better for them. Further, make it clear that is any government, not only those in ARIN's geographic region, just like anyone else in region or not is welcome to participate. I completely agree with you that some group of government representatives with special powers is not a good idea. ARIN, and I believe some of other RIRs too, have government and law enforcement forums intended help create a dialog and to education them on our processes and policies, but these forums have no specific powers. Further, I believe John Curran said ARIN would be willing do much the same for most any constituency, if there are enough interested participants. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From jcurran at arin.net Fri Mar 5 20:06:34 2010 From: jcurran at arin.net (John Curran) Date: Fri, 5 Mar 2010 20:06:34 -0500 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <4B91A50D.1000008@umn.edu> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <4B8C834F.6000106@umn.edu> <4B8F5B31.7070902@umn.edu> <75822E125BCB994F8446858C4B19F0D701C79C6D33@SUEX07-MBX-04.ad.syr.edu> <4B91A50D.1000008@umn.edu> Message-ID: On Mar 6, 2010, at 9:42 AM, David Farmer wrote: > I completely agree with you that some group of government representatives with special powers is not a good idea. ARIN, and I believe some of other RIRs too, have government and law enforcement forums intended help create a dialog and to education them on our processes and policies, but these forums have no specific powers. Further, I believe John Curran said ARIN would be willing do much the same for most any constituency, if there are enough interested participants. David - To the extent that there is a community that wishes additional educational materials to help them come up to speed with participating in ARIN, we will make this happen. /John John Curran President and CEO ARIN From owen at delong.com Fri Mar 5 20:32:11 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Mar 2010 09:32:11 +0800 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <4B91A50D.1000008@umn.edu> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <4B8C834F.6000106@umn.edu> , <4B8F5B31.7070902@umn.edu> <75822E125BCB994F8446858C4B19F0D701C79C6D33@SUEX07-MBX-04.ad.syr.edu> <4B91A50D.1000008@umn.edu> Message-ID: <6E3A22E6-6779-4AEA-BB9B-D12F1B1E71E7@delong.com> On Mar 6, 2010, at 8:42 AM, David Farmer wrote: > Milton L Mueller wrote: >> David: >>> This made me realize that what we in the Internet community consider as >>> an open participatory process, may not actually be open to everyone. As >>> technical people our organizations generally allow us a great deal of >>> latitude to express our individual opinions. This is generally not the >>> case for government bureaucrats, especially in the realm of >>> international diplomacy. I'm not sure what to do about this, but we >>> probably shouldn't just ignore it. >> good observation. the light begins to dawn! I'm not sure what to do about it either, but I will say that ICANN's solution to this problem - the creation of a Govermental Advisory Committee with "special" powers over "public policy" - is NOT a good idea. this segregates governments into a silo and makes them advocates for governmental powers per se. In these discussions within ICANN, we have repeatedly pointed out that governmental representatives participate effectively in IETF, so a true bottom up model is feasible. But they are dealing with more technical issues than policy issues. for the bottom up model to work it takes a major cultural and institutional change in governments. > > I've been thinking about this for a couple days, I'm not necessarily sure big changes are required in government or in the way we do things either. It may really only take some subtle changes, more in the way we each think about things, we need to help each other understand there is a roles for both parties to play here. Then maybe some tweaks in our process could help too. > > I'll point out that our PDP is not unlike a notice-and-comment rulemaking process that is common in many governments. But, our PDP has been turbo charged with Internet technologies like email and remote meeting participation over chat and video streaming, etc... Rather than only using 19th century technologies like face-to-face meetings and letters. > > So maybe we need to work with governments to get them a little more comfortable using Internet technologies in the policy making processes. Something somewhat related, many governments are being pushed by there citizenry into e-government projects, so maybe this could help them. And, then maybe we need to make a few more provisions for the use of 19th century technology in our processes. > I think some of this is already happening organically. Many years ago, I participated in a California PUC proceeding where the parties stipulated to receiving service and notifications over e-mail rather than formal certified postal mail. Combining such case-by-case incidents with some of the new "Gov2.0" initiatives that are now all the rage, I think many governments, including even the united States, are starting to move their processes forward in that direction. > The tweaks in our process could be as simple as providing an opportunity for formal written comments to be submitted relating to Draft Policies that are up for adoption consideration at public policy meetings. Such formal comments could maybe be included in the meeting materials, and maybe a summary provided as part of the presentation prior to the floor discussion of each Draft Policy. > I think, actually, making it clear to the government(s) that they can submit such comments by emailing them to PPML and/or providing a web-based submission portal for such comments to PPML is probably sufficient rather than needing to accept them via snail-mail. The snail-mail process would be error-prone and add significant potential (unbounded) workload for staff. > Then maybe a final opportunity for formal written comments again in the Last Call step of the process. > My approach would allow the government(s) to make as many comments as they like at all steps of the process. > Owen From tedm at ipinc.net Fri Mar 5 20:46:39 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 05 Mar 2010 17:46:39 -0800 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <96EA4ECA-E0D4-4B86-AF7F-30D4B347AC37@delong.com> References: <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <73F74491-3325-41D3-800D-0A662A446157@arin.net> <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu> <4B8E39A8.6090900@gih.com> <3c3e3fca1003030706k2399ff76v13f477d99aec0cfb@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C78E5DEF@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca1003032338w36278e64w572515c8ae039962@mail.gmail.com> <20100304093548.GA7100@vacation.karoshi.com.> <3c3e3fca1003040539k15368751u985fc4c626fe34dc@mail.gmail.com> <6eb799ab1003040652h21dcc440sf4a021cca604d42c@mail.gmail.com> <96EA4ECA-E0D4-4B86-AF7F-30D4B347AC37@delong.com> Message-ID: <4B91B3FF.3000803@ipinc.net> Owen DeLong wrote: > On Mar 4, 2010, at 10:52 PM, James Hess wrote: > >> On Thu, Mar 4, 2010 at 7:39 AM, William Herrin wrote: >>> accept a change. And IANA has been the authoritative source for >>> numbers used on the Internet since it was brought into being for that >>> purpose, well before there was a commercial Internet. Excepting >>> accidents every ISP accedes to that. And practically speaking, there's >> Yes, but why does every ISP accede to that? >> Do they fear the government will come in and shut them down or >> fine/jail them for not using only IP addresses they got re-assigned by >> a RIR or LIR? >> >> Or do they accede to it, because it is an accordance with community standards, >> and the community would not be willing to connect to their network, >> if they failed to follow the accepted standards....... and won't >> route those IPs for them anyways? :) >> > Obviously the latter, which, IMHO, is superior to the former. > The latter is what works for us! I frankly think the ITU needs to stay out of this. I would not take kindly to any initiatives from the ITU to interfere with ICANN's operations in the existing RIR governance. I likely would be null-routing any IP addressing that the ITU assigns out, at least for a while. While the ITU may be hell-bent on becoming an RIR they aren't doing it to help the Internet, they are only interested in doing it because they want to stick their noses into something they never understood in the first place. Ted From mueller at syr.edu Fri Mar 5 21:06:22 2010 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 5 Mar 2010 21:06:22 -0500 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <4B91A50D.1000008@umn.edu> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <4B8C834F.6000106@umn.edu> , <4B8F5B31.7070902@umn.edu> <75822E125BCB994F8446858C4B19F0D701C79C6D33@SUEX07-MBX-04.ad.syr.edu>, <4B91A50D.1000008@umn.edu> Message-ID: <75822E125BCB994F8446858C4B19F0D701C79C6D3E@SUEX07-MBX-04.ad.syr.edu> ________________________________________ From: David Farmer [farmer at umn.edu] >I've been thinking about this for a couple days, I'm not necessarily >sure big changes are required in government or in the way we do things >either. It may really only take some subtle changes, more in the way we >each think about things, we need to help each other understand there is >a roles for both parties to play here. Then maybe some tweaks in our >process could help too. I believe it will take big, long-term cultural changes, but on the whole your attitude and suggestions are constructive. >I'll point out that our PDP is not unlike a notice-and-comment >rulemaking process that is common in many governments. But, our PDP has >been turbo charged with Internet technologies like email and remote >meeting participation over chat and video streaming, etc... Rather than >only using 19th century technologies like face-to-face meetings and >letters. first, don't underestimate the degree to which RIRs, IETF and ICANN rely on f2f meetings using "19th century" technologies like jet planes and computerized travel reservation intermediaries. Of course these meetings build on an underlying infrastructure of online discussion, texts and coordination, but speaking from experience, if you don't go to an ICANN meeting you don't really know what's going on and won't be that influential, and I suspect the RIRs are similar (will go to my first ARIN meeting in toronto; have been to a RIPE). second, you're right about notice and comment, but to understand and intervene in those processes via N&C one must be quite specialized. anyway I think your idea about allowing written submissions is great, that would help some civil society organizations not just govts, but it wouldn't fundamentally alter the dynamics, because whoever comments still would have to be a highly specialized follower of the process with sufficient technical expertise to understand what it means, e.g., to understand the policy implications of changing the way SWIP data is collected and distributed. >So maybe we need to work with governments to get them a little more >comfortable using Internet technologies in the policy making processes. Good luck with that. And I am not being sarcastic, I am wishing you well. It's taken about 10 years for us to get the businesspeople and IP lawyers in ICANN to feel comfortable with online discussions via email or wikis. We're still working on the govs. But some of them have insitutional constraints on what they can say, they are part of a hierarchical structure which requires the rep to go back to their superiors for approval before they can say anything. This will not change overnight. A good experience if you want to "train up" for this work with governments would be to attend a meeting or consultation of the Internet Governance Forum, which succeeded in combining business, internet techies, govts and civil society but its interactions still reflect the significant cultural/organizational differences, with a few notable exceptions. Or maybe accompany John C. and me to the ITU meeting. Breathe the atmosphere.... >The tweaks in our process could be as simple as providing an opportunity >for formal written comments to be submitted relating to Draft Policies >that are up for adoption consideration at public policy meetings. Such >formal comments could maybe be included in the meeting materials, and >maybe a summary provided as part of the presentation prior to the floor >discussion of each Draft Policy. >Then maybe a final opportunity for formal written comments again in the >Last Call step of the process. Noted. I like this idea. >Further, make it clear that is any >government, not only those in ARIN's geographic region, just like anyone >else in region or not is welcome to participate. Another good idea. But again, the essential constraint is the supply of someone from a government willing to follow ip address arcana. Following RIRs is extremely hard for ME; you can imagine what it would be like for a mid-level bureaucrat in the Ministry of Information. >I completely agree with you that some group of government >representatives with special powers is not a good idea. Good. Hold on to that thought. From owen at delong.com Fri Mar 5 21:26:26 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Mar 2010 10:26:26 +0800 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C79C6D3E@SUEX07-MBX-04.ad.syr.edu> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <4B8C834F.6000106@umn.edu> , <4B8F5B31.7070902@umn.edu> <75822E125BCB994F8446858C4B19F0D701C79C6D33@SUEX07-MBX-04.ad.syr.edu>, <4B91A50D.1000008@umn.edu> <75822E125BCB994F8446858C4B19F0D701C79C6D3E@SUEX07-MBX-04.ad.syr.edu> Message-ID: <9B3AFE62-84EB-4EBD-B183-8E4417E523CB@delong.com> On Mar 6, 2010, at 10:06 AM, Milton L Mueller wrote: > ________________________________________ > From: David Farmer [farmer at umn.edu] > >> I've been thinking about this for a couple days, I'm not necessarily >> sure big changes are required in government or in the way we do things >> either. It may really only take some subtle changes, more in the way we >> each think about things, we need to help each other understand there is >> a roles for both parties to play here. Then maybe some tweaks in our >> process could help too. > > I believe it will take big, long-term cultural changes, but on the whole your attitude and suggestions are constructive. > >> I'll point out that our PDP is not unlike a notice-and-comment >> rulemaking process that is common in many governments. But, our PDP has >> been turbo charged with Internet technologies like email and remote >> meeting participation over chat and video streaming, etc... Rather than >> only using 19th century technologies like face-to-face meetings and >> letters. > > first, don't underestimate the degree to which RIRs, IETF and ICANN rely on f2f meetings using "19th century" technologies like jet planes and computerized travel reservation intermediaries. Of course these meetings build on an underlying infrastructure of online discussion, texts and coordination, but speaking from experience, if you don't go to an ICANN meeting you don't really know what's going on and won't be that influential, and I suspect the RIRs are similar (will go to my first ARIN meeting in toronto; have been to a RIPE). Nope. I've done a couple of ARIN meetings by remote in my history, and that was before the tools were as good as they are today. Is it easier to participate in the room? Yes. Do you have more influence than if you participate on the mailing list? Nope. > second, you're right about notice and comment, but to understand and intervene in those processes via N&C one must be quite specialized. anyway I think your idea about allowing written submissions is great, that would help some civil society organizations not just govts, but it wouldn't fundamentally alter the dynamics, because whoever comments still would have to be a highly specialized follower of the process with sufficient technical expertise to understand what it means, e.g., to understand the policy implications of changing the way SWIP data is collected and distributed. > Even the government is now accepting written submissions via web pages in most public comment, so, I don't see why we wouldn't be able to make that work for their submissions as well. > Owen From mueller at syr.edu Wed Mar 17 04:34:51 2010 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 17 Mar 2010 04:34:51 -0400 Subject: [arin-ppml] RIPE/ITU In-Reply-To: <03ea01cac557$f1acc9e0$d5065da0$@net> References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net> <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org> <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu> <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net> <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu> <4B8C834F.6000106@umn.edu> , <4B8F5B31.7070902@umn.edu> <75822E125BCB994F8446858C4B19F0D701C79C6D33@SUEX07-MBX-04.ad.syr.edu>, <4B91A50D.1000008@umn.edu> <75822E125BCB994F8446858C4B19F0D701C79C6D3E@SUEX07-MBX-04.ad.syr.edu> <03ea01cac557$f1acc9e0$d5065da0$@net> Message-ID: <75822E125BCB994F8446858C4B19F0D701C7E12F31@SUEX07-MBX-04.ad.syr.edu> Tony: The ITU created a correspondence group that will better define problems and possible solutions. I haven't read your draft yet but it looks like exactly the kind of contribution that would be useful in that context. --MM > -----Original Message----- > From: Tony Hain [mailto:alh-ietf at tndh.net] > Sent: Tuesday, March 16, 2010 6:28 PM > To: Milton L Mueller > Subject: RE: [arin-ppml] RIPE/ITU > > I was on vacation when this thread went by on PPML, so I am sure I am > missing context. In any case I have had an allocation proposal around in > various forms for close to a decade that could impact this discussion: > http://www.ietf.org/id/draft-hain-ipv6-geo-addr-01.txt > A few years ago just after ITU meetings the copy on my personal server > would > get lots of hits, but I haven't looked lately. It deals with the > 'control > issue' by pre-allocating on a global basis. The questions I have gotten > about it relate to alignment with national borders, but all that drops > off > once people realize it removes -all control-. As you noted there is a > cultural mismatch between the communities over process, but at the end > of > the day they are both stuck in the mindset that they want to exercise > control over the resource. > > The only technical objection to the proposal is that it doesn't align > with > historical business practice. More specifically the topology that exists > would not align traffic flows with existing financial relationships. My > response is that topology is changing all the time, and it could easily > evolve to deal with this allocation approach if people wanted to. The > biggest issue most people have is that they see the routing core as > having > to handle one-and-only-one allocation model, where in reality it already > handles multiple virtual tables for private vpn's, so adding yet one > more > for this scheme is technically trivial. People just need to decide that > doing so is cheaper than the alternative of a bloated routing table from > random PI, or complete loss of control due to regulatory requirements. > So > far as you have noted they are much more about maintaining the status > quo > than really thinking about alternatives and what might be necessary to > implement them. > > Tony > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On > > Behalf Of Milton L Mueller > > Sent: Friday, March 05, 2010 6:06 PM > > To: David Farmer > > Cc: ARIN PPL (arin-ppml at arin.net) > > Subject: Re: [arin-ppml] RIPE/ITU > > > > ________________________________________ > > From: David Farmer [farmer at umn.edu] > > > > >I've been thinking about this for a couple days, I'm not necessarily > > >sure big changes are required in government or in the way we do > things > > >either. It may really only take some subtle changes, more in the way > > we > > >each think about things, we need to help each other understand there > > is > > >a roles for both parties to play here. Then maybe some tweaks in our > > >process could help too. > > > > I believe it will take big, long-term cultural changes, but on the > > whole your attitude and suggestions are constructive. > > > > >I'll point out that our PDP is not unlike a notice-and-comment > > >rulemaking process that is common in many governments. But, our PDP > > has > > >been turbo charged with Internet technologies like email and remote > > >meeting participation over chat and video streaming, etc... Rather > > than > > >only using 19th century technologies like face-to-face meetings and > > >letters. > > > > first, don't underestimate the degree to which RIRs, IETF and ICANN > > rely on f2f meetings using "19th century" technologies like jet planes > > and computerized travel reservation intermediaries. Of course these > > meetings build on an underlying infrastructure of online discussion, > > texts and coordination, but speaking from experience, if you don't go > > to an ICANN meeting you don't really know what's going on and won't be > > that influential, and I suspect the RIRs are similar (will go to my > > first ARIN meeting in toronto; have been to a RIPE). > > second, you're right about notice and comment, but to understand and > > intervene in those processes via N&C one must be quite specialized. > > anyway I think your idea about allowing written submissions is great, > > that would help some civil society organizations not just govts, but > it > > wouldn't fundamentally alter the dynamics, because whoever comments > > still would have to be a highly specialized follower of the process > > with sufficient technical expertise to understand what it means, e.g., > > to understand the policy implications of changing the way SWIP data is > > collected and distributed. > > > > >So maybe we need to work with governments to get them a little more > > >comfortable using Internet technologies in the policy making > > processes. > > > > Good luck with that. And I am not being sarcastic, I am wishing you > > well. It's taken about 10 years for us to get the businesspeople and > IP > > lawyers in ICANN to feel comfortable with online discussions via email > > or wikis. We're still working on the govs. But some of them have > > insitutional constraints on what they can say, they are part of a > > hierarchical structure which requires the rep to go back to their > > superiors for approval before they can say anything. This will not > > change overnight. > > > > A good experience if you want to "train up" for this work with > > governments would be to attend a meeting or consultation of the > > Internet Governance Forum, which succeeded in combining business, > > internet techies, govts and civil society but its interactions still > > reflect the significant cultural/organizational differences, with a > few > > notable exceptions. Or maybe accompany John C. and me to the ITU > > meeting. Breathe the atmosphere.... > > > > >The tweaks in our process could be as simple as providing an > > opportunity > > >for formal written comments to be submitted relating to Draft > Policies > > >that are up for adoption consideration at public policy meetings. > > Such > > >formal comments could maybe be included in the meeting materials, and > > >maybe a summary provided as part of the presentation prior to the > > floor > > >discussion of each Draft Policy. > > >Then maybe a final opportunity for formal written comments again in > > the > > >Last Call step of the process. > > > > Noted. I like this idea. > > > > >Further, make it clear that is any > > >government, not only those in ARIN's geographic region, just like > > anyone > > >else in region or not is welcome to participate. > > > > Another good idea. > > But again, the essential constraint is the supply of someone from a > > government willing to follow ip address arcana. Following RIRs is > > extremely hard for ME; you can imagine what it would be like for a > mid- > > level bureaucrat in the Ministry of Information. > > > > >I completely agree with you that some group of government > > >representatives with special powers is not a good idea. > > > > Good. Hold on to that thought. > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. From michael.dillon at bt.com Wed Mar 17 10:56:36 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 17 Mar 2010 14:56:36 -0000 Subject: [arin-ppml] IPv4 runnout convergence Message-ID: <28E139F46D45AF49A31950F88C497458058767D2@E03MVZ2-UKDY.domain1.systemhost.net> It is interesting to look at the IPv4 runnout predictions on this site, and see that they predict APNIC will run dry in Jan 2012 and ALL THE OTHER RIRs will run dry by June 2012. It appears that all the RIR-level exhaustion events are converging on the first half of 2012, not spread out over a couple of years like many have thought. I have long expected that Wall Street analysts would end up grilling CEOs on their IPv6 transition plans. Getting this close to the end, I wonder if anyone has heard of this happening? --Michael Dillon From rcannon100 at yahoo.com Wed Mar 17 12:11:57 2010 From: rcannon100 at yahoo.com (Robert Cannon) Date: Wed, 17 Mar 2010 09:11:57 -0700 (PDT) Subject: [arin-ppml] RIPE/ITU - Govt Reps In-Reply-To: <4B8F5B31.7070902@umn.edu> Message-ID: <182481.12507.qm@web37904.mail.mud.yahoo.com> --- On Thu, 3/4/10, David Farmer wrote: > Xiaoya Yang made another comment, "I also want to mention > that a fact that it's very difficult for government > representative to participate in the Internet policy > discussion. Because, as you could acknowledge if I'm > representing our government, I cannot speak on my individual > behalf." > > This made me realize that what we in the Internet community > consider as an open participatory process, may not actually > be open to everyone.? As technical people our > organizations generally allow us a great deal of latitude to > express our individual opinions.? This is generally not > the case for government bureaucrats, especially in the realm > of international diplomacy.? I'm not sure what to do > about this, but we probably shouldn't just ignore it. If I may.... Simple answer is yes. A civil servant in their official capacity can only speak with clearance from the decision makers / bosses. If the agency has no official formal position on a specific question, the civil servant may not be able to speak at all. If the agency is considering a question, but has not issued an opinion, the civil servant cant speak. If the agency has expressed an opinion, then its usually 3 years later. But that's a general rule - with exceptions. There are civil servants that do speak, sometimes they are high in leadership - sometimes they sit in unique offices. Some times you can get a civil servant to speak, but not on the record (in other words, perhaps in the hallway). A civil servant who speaks generally does not represent their agency and cannot bind their agency. Every agency, govt, and country will be different. One answer is creating an environment where the person you want to speak can speak. Finally, sometimes civil servants who dont speak - are very good listeners (and are taking information back to their agencies). B From terry.l.davis at boeing.com Wed Mar 17 12:31:03 2010 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Wed, 17 Mar 2010 09:31:03 -0700 Subject: [arin-ppml] RIPE/ITU - Govt Reps In-Reply-To: <182481.12507.qm@web37904.mail.mud.yahoo.com> References: <4B8F5B31.7070902@umn.edu> <182481.12507.qm@web37904.mail.mud.yahoo.com> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF551547BCF7@XCH-NW-05V.nw.nos.boeing.com> Bob/David Works pretty much the same for those of us with enterprises/business as for government. Take care Terry > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Robert Cannon > Sent: Wednesday, March 17, 2010 9:12 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] RIPE/ITU - Govt Reps > > --- On Thu, 3/4/10, David Farmer wrote: > > Xiaoya Yang made another comment, "I also want to mention > > that a fact that it's very difficult for government > > representative to participate in the Internet policy > > discussion. Because, as you could acknowledge if I'm > > representing our government, I cannot speak on my individual > > behalf." > > > > This made me realize that what we in the Internet community > > consider as an open participatory process, may not actually > > be open to everyone.? As technical people our > > organizations generally allow us a great deal of latitude to > > express our individual opinions.? This is generally not > > the case for government bureaucrats, especially in the realm > > of international diplomacy.? I'm not sure what to do > > about this, but we probably shouldn't just ignore it. > > If I may.... > > Simple answer is yes. A civil servant in their official > capacity can only speak with clearance from the decision > makers / bosses. If the agency has no official formal > position on a specific question, the civil servant may not be > able to speak at all. If the agency is considering a > question, but has not issued an opinion, the civil servant > cant speak. If the agency has expressed an opinion, then its > usually 3 years later. > > But that's a general rule - with exceptions. There are civil > servants that do speak, sometimes they are high in leadership > - sometimes they sit in unique offices. Some times you can > get a civil servant to speak, but not on the record (in other > words, perhaps in the hallway). A civil servant who speaks > generally does not represent their agency and cannot bind > their agency. > > Every agency, govt, and country will be different. One > answer is creating an environment where the person you want > to speak can speak. > > Finally, sometimes civil servants who dont speak - are very > good listeners (and are taking information back to their agencies). > > B > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From jKnowles at Cogentco.com Wed Mar 17 17:41:35 2010 From: jKnowles at Cogentco.com (Knowles, John) Date: Wed, 17 Mar 2010 17:41:35 -0400 Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality Message-ID: We are opposed to policy 2001-3 because it would make internet security harder. John Knowles. jknowles at cogentco.com Cogent Communications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ser at layer42.net Wed Mar 17 19:16:00 2010 From: ser at layer42.net (Steve Rubin) Date: Wed, 17 Mar 2010 16:16:00 -0700 Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality In-Reply-To: References: Message-ID: <51C1FBAA-54E9-4585-843A-1967DB9B8B02@layer42.net> On Mar 17, 2010, at 2:41 PM, Knowles, John wrote: > We are opposed to policy 2001-3 because it would make internet security harder. > > John Knowles. > jknowles at cogentco.com > Cogent Communications. > It would also make it difficult for sales people from certain companies people to mine for leads. -- Steve Rubin ser at layer42.net Layer42 Networks http://www.layer42.net/ Expect More from A Web Solutions Provider (408)450-5742 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen at sprunk.org Wed Mar 17 19:19:15 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 17 Mar 2010 18:19:15 -0500 Subject: [arin-ppml] RIPE/ITU - Govt Reps In-Reply-To: <182481.12507.qm@web37904.mail.mud.yahoo.com> References: <182481.12507.qm@web37904.mail.mud.yahoo.com> Message-ID: <4BA16373.5050304@sprunk.org> On 17 Mar 2010 11:11, Robert Cannon wrote: > --- On Thu, 3/4/10, David Farmer wrote: > >> Xiaoya Yang made another comment, "I also want to mention that a fact that it's very difficult for government representative to participate in the Internet policy discussion. Because, as you could acknowledge if I'm representing our government, I cannot speak on my individual behalf." >> >> This made me realize that what we in the Internet community consider as an open participatory process, may not actually be open to everyone. As technical people our organizations generally allow us a great deal of latitude to express our individual opinions. This is generally not the case for government bureaucrats, especially in the realm of international diplomacy. I'm not sure what to do about this, but we probably shouldn't just ignore it. >> > If I may.... > > Simple answer is yes. A civil servant in their official capacity can only speak with clearance from the decision makers / bosses. If the agency has no official formal position on a specific question, the civil servant may not be able to speak at all. If the agency is considering a question, but has not issued an opinion, the civil servant cant speak. If the agency has expressed an opinion, then its usually 3 years later. > IMHO, if an entity cannot find even one single representative who is willing to attend and voice the entity's position(s) as their own, perhaps that entity should reconsider its position(s). If the entity has no position(s) at all to be expressed, then what is the problem? Their representatives can easily attend as observers and report back, which is all the participation that an entity with no position(s) could logically do anyway. I _am_ sensitive to bureaucrats' concern that underlings' comments could be misinterpreted as official government policy/direction/intent, but the Internet community has a long tradition of allowing participants to put on or take off various "hats" when they speak, and everyone in attendance will understand the difference between someone expressing an official position and a personal one _as long as they say which it is_. We also have a quasi-tradition of people speaking on behalf of others who are not allowed to speak, are underrepresented, or are not present at all. Those who are not allowed to comment on the record should be able to find someone of similar mind to make their comments for them. If governments _want_ to participate, they can find a way to do it. Based on attendance at various meetings, though, it appears that they rarely show up even as observers, which makes me question whether the real problem is not being _able_ to participate or rather not _wanting_ to participate--or not even understanding what forums exist for them to participate in. And, the longer they stay silent (either by choice or by ignorance), the further behind the curve they are going to fall and the less interested anyone is going to be in what they have to say when they finally get around to making an official comment on something that was discussed and settled several years previously. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From joe at oregon.uoregon.edu Wed Mar 17 17:44:07 2010 From: joe at oregon.uoregon.edu (Joe St Sauver) Date: Wed, 17 Mar 2010 14:44:07 -0700 (PDT) Subject: [arin-ppml] Comments on Draft Policy 2010-3 Message-ID: <10031714440720_21B4C@oregon.uoregon.edu> Hi, I have reviewed https://www.arin.net/policy/proposals/2010_3.html dated 2 Feb 2010, and I have many serious concerns about the draft policy in its current form. Let me go over just a dozen of those concerns now. 1) The overarching purpose of IP whois point of contact information is and should be to insure that operational problems can be addressed by those who are most knowledgeable and best situated to address them. While ISPs have a role in limiting or responding to problematic traffic flowing through their networks, ultimately it is the down stream customer who is configuring and operating systems which are sourcing or sinking traffic, and it is those customers who will need to fix many operational issues. If customer address and telephone information is redacted from IP whois reassignment and reallocation data, the community's ability to contact the administrator of a problematic system is profoundly impaired, and we are reduced to relying on a third party, the upstream ISP, to proxy our query or complaint to their downstream customer. Some ISPs may be willing to play this intermediate role, others may not. There is nothing in this policy that compells them to take on that additional work (nor is there any indication of how the costs of meeting that communication "mandate" might be paid). Even if ISPs *are* required to forward communications they receive to their downstream confidential customer, it will likely take time for them to do so -- maybe just a minute or two, but more likely hours, or perhaps even days if this process is handled manually. When dealing with problematic systems, time can be of the essence, yet this policy as currently written enforces no processing time "SLA" on ISPs who may have elected to shroud customer data. 2) As written, it is unclear that ARIN would be permitted to respond to legal process seeking disclosure of shrouded customer contact information. In particular, while the policy states that "the customer's actual information must be provided to ARIN on request" the policy also states that the information "will be held in the strictest confidence." The customer information will be held in "strictest confidence" by *whom?* The ISP? ARIN? The ISP *and* ARIN? As written, the policy is at best ambiguous, and at worst the proposed language may create a new duty, requiring ARIN to employ all reasonable efforts to protect customer data it may receive (including potentially defending against legal actions seeking compulsory redisclosure of the customer's data). 3) The draft policy allows *ISPs* the option of shrouding their customer's data, ("*ISPs* may choose to...", emphasis added), but what of the customer's preferences when it comes to the release of their point of contact data? The policy is silent on this matter. While *some* customers may want to have their contact information concealed by their ISP, *other* customers may actually prefer full disclosure and complete transparency. For example, full disclosure of contact information may be preferred by some as a matter of bolstering one's online reputation (thereby avoiding what some term suspicion about "men in ski masks"). Unfortunately, as written, disclosure or non-disclosure of the customer's point of contact data is solely a matter for the ISP's discretion. This ignores the role and importance of customer preferences when it comes to controlling the release of their own data. 4) Does this proposed policy apply to both PA and PI customer address space? The policy speaks only of "reassignments and reallocations" -- is that meant to implicitly limit this to just PA space? In the case of PI space that may be announced by multiple ISPs for multihoming, which ISP has controlling authority when it comes to determining if customer address and phone number information should be withheld? If there are multiple upstream ISPs, which ISP's address and phone number would be shown in lieu of the customer's information? Either? Both? The customer him/her self? The policy is silent in the face of this potential complexity, and potentially clouds control over PI netblocks. 5) Eroding the availability of customer point of contact data hinders the public's ability to formally or informally audit ISP IP reallocations and reassignments, even though we are now approaching a critical period when IPv4 address scarcity may motivate shenanigans or abuse. This lack of transparency is inconsistent with the Number Resource Organizations first and most critical goal, which is to "Protect the unallocated Number Resource pool" (http://www.nro.net/about/index.html) 6) Will this proposed policy be consistent with the policies of other regional registries? If ARIN is more permissive in its reassignment and reallocation process than other registries, ARIN invites an influx of abusive customers/cybercriminals, potentially damaging the value of ARIN-assigned/ARIN-allocated space for all who have or will receive address space from ARIN. 7) Access to IP whois/rwhois data is critical to working cyber abuse issues in many circumstances (for example, consider a case where malware or phishing incident involves URIs with raw IP addresses rather than domain names). Removing customer point of contact information from whois/rwhois hinders efforts to resolve incidents of cyber abuse. Since the rationale for this policy makes it clear that it is motivated solely by competitive concerns, the importance of those competitive concerns should be weighed against the damage this proposed policy would potentially cause to the safety and stability of the Internet. 8) Customer address and phone number information serves an important purpose with respect to customer differentiation and disambiguation. Consider an assignment made to a customer with a common name (hypothetically "John Smith" or "Jane Doe"). If whois/rwhois data lacks address and phone number information, how am I to distinguish John Smith of Akron Ohio from John Smith of Wichita Kansas? Answer, entities (other than the ISP) couldn't, absent assignment of a unique global customer identifier. Confouding those two "John Smiths" could have profound consequences. For example, what if a block list operator incorrectly attributed both of those blocks to a single malicious "John Smith"? In a case where one's abusive, and one's wholly innocent, the misdeeds of the abusive customer may inadvertently result in unjustified action against the innocent customer who has the misfortune of having the same "customer name." 9) For that matter, what constitutes an acceptable customer "name"? If, hypothetically, a celebrity such as Cher held a netblock, would "Cher" be enough of a name to meet the requirement of this proposed policy? Are nicknames sufficient? First initial plus a last name? Just first and last initials? What of a corporation? Is just the corporation's name to be listed? The corporation's name plus a human point of contact there? Are role names acceptable? (I wonder how many netblocks will end up owned by the customer with the name of "hostmaster", eh?) 10) Arguing in the alternative, if customer privacy *is* a critical objective, the draft as written fails to adequately shield the core of customer identity information, namely the customer's name. Given the customer's name, it may be possible for data brokers and other "e-penders" to merge the customer's name with other data sources to the ultimate detriment of the customer's privacy. Similarly, continuing to argue in the alternative, if privacy *is* important, the policy as written still allows the public to identify and potentially tabulate all reassignments or reallocations assigned to a given customer. Thus, if a single customer with dozens or (perhaps even hundreds) of small distributed reassignments or reallocations is perceived differently than a single customer with a single monolithic netblock, this policy fails to "protect" that customer's (rather dubious) address usage. I also have issues with the proposed policy's process, oversight and review. 11) The draft policy has a proposed implementation timeline that is abrupt: implementation is to be "immediate." No explanation or justification is provided for this highly expedited deployment time frame. If this policy were to be passed, more time should be provided to allow ISPs and customers to prepare to accomodate this policy. 12) If a customer is wronged by this policy, does the customer have the right to appeal their ISP's actions? If so, to whom? The policy is silent on this point. If this policy is passed, will there be any analysis of the uptake of this policy, or any review of the burden it imposes on ARIN or other members of the community? No. Given all of these flaws, I urge that this policy not be adopted unless/until the preceding issues are considered and satisfactorily resolved. Thank you for considering this feedback on Draft Policy 2010-3. Joe St Sauver, Ph.D. Disclaimer: the opinions expressed are my own, and do not necessarily represent the opinion of any other entity or organization. From farmer at umn.edu Thu Mar 18 11:30:26 2010 From: farmer at umn.edu (David Farmer) Date: Thu, 18 Mar 2010 10:30:26 -0500 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <03b501cac543$127f6520$377e2f60$@net> References: <75cb24521002220705l1283decy46be540b23be810@mail.gmail.com> <28E139F46D45AF49A31950F88C497458054324FC@E03MVZ2-UKDY.domain1.systemhost.net> <03b501cac543$127f6520$377e2f60$@net> Message-ID: <4BA24712.3090903@umn.edu> Tony Hain wrote: > I haven't kept up with the PPML list this calendar year, but clearly need to > get back to it. I have a draft related to FC00::/8 > http://www.ietf.org/id/draft-hain-ipv6-ulac-01.txt > The major diff between the earlier IETF and the Vixie version is the > specific recognition that making an organization with a public /44 have to > figure out how to align random /48's under this prefix makes no sense > operationally. Comments welcome... > > Tony Tony, Thanks for the pointer, that one didn't come up when I was googling. I thought the whole list might be interested. While this is out of scope of the RFC itself, how would you see this being implemented? Would you expect for the RIR's and IANA to create a global policy and assign ULA-C via the RIR system or are you envisioning another way? If we assume the RIRs would be handling ULA-C, then I have a question about the third paragraph in section 3.2. Global ID. It states; The allocation and registration authority should permit allocations to be obtained without having any sort of Internet connectivity and must include the ability to make an allocation on a permanent basis, without any need for renewal. The registration authority may covers its costs through registration fees and may also use registration agreements to clearly set forth the terms conditions and liabilities associated with registration of such allocations. The payments and conditions associated with this function should not be unreasonably onerous to the extent that the availability of allocations is impaired. Do you believe it would be consistent with this paragraph, if ARIN were to follow business practices for ULA-C similar to those used currently for an end-user assignments, charging a one-time fee covering its cost for the assignment activity and then an annual fee for maintaining a Organizational ID? I ask because, I believe a fee related to the Organizational ID is an important mechanism to insure ongoing active business contact between ARIN and the assignee. I believe such ongoing active business contact is essential for maintaining the long-term accuracy of the records associated with an assignment. Personally, I don't believe this language is intended to prevent such a model. However, I could see where some people might interpret this language as not allowing that model. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From jeffc at surbl.org Thu Mar 18 11:20:44 2010 From: jeffc at surbl.org (Jeff Chan) Date: Thu, 18 Mar 2010 08:20:44 -0700 Subject: [arin-ppml] Comments on Draft Policy 2010-3: Customer Confidentiality Message-ID: <1072932608.20100318082044@surbl.org> Here are my comments on "Draft Policy 2010-3: Customer Confidentiality": https://www.arin.net/policy/proposals/2010_3.html Privacy and transparency are both worthy and sometimes contradictory goals. Current ARIN policies on network registrations strike a good balance between the two. They should not be changed. In particular, registrations of residential networks are not required to reveal personal names or home addresses, and this seems appropriate. Reference: https://www.arin.net/policy/nrpm.html#four2376 The proposed new policy would allow ISPs to withhold providing some of the contact information for business customers. Businesses are already public entities, so this change seems unnecessary and possibly counterproductive. The main benefit would appear to be in not exposing ISP customer lists, however a practical effect would be to require a court order to ARIN to discover the business user of an IP address. Such restrictions could severely hamper private operations that significantly help to secure the Internet, such as security research, botnet and malware mitigation, notification about cracked servers and networks, etc. By slowing down access to contact information, indeed severely restricting access to it, routine actions which today help protect the Internet community could be severely obstructed to the point of preventing them from happening in many cases. Therefore I oppose the proposed new policy. ARIN should instead focus effort on improving the quality of registration data. Too often, registration data are out of date, fraudulent or otherwise inaccurate. Providing inaccurate contact information is a disservice to the community. Sincerely, Jeff Chan Please note that I am commenting as a concerned individual and not on behalf of an organization, but I believe the views above are widely held by many in the security and anti-abuse communities. -- Jeff Chan mailto:jeffc at surbl.org http://www.surbl.org/ From cengel at sponsordirect.com Thu Mar 18 13:55:22 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Thu, 18 Mar 2010 13:55:22 -0400 Subject: [arin-ppml] Comments on Draft Policy 2010-3 In-Reply-To: Message-ID: As a corporate end user of IP Address space, I appreciate the sentiments for Customer Confidentiality both on the part of protecting the IP's interests (in protecting it's customer lists) and on the part the organization holding the address space in maintaining some level of privacy. However, I think the draft probably is deficient in it's current form. There have been many arguements put forward as to why having that information availble is useful for legitimate purposes. However said information is just as useful for illegitimate or malicious use. Yes, the information can be used by white-hats to help profile networks where malicious attacks are being launched from..... but the very same information can be used by black-hats to profile a target organization for attack. It has been pointed out to me previously that such use would be a violation of WHOIS acceptable use policy....but I have yet to hear or see a single actual example of enforcement of that policy upon a violator...can anyone point me toward one? Nor do I see how, under current usage (anonymous lookup for anyone) such a policy COULD practicaly be enforced. As some-one who has had a small bit of experience in IT security (I don't claim to be an expert by any stretch of the imagination).... I do know one basic truism... A policy that cannot be or is not practicaly enforced may as well not exist... except, perhaps, as a fig leaf for an organizations lawyers. Ultimately, I would like to see a system whereby the holder (not ISP) of an IP address block can designate a responsible AGENT.... Any Agent (could be the ISP or not) to ACT as a point of contact for ALL WHOIS information (including Name). I think you'd actualy see better results in terms of voluntary compliance with providing information...as well as responsiveness to technical issues... if this option existed for organizations. It's NOT an unreasonable request for an address holder to want to designate some-one to act as a Gatekeeper for thier information... to require a requester of said information to at least divulge WHO they are and WHY they legitimately want the information in return for recieving said information. Allowing an agent to act as Gatekeeper CAN achieve that. Many organizations may not care or bother with that...but some legitimately will. I think in practical terms you MAY see better responsiveness among contacts if you allow for this. Essentialy if you call my organizations publicaly listed number for an urgent technical matter on 2:00 AM on a Saturday...you won't get ANY response until 9:00 AM on Monday. I'm not going to list my cell phone numbers or any of the ones belonging to people who work for me on a public registry so that some guy can wake me up in the middle of the night to try to sell me hosting space in Hong Kong...and I expect many small organizations (without 24/7/365 NOC's) won't either. However, I'm perfectly willing to provide such emergency contact info along with an escalation list to a responsible Agent who can act intelligently to verify the identity of the entity requesting such information and justify the legitimate NEED for it, BEFORE handing it out. For other purposes...it's not like you wouldn't be able to find out which address block a particular IP address belonged to for the purposes of filtering the block.... and for malicious organizations that were seeking to shield thier identities in order escape from legal consequences (like they'd list thier legitimate contact info in WHOIS anyway)....you STILL have a listed entity to point your lawyers at...the Agent (if they won't cough up the info when requested)....and you could probably claim the cost and delay in obtaining the correct information as part of your damages.... so where is the problem? Christopher Engel From joe at oregon.uoregon.edu Thu Mar 18 14:24:53 2010 From: joe at oregon.uoregon.edu (Joe St Sauver) Date: Thu, 18 Mar 2010 11:24:53 -0700 (PDT) Subject: [arin-ppml] Comments on Draft Policy 2010-3 Message-ID: <10031811245293_21B4C@oregon.uoregon.edu> Chris Engel commented: #It has been pointed out to me previously that such use would be a #violation of WHOIS acceptable use policy....but I have yet to hear or #see a single actual example of enforcement of that policy upon a #violator...can anyone point me toward one? Nor do I see how, under #current usage (anonymous lookup for anyone) such a policy COULD #practicaly be enforced. Zone files obviously have far different contents than whois servers, but the topic of access policy enforcement came up during recent ICANN Zone File Access Advisory Group discussions (e.g., see my post at http://mm.icann.org/pipermail/zfa-ag/2010-January/000069.html ) Since authentication and access control requirements drive a major part of the complexity underlying zone file data access provisioning, -- IF authentication and access control *isn't* serving any demonstrably useful purpose (e.g., usage isn't somehow being closely monitored, and users with "unacceptable" usage aren't having their access revoked), -- THEN copies of zone files could potentially simply be rolled out onto an FTP server or web server (like any other data file) rather than requiring users to first "jump through the hoops" of applying for access, being granted access, and then using personalized credentials to actually retrieve copies of the zone files. I think it is unlikely that this would actually ever happen, but this issue of unenforced policies driving potentially unscalable complexity is a real one that the community should be paying attention to. With respect to anonymous access to whois servers, I believe the only policy enforcement mechanisms I've seen discussed or deployed for traditional whois server access has been query rate limiting (or out-and-out access blocking) on an IP-by-IP basis, a strategy of limited eficacy in an era where addresses are assigned by DHCP with short lease times (and the use of proxy anonymization services is common). The situation for web based whois is somewhat more flexible, and deployment of cookies and/or captchas to (somewhat) limit automated access are the primary additional (albeit imperfect) "protections" used in an effort to track and improve the security of that access channel. #For other purposes...it's not like you wouldn't be able to find out #which address block a particular IP address belonged to for the purposes #of filtering the block.... When it comes to managing abuse, the issue is not mapping an indvidual IP to its encompassing network block -- I agree that this would continue to be possible under draft policy 2010-3. Unfortunately the abuse management issue is actually a three step process: -- mapping an individual IP to the ultimately responsible *entity* (the end user/customer), AND -- identifying the full set of *additional* network resources that abusive entity may *also* control ("generalizing reputation"), AND then -- applying appropriate sanctions (whether technical in nature, such as blocklisting applicable network ranges, or administrative in nature (civil suits or criminal enforcement, etc.)). The second and third steps become difficult to accomplish without the ability to successfully complete the first step. #(like they'd list thier legitimate contact info in WHOIS anyway).... The dismal state of whois accuracy (for domains) is well known, and has been confirmed by things like the recent ICANN whois accuracy study (still open for public comments, BTW, through April 15th, see http://www.icann.org/en/announcements/announcement-3-15feb10-en.htm ). If you'd like to see stronger verification of domain whois point of contact information, I would urge you to express that comment to ICANN during the comment period. With respect to *IP* whois point of contact validity, given the adoption by ARIN of 2008-7 ( https://www.arin.net/policy/proposals/2008_7.html ) one might hope that the quality and validity of ARIN IP whois point of contact data might improve over time, however the results listed at https://www.arin.net/resources/request/whois_cleanup.html (an effort listed as "complete" on that page) aren't very encouraging: 29,929 point of contact confirmation notices sent 1,854 bounced messages 1,192 responses received That is, 1,192/29,929*100=3.9% of all points of contact have been validated at this point. That leaves a substantial volume of IP whois point of contact addresses in an uncertain/unknown status, addresses which are unlikely to be reliably usable for critical operational notifications or other appropriate purposes. As IPv4 exhaustion increases the value of number assets, I hope additional organizational attention can be devoted to insuring that more than 3.9% of IP whois point of contact data is correct/usable. Regards, Joe St Sauver, Ph.D. Disclaimer: the opinions express do not necessarily reflect the opinion of any other organization or entity. From owen at delong.com Thu Mar 18 17:15:24 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 18 Mar 2010 14:15:24 -0700 Subject: [arin-ppml] ULA, GUA, NCN and the potential for abuse Message-ID: ULA - Unique Local Addresses GUA - Globally Unique Addresses NCN - Non-Connected Networks I'm seeing a lot of confusion and consternation about policy for these different things. Part of this comes from the fact that there are several perspectives on the issue which are not entirely compatible. There are people who legitimately want addresses for non-connected networks. In some of these cases, assigning global unicast space is a fine solution, but, in some cases, there is actually a (political/administrative/policy/human factors) reason to want space which is actually well-known to be "non-routable" on the global internet. Some of the people who feel the need for globally unique addresses for their NCN would like to get them from ARIN, but, see the current policies as a significant barrier. Part of it comes from the (erroneous) perspective that receiving a prefix from ARIN entitles you to a slot in the "Global Routing Table". This perspective creates a certain amount of fear about over-allocation/over-assignment leading to an unsustainable level of growth in the routing table. I think a unified solution is possible. The following steps would be required: 1. Reduce the criteria for getting Global IPv6 Unicast space to the minimum set of justified need and remove the artificial barriers created to prevent routing table growth from address assignment policy. 2. Create a pool of Global IPv6 Unicast space that can be issued to applicants that believe they need space which is regarded as "non-routable" by community convention. 3. Maintain the same qualification and assignment criteria for both groups of IPv6 unicast addresses. Do not differentiate them at the fee structure, either. 4. Leave the determination of what actually makes it into a routing table up to those who run routers and remove it entirely from ARIN policy. By doing this, we can meet the needs of non-connected networks that require globally unique addresses and the needs of networks that require globally unique addresses which are known by convention to be "unroutable" as well as the more generic needs of networks that are attached to the internet. It prevents abuse of "unroutable" addresses in the routing system because there is no advantage to this form of abuse if the policies and fee structures remain identical. Growth of the routing table is limited to legitimate demand and ISPs remain free to reject routes which do not meet their criteria. Owen (Speaking only for himself) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cengel at sponsordirect.com Thu Mar 18 17:27:58 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Thu, 18 Mar 2010 17:27:58 -0400 Subject: [arin-ppml] Comments on Draft Policy 2010-3 In-Reply-To: <10031811245293_21B4C@oregon.uoregon.edu> Message-ID: Joe St Sauver wrote: #When it comes to managing abuse, the issue is not mapping an indvidual IP #to its encompassing network block -- I agree that this would continue to be possible under #draft policy 2010-3. #Unfortunately the abuse management issue is actually a three step process: #-- mapping an individual IP to the ultimately responsible *entity* (the end user/customer), AND #-- identifying the full set of *additional* network resources that abusive entity may *also* control ("generalizing reputation"), AND then #-- applying appropriate sanctions (whether technical in nature, such as blocklisting applicable network ranges, or administrative in nature (civil suits or criminal enforcement, etc.)). #The second and third steps become difficult to accomplish without the ability to successfully #complete the first step. .... # As IPv4 exhaustion increases the value of number assets, I hope # additional organizational attention can be devoted to insuring that # more than 3.9% of IP whois point of contact data is correct/usable. Joe, I'm not sure how many resources ARIN or any registry can afford or is willing to devote to audit & enforcement efforts for the accuracy of such information. I can imagine that even a very cursorary audit/enforcement effort will be a very resource intensive undertaking....and such an effort won't catch anyone seeking to obfuscate thier identity for malicious reasons if they are halfway smart about it. You would need a pretty streneous effort to do that. Let's say you do probably the most cost effective thing and send out an e-mail to the contact e-mail address provided.... and if you don't get a response from that entity after X number of tries without a response you put them on some sort of RBL. So how does knowing that SOMEONE responds to the e-mail address slipperymonkey at gmail.com get you any closer to getting the REAL identity of someone you can bring to Court (your step #3). How does that help you know that 123 Anywhwere Street is a real street address.... or that the entity owning address block A - ACME Export, inc (contact slippermonkey at gmail.com) and the entity owning address block B - Vanderlay, Industries (contact shadymoose at hotmail.com) are ACTUALY the same entity (what you need to block access to them...your Step #2)? For that you'd pretty much need to goto the ISP anyway to find out who signs the checks/credit cards for that block....which probably means going to the Courts. Given that, it leaves the discussion centered on the block holders who AREN'T actualy malicious but who may be causing a problem inadvertantly. I'm pretty sure those people aren't going to have any issues giving out contact info to people who have a LEGITIMATE need for it (e.g. one of your IP's is flooding my network with SPAM). The problem is...under the current mechanism (anonymous WHOIS lookups) they have no means to differentiate people with a legitimate need for that info from the malicious folks themselves. I'd have no problem giving out an after-hours call sheet or an escalation document to YOU...if one of my IP's happaned to be SPAM bombing you and you needed to contact me in order to get it stopped. Under WHOIS...how do I tell the difference between YOU and the guy who wants that info so that he can wake me up at 2:00 AM to sell me server space in Hong Kong? I believe you are likely to get BETTER quality data if you actualy allow people some control over who USES that data and HOW. I don't think it's an unreasonable demand for people these days to request some controls/tracking over who gets thier information and why. Right now, I don't see how WHOIS addresses that. Which means you aren't likely to VOLUNTARLY get any better info then organizations would be willing for the hackers/scammers/spammers get.... and INVOLUNTARY compliance is both expensive in terms of resources and earns ALOT of negative political capital. That's how I see it anyways. Christopher Engel From mpetach at netflight.com Thu Mar 18 19:13:55 2010 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 18 Mar 2010 16:13:55 -0700 Subject: [arin-ppml] ULA, GUA, NCN and the potential for abuse In-Reply-To: References: Message-ID: <63ac96a51003181613u71919f96lf2e5ad6c3534896c@mail.gmail.com> On Thu, Mar 18, 2010 at 2:15 PM, Owen DeLong wrote: > ULA - Unique Local Addresses > GUA - Globally Unique Addresses > NCN - Non-Connected Networks > I'm seeing a lot of confusion and consternation about policy for these > different > things. > Part of this comes from the fact that there are several perspectives on the > issue > which are not entirely compatible. ?There are people who legitimately want > addresses for non-connected networks. In some of these cases, assigning > global unicast space is a fine solution, but, in some cases, there is > actually > a (political/administrative/policy/human factors) reason to want space which > is actually well-known to be "non-routable" on the global internet. > Some of the people who feel the need for globally unique addresses for > their NCN would like to get them from ARIN, but, see the current policies > as a significant barrier. > Part of it comes from the (erroneous) perspective that receiving a prefix > from > ARIN entitles you to a slot in the "Global Routing Table". ?This perspective > creates a certain amount of fear about over-allocation/over-assignment > leading to an unsustainable level of growth in the routing table. > I think a unified solution is possible. The following steps would be > required: > 1. Reduce the criteria for getting Global IPv6 Unicast space to the > minimum set of justified need and remove the artificial barriers > created to prevent routing table growth from address assignment > policy. > 2. Create a pool of Global IPv6 Unicast space that can be issued to > applicants that believe they need space which is regarded as > "non-routable" by community convention. > 3. Maintain the same qualification and assignment criteria for both > groups of IPv6 unicast addresses. Do not differentiate them at > the fee structure, either. I think this is going to be the biggest stumbling point. Today, there's no fee for a private organization to use RFC1918 addresses internally. If they're building a massive internal test network, and use most of 10/8 to do it, but only need a /29 from their upstream ISP for minimal external connectivity, they don't pay ARIN for the ability to use 10/8 internally. In your model, the network would now have to pay annual ARIN fees to use IPv6 addresses internally, *even* if they are never using them on the global internet. I think the only way this model is going to work is if non-routed prefix blocks are fee-exempt and are designated as martian blocks, to be filtered by ISPs. Otherwise, people are going to decide that if they have to shell out an annual fee for getting legitimate space, they might as well just stake out a chunk of space and not tell anyone they're using it; and at that point, we'll be back to the jungle of every internal private network just picking a random range to squat on. > 4. Leave the determination of what actually makes it into a routing > table up to those who run routers and remove it entirely from > ARIN policy. > By doing this, we can meet the needs of non-connected networks that > require globally unique addresses and the needs of networks that > require globally unique addresses which are known by convention > to be "unroutable" as well as the more generic needs of networks > that are attached to the internet. ?It prevents abuse of "unroutable" > addresses in the routing system because there is no advantage > to this form of abuse if the policies and fee structures remain > identical. Growth of the routing table is limited to legitimate > demand and ISPs remain free to reject routes which do not meet > their criteria. I would argue just the reverse; it's likely to increase the likelihood of abuse of unroutable addresses, because a company that's paying for a block of addresses for internal use is likely to feel *more* justified in just announcing it out one day, because hell, they've been paying the 'real' address fee for it the whole time already. The existence of the fee structure for the addresses legitimizes their 'real' nature, and is likely to grease the slippery slope towards eventual announcement into the global table. > Owen > (Speaking only for himself) And, just so it's clear, I support the rest of your effort, and think it's a good idea; I simply think that your 'same fee as for real blocks' clause will end up elevating these blocks to the same status in the eyes of many of the enterprise companies that end up paying for the space year after year. ^_^; Matt From leo.vegoda at icann.org Thu Mar 18 19:34:30 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 18 Mar 2010 16:34:30 -0700 Subject: [arin-ppml] ULA, GUA, NCN and the potential for abuse In-Reply-To: <63ac96a51003181613u71919f96lf2e5ad6c3534896c@mail.gmail.com> References: <63ac96a51003181613u71919f96lf2e5ad6c3534896c@mail.gmail.com> Message-ID: On 18 Mar 2010, at 4:13, Matthew Petach wrote: [...] >> 3. Maintain the same qualification and assignment criteria for both >> groups of IPv6 unicast addresses. Do not differentiate them at >> the fee structure, either. > > I think this is going to be the biggest stumbling point. > > Today, there's no fee for a private organization to use > RFC1918 addresses internally. If they're building > a massive internal test network, and use most of 10/8 > to do it, but only need a /29 from their upstream ISP > for minimal external connectivity, they don't pay ARIN > for the ability to use 10/8 internally. > > In your model, the network would now have to pay > annual ARIN fees to use IPv6 addresses internally, > *even* if they are never using them on the global > internet. Assuming this proposal is accepted, they would only have to do this if they were unwilling to use a /48 from the unique local space already set aside in RFC 4193. If RFC 1918 address space is good enough in IPv4 I find it hard to understand why RFC 4193 space would not be good enough in IPv6. RFC 4193 is far, far less likely to suffer from any address clash problems and is very unlikely to ever be routed across the Internet. I can't help but think that the number of people who use RFC 1918 space now instead of requesting unique addresses but would not be happy with RFC 4193 for a similar private network is going to be quite small. While such cases might exist, people with special needs generally understand that their needs are special and understand what that means. If it means paying a registration fee of some kind then presumably that would be acceptable to most people if it gave them the guarantee they were after. Regards, Leo Vegoda From mpetach at netflight.com Thu Mar 18 19:44:39 2010 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 18 Mar 2010 16:44:39 -0700 Subject: [arin-ppml] ULA, GUA, NCN and the potential for abuse In-Reply-To: References: <63ac96a51003181613u71919f96lf2e5ad6c3534896c@mail.gmail.com> Message-ID: <63ac96a51003181644i794fec86r4ce68829b670f71b@mail.gmail.com> On Thu, Mar 18, 2010 at 4:34 PM, Leo Vegoda wrote: > On 18 Mar 2010, at 4:13, Matthew Petach wrote: > > [...] > >>> 3. Maintain the same qualification and assignment criteria for both >>> groups of IPv6 unicast addresses. Do not differentiate them at >>> the fee structure, either. >> >> I think this is going to be the biggest stumbling point. >> >> Today, there's no fee for a private organization to use >> RFC1918 addresses internally. ?If they're building >> a massive internal test network, and use most of 10/8 >> to do it, but only need a /29 from their upstream ISP >> for minimal external connectivity, they don't pay ARIN >> for the ability to use 10/8 internally. >> >> In your model, the network would now have to pay >> annual ARIN fees to use IPv6 addresses internally, >> *even* if they are never using them on the global >> internet. > > Assuming this proposal is accepted, they would only have to do this if they were unwilling to use a /48 from the unique local space already set aside in RFC 4193. If RFC 1918 address space is good enough in IPv4 I find it hard to understand why RFC 4193 space would not be good enough in IPv6. RFC 4193 is far, far less likely to suffer from any address clash problems and is very unlikely to ever be routed across the Internet. > Unless I misunderstood Owen's opening paragraphs, it sounded to me as though he's putting this grand unified address allocation idea forth in order to incorporate all v6 allocations, including the ULA addresses mentioned in RFC4193. > I can't help but think that the number of people who use RFC 1918 space now instead of requesting unique addresses but would not be happy with RFC 4193 for a similar private network is going to be quite small. While such cases might exist, people with special needs generally understand that their needs are special and understand what that means. If it means paying a registration fee of some kind then presumably that would be acceptable to most people if it gave them the guarantee they were after. > If this is *not* subsuming RFC4193, but would be a parallel track as an alternative to RFC4193 addresses, then yes, I quite agree. Owen, can you clarify whether you intended this to be an umbrella which also applied to unique local addresses as defined in RFC 4193, or as a a parallel source of addresses separate from RFC4193? > Regards, > Leo Vegoda Thanks! Matt From owen at delong.com Thu Mar 18 23:54:06 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 18 Mar 2010 20:54:06 -0700 Subject: [arin-ppml] ULA, GUA, NCN and the potential for abuse In-Reply-To: References: <63ac96a51003181613u71919f96lf2e5ad6c3534896c@mail.gmail.com> Message-ID: On Mar 18, 2010, at 4:34 PM, Leo Vegoda wrote: > On 18 Mar 2010, at 4:13, Matthew Petach wrote: > > [...] > >>> 3. Maintain the same qualification and assignment criteria for both >>> groups of IPv6 unicast addresses. Do not differentiate them at >>> the fee structure, either. >> >> I think this is going to be the biggest stumbling point. >> >> Today, there's no fee for a private organization to use >> RFC1918 addresses internally. If they're building >> a massive internal test network, and use most of 10/8 >> to do it, but only need a /29 from their upstream ISP >> for minimal external connectivity, they don't pay ARIN >> for the ability to use 10/8 internally. >> >> In your model, the network would now have to pay >> annual ARIN fees to use IPv6 addresses internally, >> *even* if they are never using them on the global >> internet. > > Assuming this proposal is accepted, they would only have to do this if they were unwilling to use a /48 from the unique local space already set aside in RFC 4193. If RFC 1918 address space is good enough in IPv4 I find it hard to understand why RFC 4193 space would not be good enough in IPv6. RFC 4193 is far, far less likely to suffer from any address clash problems and is very unlikely to ever be routed across the Internet. > RFC-1918 is, in most cases, a barely tolerated necessary evil. As to the likelihood of RFC-4193 being routed, if it is centrally registered and has guaranteed uniqueness, then, if RIR policies are regarded as overly restrictive, it is not at all unlikely it will get used as routable address space at least within some meaningful portion of the internet. > I can't help but think that the number of people who use RFC 1918 space now instead of requesting unique addresses but would not be happy with RFC 4193 for a similar private network is going to be quite small. While such cases might exist, people with special needs generally understand that their needs are special and understand what that means. If it means paying a registration fee of some kind then presumably that would be acceptable to most people if it gave them the guarantee they were after. > ULA (RFC-4193) was, IMHO, an IETF hack to get around the lack of good RIR policy in this area. If we solve the problem more generically at the RIR level as I have proposed, then, networks that believe they do not need to connect to the internet now, but, may need to connect later would be free to use valid global unicast space for that purpose and be able to change the connectedness of their network when that was desired. Those that need space labeled as "non-routable" by accepted convention, OTOH, would be able to get such space. This would primarily be to satisfy audit and/or other political requirements such as PCI. Owen From owen at delong.com Fri Mar 19 00:03:38 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 18 Mar 2010 21:03:38 -0700 Subject: [arin-ppml] ULA, GUA, NCN and the potential for abuse In-Reply-To: <63ac96a51003181644i794fec86r4ce68829b670f71b@mail.gmail.com> References: <63ac96a51003181613u71919f96lf2e5ad6c3534896c@mail.gmail.com> <63ac96a51003181644i794fec86r4ce68829b670f71b@mail.gmail.com> Message-ID: <955D83FF-7A7C-49E5-9A8C-90C296859CC9@delong.com> On Mar 18, 2010, at 4:44 PM, Matthew Petach wrote: > On Thu, Mar 18, 2010 at 4:34 PM, Leo Vegoda wrote: >> On 18 Mar 2010, at 4:13, Matthew Petach wrote: >> >> [...] >> >>>> 3. Maintain the same qualification and assignment criteria for both >>>> groups of IPv6 unicast addresses. Do not differentiate them at >>>> the fee structure, either. >>> >>> I think this is going to be the biggest stumbling point. >>> >>> Today, there's no fee for a private organization to use >>> RFC1918 addresses internally. If they're building >>> a massive internal test network, and use most of 10/8 >>> to do it, but only need a /29 from their upstream ISP >>> for minimal external connectivity, they don't pay ARIN >>> for the ability to use 10/8 internally. >>> >>> In your model, the network would now have to pay >>> annual ARIN fees to use IPv6 addresses internally, >>> *even* if they are never using them on the global >>> internet. >> >> Assuming this proposal is accepted, they would only have to do this if they were unwilling to use a /48 from the unique local space already set aside in RFC 4193. If RFC 1918 address space is good enough in IPv4 I find it hard to understand why RFC 4193 space would not be good enough in IPv6. RFC 4193 is far, far less likely to suffer from any address clash problems and is very unlikely to ever be routed across the Internet. >> > > Unless I misunderstood Owen's opening paragraphs, it sounded > to me as though he's putting this grand unified address allocation > idea forth in order to incorporate all v6 allocations, including the > ULA addresses mentioned in RFC4193. > >> I can't help but think that the number of people who use RFC 1918 space now instead of requesting unique addresses but would not be happy with RFC 4193 for a similar private network is going to be quite small. While such cases might exist, people with special needs generally understand that their needs are special and understand what that means. If it means paying a registration fee of some kind then presumably that would be acceptable to most people if it gave them the guarantee they were after. >> > > If this is *not* subsuming RFC4193, but would be a parallel > track as an alternative to RFC4193 addresses, then yes, I > quite agree. > > Owen, can you clarify whether you intended this to be an > umbrella which also applied to unique local addresses > as defined in RFC 4193, or as a a parallel source of > addresses separate from RFC4193? I'm open to either mechanism of implementation. My concern is that RFC-4193 (ULA-RANDOM) has drawbacks in that it is merely statistically unique and not reliably unique. The process for determining your proper RFC-4193 addresses is complex enough that I suspect a high percentage of sites will approach it like RFC-1918 and choose the first available, last available, or, some other convenient to remember prefix. That sparse pseudo-random allocations will be far less common than envisioned by the RFC. Certainly, my opinion is that it makes more sense to supplant the deprecated (but possibly getting resurrected again) ULA-Central in favor of my proposal, but, I am not sure whether it should apply to ULA-Random. I think ULA random should either be deprecated entirely, or, left to rot as the morass that it may well be already. My key point is that if we stop assuming that RIR-issuance = routing table slot and provide for corespondingly more liberal policy at the RIR level, we can maintain good RIR stewardship of the address space while serving a much broader user community and removing the desire to create end-runs on RIR justification policies. The temptation to do an end-run comes from policies that are perceived as unnecessarily restrictive. To the extent possible, we should not be restrictive in our policies. My proposal allows us to be quite a bit less restrictive and support non-routed and routed addresses with common allocation/assignment policy. I'm not religious about what effect or relationship this action has on or to ULA. Owen From owen at delong.com Fri Mar 19 00:14:17 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 18 Mar 2010 21:14:17 -0700 Subject: [arin-ppml] ULA, GUA, NCN and the potential for abuse In-Reply-To: <63ac96a51003181613u71919f96lf2e5ad6c3534896c@mail.gmail.com> References: <63ac96a51003181613u71919f96lf2e5ad6c3534896c@mail.gmail.com> Message-ID: <2ADD829A-9EC4-4D26-98B6-5CB0FB40166D@delong.com> On Mar 18, 2010, at 4:13 PM, Matthew Petach wrote: > On Thu, Mar 18, 2010 at 2:15 PM, Owen DeLong wrote: >> ULA - Unique Local Addresses >> GUA - Globally Unique Addresses >> NCN - Non-Connected Networks >> I'm seeing a lot of confusion and consternation about policy for these >> different >> things. >> Part of this comes from the fact that there are several perspectives on the >> issue >> which are not entirely compatible. There are people who legitimately want >> addresses for non-connected networks. In some of these cases, assigning >> global unicast space is a fine solution, but, in some cases, there is >> actually >> a (political/administrative/policy/human factors) reason to want space which >> is actually well-known to be "non-routable" on the global internet. >> Some of the people who feel the need for globally unique addresses for >> their NCN would like to get them from ARIN, but, see the current policies >> as a significant barrier. >> Part of it comes from the (erroneous) perspective that receiving a prefix >> from >> ARIN entitles you to a slot in the "Global Routing Table". This perspective >> creates a certain amount of fear about over-allocation/over-assignment >> leading to an unsustainable level of growth in the routing table. >> I think a unified solution is possible. The following steps would be >> required: >> 1. Reduce the criteria for getting Global IPv6 Unicast space to the >> minimum set of justified need and remove the artificial barriers >> created to prevent routing table growth from address assignment >> policy. >> 2. Create a pool of Global IPv6 Unicast space that can be issued to >> applicants that believe they need space which is regarded as >> "non-routable" by community convention. >> 3. Maintain the same qualification and assignment criteria for both >> groups of IPv6 unicast addresses. Do not differentiate them at >> the fee structure, either. > > I think this is going to be the biggest stumbling point. > > Today, there's no fee for a private organization to use > RFC1918 addresses internally. If they're building > a massive internal test network, and use most of 10/8 > to do it, but only need a /29 from their upstream ISP > for minimal external connectivity, they don't pay ARIN > for the ability to use 10/8 internally. > It is not my intent to supplant RFC-1918 style ULA-Random addressing. I'm talking about the people who want globally unique (ULA-Central style) addressing which is currently NOT available anywhere at any cost in IPv6. There have been proposals for it in IETF but they have not yet gained any consensus. > In your model, the network would now have to pay > annual ARIN fees to use IPv6 addresses internally, > *even* if they are never using them on the global > internet. > Not at all. They would only need to pay if they want REGISTERED addresses. Sorry if this was not clear. No registration service, no registration fee. Simple. > I think the only way this model is going to work is > if non-routed prefix blocks are fee-exempt and are > designated as martian blocks, to be filtered by > ISPs. Otherwise, people are going to decide that > if they have to shell out an annual fee for getting > legitimate space, they might as well just stake > out a chunk of space and not tell anyone they're > using it; and at that point, we'll be back to the > jungle of every internal private network just picking > a random range to squat on. > There are two types of non-routed blocks. non-routed non-unique blocks should remain fee-free and their use should come with an appropriate disclaimer. non-routed guaranteed unique registered blocks should be registered just like routed blocks and should have the same policy and fee structure. >> 4. Leave the determination of what actually makes it into a routing >> table up to those who run routers and remove it entirely from >> ARIN policy. >> By doing this, we can meet the needs of non-connected networks that >> require globally unique addresses and the needs of networks that >> require globally unique addresses which are known by convention >> to be "unroutable" as well as the more generic needs of networks >> that are attached to the internet. It prevents abuse of "unroutable" >> addresses in the routing system because there is no advantage >> to this form of abuse if the policies and fee structures remain >> identical. Growth of the routing table is limited to legitimate >> demand and ISPs remain free to reject routes which do not meet >> their criteria. > > I would argue just the reverse; it's likely to increase the likelihood > of abuse of unroutable addresses, because a company that's > paying for a block of addresses for internal use is likely to feel > *more* justified in just announcing it out one day, because hell, > they've been paying the 'real' address fee for it the whole time > already. The existence of the fee structure for the addresses > legitimizes their 'real' nature, and is likely to grease the slippery > slope towards eventual announcement into the global table. > The thing is, that's not abuse, so long as they asked for a block that was not tagged as "not routable by convention". However, whether or not a service provider or the rest of the internet chooses to accept that route is now up to the people being asked to shoulder the burden of carrying the route instead of being limited to a decision made by ARIN in proxy. >> Owen >> (Speaking only for himself) > > And, just so it's clear, I support the rest of your effort, and think > it's a good idea; I simply think that your 'same fee as for real blocks' > clause will end up elevating these blocks to the same status in > the eyes of many of the enterprise companies that end up paying > for the space year after year. ^_^; > Hopefully with the clarification above, it makes more sense. Owen > Matt From mpetach at netflight.com Fri Mar 19 01:32:24 2010 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 18 Mar 2010 22:32:24 -0700 Subject: [arin-ppml] ULA, GUA, NCN and the potential for abuse In-Reply-To: <2ADD829A-9EC4-4D26-98B6-5CB0FB40166D@delong.com> References: <63ac96a51003181613u71919f96lf2e5ad6c3534896c@mail.gmail.com> <2ADD829A-9EC4-4D26-98B6-5CB0FB40166D@delong.com> Message-ID: <63ac96a51003182232y540d88cbn65874b74a9bb7bff@mail.gmail.com> On Thu, Mar 18, 2010 at 9:14 PM, Owen DeLong wrote: > On Mar 18, 2010, at 4:13 PM, Matthew Petach wrote: >> On Thu, Mar 18, 2010 at 2:15 PM, Owen DeLong wrote: >>> ULA - Unique Local Addresses >>> GUA - Globally Unique Addresses >>> NCN - Non-Connected Networks ... > It is not my intent to supplant RFC-1918 style ULA-Random > addressing. ?I'm talking about the people who want > globally unique (ULA-Central style) addressing which is > currently NOT available anywhere at any cost in IPv6. > There have been proposals for it in IETF but they have not > yet gained any consensus. > >> In your model, the network would now have to pay >> annual ARIN fees to use IPv6 addresses internally, >> *even* if they are never using them on the global >> internet. >> > Not at all. ?They would only need to pay if they want > REGISTERED addresses. ?Sorry if this was not clear. > No registration service, no registration fee. Simple. ... > There are two types of non-routed blocks. > > non-routed non-unique blocks should remain fee-free and > their use should come with an appropriate disclaimer. > > non-routed guaranteed unique registered blocks should be > registered just like routed blocks and should have the same > policy and fee structure. ... >> And, just so it's clear, I support the rest of your effort, and think >> it's a good idea; I simply think that your 'same fee as for real blocks' >> clause will end up elevating these blocks to the same status in >> the eyes of many of the enterprise companies that end up paying >> for the space year after year. ?^_^; >> > Hopefully with the clarification above, it makes more sense. Definitely--with the clarification that non-registered, RFC1493 'statistically unique' non-routed address blocks are still free and are not covered by this, then yes, I think unifying the structure makes considerable sense--that removes my only concern/objection to the proposal. > Owen Thanks again for the clarification! Matt From michael.dillon at bt.com Fri Mar 19 06:26:37 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 19 Mar 2010 10:26:37 -0000 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BA24712.3090903@umn.edu> Message-ID: <28E139F46D45AF49A31950F88C497458058E1B06@E03MVZ2-UKDY.domain1.systemhost.net> > If we assume the RIRs would be handling ULA-C, then I have a > question about the third paragraph in section 3.2. Global ID. > It states; > > The allocation and registration authority should permit > allocations > to be obtained without having any sort of Internet > connectivity and > must include the ability to make an allocation on a > permanent basis, > without any need for renewal. The registration authority > may covers > its costs through registration fees and may also use registration > agreements to clearly set forth the terms conditions and > liabilities > associated with registration of such allocations. The > payments and > conditions associated with this function should not be > unreasonably > onerous to the extent that the availability of allocations is > impaired. > > Do you believe it would be consistent with this paragraph, if > ARIN were to follow business practices for ULA-C similar to > those used currently for an end-user assignments, charging a > one-time fee covering its cost for the assignment activity > and then an annual fee for maintaining a Organizational ID? I think that we should go ahead with allocating a /8 for ULA-C addresses without any significant technical changes to this Internet draft However, there could be some changes to clarify who does what, etc. I believe that the ULA-C registry should be based around a tool similar to the one operated by SIXXS for the regular ULA addresses. This tool should be hosted by more than one RIR, perhaps since RIPE and ARIN are the senior RIRs then they should both host the tool. It would have to be based on a distributed datastore, but with all the recent developments in the NoSQL field, this should be simply a matter of picking the right db software and implementing it. Essentially, the tool just generates a pseudo-random /48 block, checks to make sure it is not already in the database, and if so, tries again until it gets a free one. The /48 is then registered with the customer and RIR info that was entered. Procedurally, each RIR would have a login to this allocation tool, and after signing a customer agreement and collecting payment for the service, they would enter all the info into the tool, a /48 would pop out, and they would record that number and pass it on to the customer. A customer can ask for as many /48s as they want, but they pay each time and NO DISCOUNTING IS ALLOWED. Full price only except for the very first allocation to customers in an RIR that has implemented a special price category. This allows RIRs to service customers in economically depressed areas in a reasonable way. As for whois, none of these numbers would be recorded in the RIR whois directories. However, each RIR should operate an instance of the ULA-C directory lookup tool which will query single /48 blocks from the allocation tool's database. This should not pose any serious problems to anyone, since the entire ULA-C block will be listed in bogon lists. The only time you should see someone else's ULA-C block on your network is when you have a direct business partnership and a direct connection to the other organization. Potentially, ULA-C blocks could seem useful to COIN (Community Of INterest) internetworks, but in practice the costs would be higher than necessary, and the impossiblility of prefix aggregation only causes operational problems. I expect that a COIN will simply register a /32 and assign from that much like any other ISP. However, it is quite possible that a small scale COIN will simply require all members to use a ULA-C block because a small COIN is pretty much the same scale as a two-party private extranet connection. And a two-party private extranet is identical, from a technology viewpoint, to an M&A scenario where two organizations begin to merge their networks. I would encourage ARIN and RIPE folks to work on a global policy for ULA-C that assumes IETF approval of a ULA-C RFC. Then, once we have the global policy, I believe that the IETF will approve a ULA-C RFC that creates ULA-C addresses. --Michael Dillon From michael.dillon at bt.com Fri Mar 19 06:33:55 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 19 Mar 2010 10:33:55 -0000 Subject: [arin-ppml] ULA, GUA, NCN and the potential for abuse In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458058E1B23@E03MVZ2-UKDY.domain1.systemhost.net> > I can't help but think that the number of people who use RFC > 1918 space now instead of requesting unique addresses but > would not be happy with RFC 4193 for a similar private > network is going to be quite small. It only takes one person disatisfied with RFC 4193, to make this disatisfaction into a majority view. If that one person is a technical magazine columnist, their views can be very quickly adopted by a huge number of techies who all have technical decision making power at their companies. You may moan about how these people are all technically wrong, but the fact is that the technical community today is huge, and 99% of them don't know much about the IETF other than the fact that RFCs are the law unless a vendor says otherwise. If people have no choice, they tend to attack those imposing no choice. I say we should create ULA-C to give them a choice, because that way, there will be less heat and light wasted. --Michael Dillon From mcr at sandelman.ca Fri Mar 19 10:20:34 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 19 Mar 2010 10:20:34 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <28E139F46D45AF49A31950F88C497458058E1B06@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458058E1B06@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <7848.1269008434@marajade.sandelman.ca> >>>>> "michael" == michael dillon writes: michael> I think that we should go ahead with allocating a /8 for michael> ULA-C addresses without any significant technical changes michael> to this Internet draft michael> michael> However, there could be some changes to clarify who does michael> what, etc. Very good analysis. I'm on board! michael> As for whois, none of these numbers would be recorded in michael> the RIR whois directories. However, each RIR should operate michael> an instance of the ULA-C directory lookup tool which will michael> query single /48 blocks from the allocation tool's michael> database. This should not pose any serious problems to Are you saying that when I do a whois on this ULA-C, that the server will go do that query for me? michael> Potentially, ULA-C blocks could seem useful to COIN michael> (Community Of INterest) internetworks, but in practice the michael> costs would be higher than necessary, and the michael> impossiblility of prefix aggregation only causes michael> operational problems. I expect that a COIN will simply michael> register a /32 and assign from that much like any other michael> ISP. However, it is quite possible that a small scale COIN michael> will simply require all members to use a ULA-C block michael> because a small COIN is pretty much the same scale as a michael> two-party private extranet connection. And a two-party michael> private extranet is identical, from a technology viewpoint, michael> to an M&A scenario where two organizations begin to merge michael> their networks. I agree with you. michael> I would encourage ARIN and RIPE folks to work on a global michael> policy for ULA-C that assumes IETF approval of a ULA-C michael> RFC. Then, once we have the global policy, I believe that michael> the IETF will approve a ULA-C RFC that creates ULA-C michael> addresses. The communications I have had say that the IETF is waiting for the RIRs to tell them what they need. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From owen at delong.com Fri Mar 19 11:37:42 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 19 Mar 2010 08:37:42 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <7848.1269008434@marajade.sandelman.ca> References: <28E139F46D45AF49A31950F88C497458058E1B06@E03MVZ2-UKDY.domain1.systemhost.net> <7848.1269008434@marajade.sandelman.ca> Message-ID: <6019944A-E573-430E-B619-A71899F73082@delong.com> On Mar 19, 2010, at 7:20 AM, Michael Richardson wrote: > >>>>>> "michael" == michael dillon writes: > michael> I think that we should go ahead with allocating a /8 for > michael> ULA-C addresses without any significant technical changes > michael> to this Internet draft > michael> > > michael> However, there could be some changes to clarify who does > michael> what, etc. > > Very good analysis. I'm on board! > Making ULA-C available on the terms specified in the referenced draft is an invitation to massive abuse. That was the whole point of my ULA, GLA, NCN, and the potential for abuse post. > michael> As for whois, none of these numbers would be recorded in > michael> the RIR whois directories. However, each RIR should operate > michael> an instance of the ULA-C directory lookup tool which will > michael> query single /48 blocks from the allocation tool's > michael> database. This should not pose any serious problems to > > Are you saying that when I do a whois on this ULA-C, that the server > will go do that query for me? > Quite the opposite, actually. > > michael> I would encourage ARIN and RIPE folks to work on a global > michael> policy for ULA-C that assumes IETF approval of a ULA-C > michael> RFC. Then, once we have the global policy, I believe that > michael> the IETF will approve a ULA-C RFC that creates ULA-C > michael> addresses. > > The communications I have had say that the IETF is waiting for the RIRs > to tell them what they need. Interesting. Personally, I think that the RIRs have much work to do on policy to accommodate NCN and that it should be done through a unified set of policies which allow reasonable management of GUA to encompass ULA-C as essentially a community convention for indicating a network should not be globally routed and nothing more. To do this without creating a potential for abuse, what is needed is a much more relaxed GUA policy divorced from the idea that every GUA prefix issued will end up in the routing table. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Fri Mar 19 11:58:31 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 19 Mar 2010 15:58:31 -0000 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <7848.1269008434@marajade.sandelman.ca> Message-ID: <28E139F46D45AF49A31950F88C497458058E1EE2@E03MVZ2-UKDY.domain1.systemhost.net> > michael> As for whois, none of these numbers would be recorded in > michael> the RIR whois directories. However, each RIR > should operate > michael> an instance of the ULA-C directory lookup tool which will > michael> query single /48 blocks from the allocation tool's > michael> database. This should not pose any serious problems to > > Are you saying that when I do a whois on this ULA-C, that the > server will go do that query for me? Nope. When you do a whois on a ULA-C address, the server will send back something like this: Comment: These addresses are ULA-C addresses as defined in RFC 7777. Comment: These addresses are not intended for use on the public Comment: Internet and are not recorded in ARIN's whois directory. Comment: However you can query the ULA-C database at http://ula.arin.net Comment: Note that ULA-C addresses are assigned randomly. There is Comment: no need to check a specific address for availability and Comment: ARIN can *NOT* accomodate any requests for a specific block. Comment: More information is available at http://ula.arin.net Comment: and at http://www.cymru.com/Bogons/ipv6.txt Now when ARIN allocates fcf8:8f00:40ef::/48 to Thingamiggies Global Corp. and they go to Bill's Bait and Tackle Shop asking him to route this block, Bill looks up the whois directory just to be sure, and voila. The whois directory does *NOT* confirm that this block has indeed been assigned to Thingamajiggies, and it more or less tells Bill not to accept this route. This doesn't prevent Bill and his friends from plotting to disrupt the internets by actually routing traffic globally across their ASes using Thingamajiggies' ULA-C assignment, but then ARIN is not in the business of telling Bill and his friends what they can and can't do. ARIN just won't join the party and make their job easy. --Michael Dillon From stephen at sprunk.org Fri Mar 19 13:30:23 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 19 Mar 2010 12:30:23 -0500 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <28E139F46D45AF49A31950F88C497458058E1EE2@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458058E1EE2@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4BA3B4AF.7090806@sprunk.org> On 19 Mar 2010 10:58, michael.dillon at bt.com wrote: >>> As for whois, none of these numbers would be recorded in the RIR whois directories. However, each RIR should operate an instance of the ULA-C directory lookup tool which will query single /48 blocks from the allocation tool's database. This should not pose any serious problems to >> Are you saying that when I do a whois on this ULA-C, that the >> server will go do that query for me? > Nope. When you do a whois on a ULA-C address, the server will > send back something like this: > > Comment: These addresses are ULA-C addresses as defined in RFC 7777. > Comment: These addresses are not intended for use on the public > Comment: Internet and are not recorded in ARIN's whois directory. > Comment: However you can query the ULA-C database at > http://ula.arin.net > So, rather than putting them in WHOIS, which is supposed to be comprehensive, now the RIRs are going to have to operate a _second_ directory service which duplicates WHOIS's functionality but contains a different subset of records? That seems like a waste of time, effort, and money, since it doesn't really accomplish _anything_. If RIRs list ULA-C assignments in _any_ publicly-accessible database, customers can go to their ISP and say "My number is in $RIR's database, so you have to route it for me!" That is not good, because _many_ ISPs will listen to such arguments, and in a decade or less there will be no meaningful difference between the routability of ULA-Cs and GUAs. ULAs are _local_, i.e. not meant to be seen on the Internet. If individual orgs want to know which of their non-Internet peers is using, they can establish that via standard contractual means--or demand that their peers get GUAs. > Comment: Note that ULA-C addresses are assigned randomly. There is > Comment: no need to check a specific address for availability and > Comment: ARIN can *NOT* accomodate any requests for a specific block. > I don't see any point in including this information in WHOIS, nor is it all that different from how any other addresses are assigned by ARIN. > Comment: More information is available at http://ula.arin.net > Comment: and at http://www.cymru.com/Bogons/ipv6.txt > That'd be fine, except I don't approve of ARIN linking to external sites that are not officially part of the Internet governance community. The Cymru folks do good work, but official they are not. I still object to a ULA-C block in general, for a variety of reasons; my comments here are just to make sure that if we go down that path, we do it in the least-broken way possible. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From JOHN at egh.com Fri Mar 19 14:29:55 2010 From: JOHN at egh.com (John Santos) Date: Fri, 19 Mar 2010 14:29:55 -0400 Subject: [arin-ppml] IPv6 Non-connected networks Message-ID: <1100319142309.37820A-100000@Ives.egh.com> On 19 Mar 2010 stephen at sprunk.org wrote: > > On 19 Mar 2010 10:58, michael.dillon at bt.com wrote: > >>> As for whois, none of these numbers would be recorded in the RIR whoi= > s directories. However, each RIR should operate an instance of the ULA-C = > directory lookup tool which will query single /48 blocks from the allocat= > ion tool's database. This should not pose any serious problems to > >> Are you saying that when I do a whois on this ULA-C, that the=20 > >> server will go do that query for me? > > Nope. When you do a whois on a ULA-C address, the server will > > send back something like this: > > > > Comment: These addresses are ULA-C addresses as defined in RFC 7777.= > > > Comment: These addresses are not intended for use on the public > > Comment: Internet and are not recorded in ARIN's whois directory. > > Comment: However you can query the ULA-C database at > > http://ula.arin.net > > =20 > > So, rather than putting them in WHOIS, which is supposed to be > comprehensive, now the RIRs are going to have to operate a _second_ > directory service which duplicates WHOIS's functionality but contains a > different subset of records? That seems like a waste of time, effort, > and money, since it doesn't really accomplish _anything_. > > If RIRs list ULA-C assignments in _any_ publicly-accessible database, > customers can go to their ISP and say "My number is in $RIR's database, > so you have to route it for me!" That is not good, because _many_ ISPs > will listen to such arguments, and in a decade or less there will be no > meaningful difference between the routability of ULA-Cs and GUAs. This is completely illogical. Why should the ISP listen? ULA-C is *not* supposed to be routed, and even if the ISP is brow-beaten into routing it, all the other ISPs will filter it and so the customer's demand does it virtually no good, even if it is listened to. > > ULAs are _local_, i.e. not meant to be seen on the Internet. If > individual orgs want to know which of their non-Internet peers is using, > they can establish that via standard contractual means--or demand that > their peers get GUAs. > > > Comment: Note that ULA-C addresses are assigned randomly. There is > > Comment: no need to check a specific address for availability and > > Comment: ARIN can *NOT* accomodate any requests for a specific block= > =2E > > =20 > > I don't see any point in including this information in WHOIS, nor is it > all that different from how any other addresses are assigned by ARIN. > > > Comment: More information is available at http://ula.arin.net > > Comment: and at http://www.cymru.com/Bogons/ipv6.txt > > =20 > > That'd be fine, except I don't approve of ARIN linking to external sites > that are not officially part of the Internet governance community. The > Cymru folks do good work, but official they are not. > > I still object to a ULA-C block in general, for a variety of reasons; my > comments here are just to make sure that if we go down that path, we do > it in the least-broken way possible. You might as well object to vanilla ice cream because you prefer chocolate. If you don't want ULA-C addresses, don't ask for any. No one would be forcing you, and no one can require that you route them. > > S -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From stephen at sprunk.org Fri Mar 19 16:24:26 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 19 Mar 2010 15:24:26 -0500 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <1100319142309.37820A-100000@Ives.egh.com> References: <1100319142309.37820A-100000@Ives.egh.com> Message-ID: <4BA3DD7A.9070908@sprunk.org> On 19 Mar 2010 13:29, John Santos wrote: > On 19 Mar 2010 stephen at sprunk.org wrote: > >> So, rather than putting them in WHOIS, which is supposed to be comprehensive, now the RIRs are going to have to operate a _second_ directory service which duplicates WHOIS's functionality but contains a different subset of records? That seems like a waste of time, effort, and money, since it doesn't really accomplish _anything_. >> >> If RIRs list ULA-C assignments in _any_ publicly-accessible database, customers can go to their ISP and say "My number is in $RIR's database, so you have to route it for me!" That is not good, because _many_ ISPs will listen to such arguments, and in a decade or less there will be no meaningful difference between the routability of ULA-Cs and GUAs. >> > This is completely illogical. Why should the ISP listen? The ISP _will_ listen because the customer has money, collectively if not enough individually. > ULA-C is *not* supposed to be routed, and even if the ISP is brow-beaten into routing it, all the other ISPs will filter it and so the customer's demand does it virtually no good, even if it is listened to. > If this would really work, then why bother having a separate database for ULA-C? We could just put them in WHOIS like any other addresses, just with a comment on the record that RFC XYZ says they shouldn't be routed publicly. >> I still object to a ULA-C block in general, for a variety of reasons; my comments here are just to make sure that if we go down that path, we do it in the least-broken way possible. >> > You might as well object to vanilla ice cream because you prefer > chocolate. If you don't want ULA-C addresses, don't ask for any. > No one would be forcing you, and no one can require that you route > them. > We're supposed to be considering the good of the entire community here, not just ourselves, and IMHO ULA-C is bad for the entire community. It made a _small_ bit of sense back before PIv6 was allowed, but that excuse is gone. If GUAs are too difficult for legitimate users to get, we need to fix the GUA policy, not create a way for people to bypass the system. If "no one can require that you route them" really worked, why have an IPv6 allocation/assignment policy at all, rather than simply handing out address blocks to anyone who asked for them? After all, ARIN doesn't guarantee routability of _any_ numbers. Also, by specifically saying that ULA-Cs are unroutable, that implies that non-ULA-C addresses _are_ somehow guaranteed to be routable, and that is a dangerous implication for us to make. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From michael.dillon at bt.com Mon Mar 22 05:07:53 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Mar 2010 09:07:53 -0000 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BA3B4AF.7090806@sprunk.org> Message-ID: <28E139F46D45AF49A31950F88C497458058E21B8@E03MVZ2-UKDY.domain1.systemhost.net> > So, rather than putting them in WHOIS, which is supposed to > be comprehensive, now the RIRs are going to have to operate a > _second_ directory service which duplicates WHOIS's > functionality but contains a different subset of records? No. Firstly whois is not comprehensive. It currently contains only ARIN allocations. If you query a RIPE allocated address then you get comments similar to what I showed. And if you query ULA-RANDOM you get nothing at all. Secondly, the ULA-C query would not duplicate whois's fuctionality because you don't have the same interconnected set of records like technical contacts, ASNs, Orgs, etc. Just one ULA-C block and the identity and contact info for the Org who registered it. There is no need for a technical contact since this block will never be used for internetworking outside of private two-party agreements. Remember that the entire ULA block is a bogon. These are not Internet addresses. And most importantly, the ULA-C registry is not ARIN's. It is a single global registry used by all 5 RIRs. > That seems like a waste of time, effort, and money, since it > doesn't really accomplish _anything_. Sure it does. It gives organizations a registered ULA-C block at a fee that they are willing to pay, and keeps a clean separation between ULA-C addresses and Internet addresses. > If RIRs list ULA-C assignments in _any_ publicly-accessible > database, customers can go to their ISP and say "My number is > in $RIR's database, so you have to route it for me!" They can try, but I expect that the ULA-C directory will have similarly worded disclaimers as I suggested for whois, so the ISP will point to that and say, "Can't you read plain English? It says that these addresses are not for use on the public Internet and should be considered bogons.". > That is > not good, because _many_ ISPs will listen to such arguments, > and in a decade or less there will be no meaningful > difference between the routability of ULA-Cs and GUAs. ARIN is not the intelligence police. If you really believe that stupidity will increase (see the film Idiocracy) then I suggest that there is nothing ARIN can do about it. > ULAs are _local_, i.e. not meant to be seen on the Internet. > If individual orgs want to know which of their non-Internet > peers is using, they can establish that via standard > contractual means--or demand that their peers get GUAs. However ULA-C addresses are registered in a 3rd party registry. If the RIRS do NOT manage that registry then we will have no policy control and it is possible that it will grow legs and demand to compete with ARIN on a level playing field. However, if the RIRs DO manage the registry, we can keep it in the corner where it belongs. If people want to register globally unique local blocks which are not meant to be seen on the Internet, then that is what we should provide. After all, ARIN is not the "Internet" registry. ARIN is the registry for various numbers related to IETF protocols which are in use, both on and off the Internet. > > Comment: Note that ULA-C addresses are assigned > randomly. There is > > Comment: no need to check a specific address for availability and > > Comment: ARIN can *NOT* accomodate any requests for a > specific block. > > I don't see any point in including this information in WHOIS, > nor is it all that different from how any other addresses are > assigned by ARIN. Well, since that is an ARIN operational issue, not a policy one, you have no say over what ARIN may or may not include in a whois message. I merely suggested this in the context of an example. --Michael Dillon From michael.dillon at bt.com Mon Mar 22 05:27:37 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Mar 2010 09:27:37 -0000 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BA3DD7A.9070908@sprunk.org> Message-ID: <28E139F46D45AF49A31950F88C497458058E2208@E03MVZ2-UKDY.domain1.systemhost.net> > The ISP _will_ listen because the customer has money, > collectively if not enough individually. You are wrong! Spammers have lots of money, but the vast majority of ISPs refuse to accept customers who spam. Money is not the only factor in an ISP's decision. ULA-C is only intended to be routed between consenting parties, which means that ISPs will likely accept a few ULA-C routes for transit where two or more of their customers need to interconnect their networks. That is OK and is indeed what ULA-C is intended to facilitate. And there is nothing bad about that because it does not affect the global routing table or the public Internet. > If this would really work, then why bother having a separate > database for ULA-C? We could just put them in WHOIS like any > other addresses, just with a comment on the record that RFC > XYZ says they shouldn't be routed publicly. Because ULA-C addresses don't come from a single RIR's supply but from IANA's unique database, even if that database is operated by a couple of RIRs. And ULA-C addresses are not intended for use on the public Internet so they should have a whois entry similar to And because if someone comes to an ISP and asks to route a ULA-C block, the ISP can say that for the past 12 years our policy has been to *NOT* route blocks which are not registered to your organization in whois. The whois entry will back them up, and when the customer points to the other database, the ISP can legitimately say, but that is not a whois entry, that is some other database which also has a note saying that these addresses are not for use on the pulic Internet. > We're supposed to be considering the good of the entire > community here, not just ourselves, and IMHO ULA-C is bad for > the entire community. It made a _small_ bit of sense back > before PIv6 was allowed, but that excuse is gone. If GUAs > are too difficult for legitimate users to get, we need to fix > the GUA policy, not create a way for people to bypass the system. Enterprise users, who are sorely underrepresented in the RIRs, rather like to have internal networks addressed with blocks which don't work on the Internet. It adds an additional layer of security in case various people make mistakes in configuring things like routers and firewalls. > Also, by specifically saying that ULA-Cs are > unroutable, that implies that non-ULA-C addresses _are_ > somehow guaranteed to be routable, and that is a dangerous > implication for us to make. The wording can be adjusted. For instance it could say that unlike the global unicast addresses in 2000::/3, addresses from the ULA-C range are not guaranteed to be routable on the public Internet. Typically, any ULA-C routes will be blocked at AS boundaries. --Michael Dillon From michael.dillon at bt.com Mon Mar 22 07:03:52 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Mar 2010 11:03:52 -0000 Subject: [arin-ppml] ULA-C and reverse DNS Message-ID: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net> I got a private question that I thought was worth sharing: > So, how is the reverse DNS handled then? Same as RFC 1918 addresses. In fact, it would be good for this to be made explicit either in the global RIR policy (i.e. RIR will not prove reverse DNS services) or in the RFC or both. Addresses intended for use on the public Internet come with reverse DNS delegations, but ULA-C addresses only come with guaranteed global uniqueness. --Michael Dillon From farmer at umn.edu Mon Mar 22 08:33:33 2010 From: farmer at umn.edu (David Farmer) Date: Mon, 22 Mar 2010 07:33:33 -0500 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <28E139F46D45AF49A31950F88C497458058E1B06@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458058E1B06@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4BA7639D.4000208@umn.edu> michael.dillon at bt.com wrote: > I think that we should go ahead with allocating a /8 for ULA-C > addresses without any significant technical changes to this > Internet draft > Are there changes between Tony's Draft and this one that you object to? Tony's draft seems to be the most current. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From farmer at umn.edu Mon Mar 22 08:28:41 2010 From: farmer at umn.edu (David Farmer) Date: Mon, 22 Mar 2010 07:28:41 -0500 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4BA76279.9060809@umn.edu> If ULA-Central is not going to include authoritative reverse DNS, then I'm not sure the point of doing ULA-Central. One of the biggest problem I have with RFC1918 is the brain damage it causes in DNS, ULA-Random has this same brain damage. I see no point in doing ULA-Central if it doesn't include reverse DNS too. michael.dillon at bt.com wrote: > I got a private question that I thought was worth sharing: > >> So, how is the reverse DNS handled then? > > Same as RFC 1918 addresses. > > In fact, it would be good for this to be made explicit either > in the global RIR policy (i.e. RIR will not prove reverse > DNS services) or in the RFC or both. > > Addresses intended for use on the public Internet come with > reverse DNS delegations, but ULA-C addresses only come with > guaranteed global uniqueness. > > --Michael Dillon > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From owen at delong.com Mon Mar 22 08:51:33 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Mar 2010 05:51:33 -0700 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <4BA76279.9060809@umn.edu> References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net> <4BA76279.9060809@umn.edu> Message-ID: <07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com> I agree. I think that it makes far more sense to make a liberal GUA policy that allows people to get GUA if they need it regardless of whether they need it for internet or not. Then, if they want it from a prefix set aside as "non-routable", then, that's available, but, it's a purely advisory semantic, not something coded into systems or routers or whatever. Owen On Mar 22, 2010, at 5:28 AM, David Farmer wrote: > If ULA-Central is not going to include authoritative reverse DNS, then I'm not sure the point of doing ULA-Central. One of the biggest problem I have with RFC1918 is the brain damage it causes in DNS, ULA-Random has this same brain damage. I see no point in doing ULA-Central if it doesn't include reverse DNS too. > > michael.dillon at bt.com wrote: >> I got a private question that I thought was worth sharing: >>> So, how is the reverse DNS handled then? >> Same as RFC 1918 addresses. >> In fact, it would be good for this to be made explicit either in the global RIR policy (i.e. RIR will not prove reverse DNS services) or in the RFC or both. >> Addresses intended for use on the public Internet come with >> reverse DNS delegations, but ULA-C addresses only come with >> guaranteed global uniqueness. >> --Michael Dillon >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mcr at sandelman.ca Mon Mar 22 10:12:35 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 22 Mar 2010 10:12:35 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <28E139F46D45AF49A31950F88C497458058E2208@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458058E2208@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <9254.1269267155@marajade.sandelman.ca> > The ISP _will_ listen because the customer has money, > collectively if not enough individually. I'm also lost by this statement. It seems to be lost in IPv4 scarcity ideas to me. It's not one ISP that customer with $$$$ has to convince, but *all* of them. A customer with that much money can certainly afford to buy globablly routable /48, or a /32 or something. End systems with that much money do not appear overnight, so it's not like they are going to number a billion mobile phones with ULA-C addresses and then want to route it. Such an organization will have money to get the address space they need. If there are customers with $$$$ money, how come they haven't convinced ISPs to route 10/8 for them already? Listen to Michael Dillon, my emphasis: > Enterprise users, who are SORELY UNDERREPRESENTED in the RIRs, rather > like to have internal networks addressed with blocks which DON'T WORK > on the Internet. It adds an ADDITIONAL LAYER OF SECURITY in case > various people make mistakes in configuring things like routers and > firewalls. AND, a reason why having whois-type information available, and for using globably unique address is so that when this mistake is discovered, it is possible to actually find out whose address space is leaking! -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr at sandelman.ca Mon Mar 22 10:20:28 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 22 Mar 2010 10:20:28 -0400 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <9736.1269267628@marajade.sandelman.ca> >>>>> "michael" == michael dillon writes: michael> I got a private question that I thought was worth sharing: >> So, how is the reverse DNS handled then? (That was me, I didn't really have to write privately) michael> Same as RFC 1918 addresses. You mean, the root and arpa. name servers are going to provide NXDOMAIN responses for them all, at huge load and system impact? michael> Addresses intended for use on the public Internet come with michael> reverse DNS delegations, but ULA-C addresses only come with michael> guaranteed global uniqueness. That's really a big problem to me. Reverse DNS is really the major reason to prefer ULA-C over ULA-random. If there is no reverse DNS, then the enterprise has to arrange for *all* machines (including the mobile ones using MIPv6) to always use the same set of concentric DNS servers. In multi-site RFC1918 numbered enterprises, what I've seen is that they have given up on reverse DNS, sometimes given up on DNS period. The only reason your proposal can't include reverse DNS is because it has been created as a tragedy of the commons with no specific RIR responsible for this. Why not just take the address space and delegate /16s of it to each RIR in the same way we do now? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr at sandelman.ca Mon Mar 22 10:36:10 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 22 Mar 2010 10:36:10 -0400 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com> References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net> <4BA76279.9060809@umn.edu> <07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com> Message-ID: <10731.1269268570@marajade.sandelman.ca> >>>>> "Owen" == Owen DeLong writes: Owen> I think that it makes far more sense to make a liberal GUA Owen> policy that allows people to get GUA if they need it Owen> regardless of whether they need it for internet or not. Okay, I can live with this, as long as it's a simple web form w/online payment and no further questions. Something a manager of a small lab can get without signatures from twelve other entities in the "IT" management part of the enterprise. But: a) Is the price the same as for GUA? b) Is the needs-requirement the same? If the answer is YES, then it's not a policy. Its status quo. If the answer is NO, then there are those that will argue that this will be used as a run-around "routing" policy. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From farmer at umn.edu Mon Mar 22 11:12:06 2010 From: farmer at umn.edu (David Farmer) Date: Mon, 22 Mar 2010 10:12:06 -0500 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <10731.1269268570@marajade.sandelman.ca> References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net> <4BA76279.9060809@umn.edu> <07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com> <10731.1269268570@marajade.sandelman.ca> Message-ID: <4BA788C6.3090703@umn.edu> Michael Richardson wrote: >>>>>> "Owen" == Owen DeLong writes: > Owen> I think that it makes far more sense to make a liberal GUA > Owen> policy that allows people to get GUA if they need it > Owen> regardless of whether they need it for internet or not. > > Okay, I can live with this, as long as it's a simple web form w/online > payment and no further questions. Something a manager of a small lab > can get without signatures from twelve other entities in the "IT" > management part of the enterprise. The brain damage inside any enterprise should not drive global policy for resources. It is not the job of global policy to tell an enterprise how to run itself, and it would really be a bad idea for global policy to enter the realm of enterprise politics. > But: > a) Is the price the same as for GUA? > b) Is the needs-requirement the same? > > If the answer is YES, then it's not a policy. Its status quo. > If the answer is NO, then there are those that will argue that this will > be used as a run-around "routing" policy. Are you suggesting that each sub part of an enterprise should be able get its own /48? Are you suggesting there should be no limit to the number of /48s a enterprise can get? It sounds to me like that is what you are suggesting. I think that is unwise for ULA-Central or normal global unicast. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From michael.dillon at bt.com Mon Mar 22 11:53:17 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Mar 2010 15:53:17 -0000 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <4BA76279.9060809@umn.edu> Message-ID: <28E139F46D45AF49A31950F88C497458058E2836@E03MVZ2-UKDY.domain1.systemhost.net> > If ULA-Central is not going to include authoritative reverse > DNS, then I'm not sure the point of doing ULA-Central. One > of the biggest problem I have with RFC1918 is the brain > damage it causes in DNS, ULA-Random has this same brain > damage. I see no point in doing ULA-Central if it doesn't > include reverse DNS too. ULA addresses, both the C and RANDOM varieties, are intended to be used local to a specific network. That means that the network will have certain boundaries at which traffic using ULA addresses will be blocked. These could be site boundaries or private network boundaries) including a global VPN, or in the case of M/A companies, the collective boundary could be the union of two or more private networks with one or two ISPs included who have special arrangements to carry the ULA traffic. So, however vague the thing with boundaries might be, it does have boundaries and all queries for the ULA addresses will originate within those boundaries. I see no good reason for a service to be provided to this bounded network from the public Internet. Inside their boundaries, they can run their own reverse DNS servers, or some kind of DNS proxy which fakes NS records so that it looks like ARIN servers have delegated the reverse DNS for the ULA'C block. It all stays inside. Now there is no reason why a commercial provider on the Internet could not offer such reverse DNS services and deliver them by extending a VPN tunnel to the bounded network, but that is still not on the public Internet, as has always been intended. --Michael Dillon From michael.dillon at bt.com Mon Mar 22 12:12:40 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Mar 2010 16:12:40 -0000 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BA7639D.4000208@umn.edu> Message-ID: <28E139F46D45AF49A31950F88C497458058E2868@E03MVZ2-UKDY.domain1.systemhost.net> > > I think that we should go ahead with allocating a /8 for ULA-C > > addresses without any significant technical changes to this > Internet > > draft > > Are there changes between Tony's Draft and this one that you > object to? > > Tony's draft seems to be the most current. That draft is fine. The most important thing missing from it is mention of the global RIR policy, and a discussion of what aspects are covered by the RIR policy and what are covered by the RFC. For instance, 3.2.1 could be less vague. The question of renewal and de-allocation is probably out of scope for an RFC and should be left to the RIRs. The sample algorithm should be replaced by "the algorithm to be used by the RIRs' ULA-C registry is as follows". And that may be a slightly different algorithm. It would be good if it included a check for collisions, and some means of resolving the issue of up to 5 RIR's using it at the same time while maintaining coherency. I expect this is a job for a NoSQL database rather than a full-blown relational one. The registration services section might be changed to just say that the RIRs will operate a single joint directory lookup service, that is entirely separate from the whois directorys of each RIR, and that each RIR will place an entry for the entire ULA-C range in their whois directory with the following disclaimer: ... The DNS issues section should be replaced with a note that it will be necessary for sites to run their own internal DNS in order to handle reverse DNS because ULA-C addresses will not be accepted in the public ip6.arpa zone. There will only be a single delegation for the entire zone to an IANA server that will have no further info, similar to IPv4 RFC 1918 addresses. 5.0 could have some mention of RFC 5156 and note that as a result the ULA blocks are likely to be listed in bogon lists which result in active blocking of traffic using ULA addresses. In 7.0, I think it should explicitly state that the RIRs will jointly run a single replicated database for this registry, and the details of whether or not ARIN and RIPE end up running it for the other 3 RIRs, would be left to global policy, or even just unstated. There should be no need of an RIR RFC, since the details can be worked out now and incorporated into the final ULA-C RFC. --Michael Dillon From michael.dillon at bt.com Mon Mar 22 12:19:18 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Mar 2010 16:19:18 -0000 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com> Message-ID: <28E139F46D45AF49A31950F88C497458058E287D@E03MVZ2-UKDY.domain1.systemhost.net> > I think that it makes far more sense to make a liberal GUA > policy that allows people to get GUA if they need it > regardless of whether they need it for internet or not. > Then, if they want it from a prefix set aside as > "non-routable", then, that's available, but, it's a purely > advisory semantic, not something coded into systems or > routers or whatever. That is as bad as PA addressing. Your address range is tainted as unroutable, and if you want to change that, you have to return the addresses and get a new range and renumber. ULA-C allocations are what they are, and are permanent allocations. You simply do not use them for traffic which needs to be routable on the Internet. e.g.: Printer1 link local, ULA Printer2 link local, ULA FileServer1 link local, ULA FileServer2 link local, Global Unicast WebServer1 link local, ULA WebServer2 link local, Global Unicast MailServer link local, ULA, Global Unicast Everybody has a link local adddress. Things that are only used inside the org, have a ULA address. FileServer2 is for customers to upload some data. WebServer1 handles the company intranet webservices, WebServer2 is the external Internet webserver. And the Mailserver works for everyone, everywhere, however they may roam. --Michael Dillon From michael.dillon at bt.com Mon Mar 22 12:25:07 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Mar 2010 16:25:07 -0000 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <9736.1269267628@marajade.sandelman.ca> Message-ID: <28E139F46D45AF49A31950F88C497458058E289C@E03MVZ2-UKDY.domain1.systemhost.net> > Why not just take the address space and delegate /16s of it > to each RIR in the same way we do now? We don't want it to be aggregatable. However we could allocate bunches of 1000 randomly generated ULA-C blocks to an RIR. That might make it possible to have the RIRs run reverse DNS service for their own customers. But the zones would be a bit messy. --Michael Dillon P.S. I'm not yet convinced that reverse DNS is needed. If a mobile device, is using ULA-C addresses, then it must have connectivity to a network using ULA-C addresses, therefore it is inside that network and can use private reverse DNS services. From michael.dillon at bt.com Mon Mar 22 12:30:22 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Mar 2010 16:30:22 -0000 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <4BA788C6.3090703@umn.edu> Message-ID: <28E139F46D45AF49A31950F88C497458058E28AA@E03MVZ2-UKDY.domain1.systemhost.net> > Are you suggesting that each sub part of an enterprise should > be able get its own /48? Are you suggesting there should be > no limit to the number of /48s a enterprise can get? It > sounds to me like that is what you are suggesting. There is a natural limit on the number of ULA-C prefixes that an enterprise can get. If they only want to route locally in some lab or local infrastructure, then they can get a ULA-C block. Later, if what they have built becomes valuable to the enterprise, they can route that ULA-C block enterprise wide with confidence that it won't break anything. But, the new block will not function enterprise wide unless they can convice the IT admins to unblock that network in their firewall ACLs. It is common for there to be multiple layers of firewalls internal to an enterprise and the policies are roughly to block all traffic that is not known and registered in their IT registry. --Michael Dillon From farmer at umn.edu Mon Mar 22 13:09:21 2010 From: farmer at umn.edu (David Farmer) Date: Mon, 22 Mar 2010 12:09:21 -0500 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <28E139F46D45AF49A31950F88C497458058E2836@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458058E2836@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4BA7A441.8040509@umn.edu> michael.dillon at bt.com wrote: >> If ULA-Central is not going to include authoritative reverse >> DNS, then I'm not sure the point of doing ULA-Central. One >> of the biggest problem I have with RFC1918 is the brain >> damage it causes in DNS, ULA-Random has this same brain >> damage. I see no point in doing ULA-Central if it doesn't >> include reverse DNS too. > > ULA addresses, both the C and RANDOM varieties, are intended > to be used local to a specific network. That means that the > network will have certain boundaries at which traffic using > ULA addresses will be blocked. These could be site boundaries > or private network boundaries) including a global VPN, or in the > case of M/A companies, the collective boundary could be the > union of two or more private networks with one or two ISPs > included who have special arrangements to carry the ULA traffic. > > So, however vague the thing with boundaries might be, it does > have boundaries and all queries for the ULA addresses will > originate within those boundaries. I see no good reason for > a service to be provided to this bounded network from the public > Internet. Inside their boundaries, they can run their own > reverse DNS servers, or some kind of DNS proxy which fakes > NS records so that it looks like ARIN servers have delegated > the reverse DNS for the ULA'C block. It all stays inside. This very notion of split DNS that is the brain damage I was referring too. DNS Views etc... are not very well implemented across the Internet, the tools are there, but they are not properly implemented in many cases. RFC 1918 forward and reverse are leaked all over the Internet, especially in DNS. Providing for authoritative DNS reverse with ULA-C doesn't prevent you from doing split DNS if you wish to, you can simply not respond to reverse queries coming from outside the boundary you are referring to. However, assuming that you have to do split DNS in order to do DNS for ULA-C is a bad idea. You are making assumptions about the way people will use ULA-C, to the extent possible we should avoid making to many assumptions. I would probably implement split DNS, but even if I do, I might find it useful for any lookups for my ULA-C reverse blocks to make there way to my public authoritative DNS servers, so I can get an idea if there is any leakage that I'm not expecting. > Now there is no reason why a commercial provider on the Internet > could not offer such reverse DNS services and deliver them by > extending a VPN tunnel to the bounded network, but that is still > not on the public Internet, as has always been intended. I'm not sure I understand what you are getting at here. What would a commercial provider do, register my DNS servers in the reverse tree? > --Michael Dillon > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From owen at delong.com Mon Mar 22 13:37:09 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Mar 2010 10:37:09 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <9254.1269267155@marajade.sandelman.ca> References: <28E139F46D45AF49A31950F88C497458058E2208@E03MVZ2-UKDY.domain1.systemhost.net> <9254.1269267155@marajade.sandelman.ca> Message-ID: On Mar 22, 2010, at 7:12 AM, Michael Richardson wrote: > >> The ISP _will_ listen because the customer has money, >> collectively if not enough individually. > > I'm also lost by this statement. > It seems to be lost in IPv4 scarcity ideas to me. > > It's not one ISP that customer with $$$$ has to convince, but *all* of > them. A customer with that much money can certainly afford to buy > globablly routable /48, or a /32 or something. > If there were enough reliably good filtering, sure. There isn't, and, as long as one ISP somewhere accepts it, it'll get to a surprisingly large fraction of the internet and eventually, it'll end up getting accepted. > End systems with that much money do not appear overnight, so it's not > like they are going to number a billion mobile phones with ULA-C > addresses and then want to route it. Given the source of some of the tactics like this which I have seen in IPv4, I wouldn't count on that being the case. I do know of one case which I can't disclose details due to NDA where it was exactly a very large mobile phone provider forcing another company to route an IANA-Reserved /8 to their network. I keep hoping that said /8 ends up at least partially allocated to one of said company's other customers. > Such an organization will have money to get the address space they > need. > Doesn't mean they'll choose to do it, especially if ULA-C appears otherwise easier or cheaper to get. > If there are customers with $$$$ money, how come they haven't > convinced > ISPs to route 10/8 for them already? > 10/8 suffers from a lack of global uniqueness. This means that none of the multiple users is more entitled to use it than any of the others and routing it is guaranteed to be a mess. (Still, it's not like it never appears in tables in the DFZ). ULA-C would not suffer from this issue, so, I can see the thought process going along the lines of "Heh.. $$$ for doing something harmless.. Why not." > Listen to Michael Dillon, my emphasis: > >> Enterprise users, who are SORELY UNDERREPRESENTED in the RIRs, rather >> like to have internal networks addressed with blocks which DON'T WORK >> on the Internet. It adds an ADDITIONAL LAYER OF SECURITY in case >> various people make mistakes in configuring things like routers and >> firewalls. > > AND, a reason why having whois-type information available, and for > using > globably unique address is so that when this mistake is > discovered, it > is possible to actually find out whose address space is leaking! > ULA-C isn't going to be blocks which don't work on the internet. It's going to be blocks which people expect not to work on the internet, but, really they do under some circumstances. End result, a false sense of security which is worse than no security. NAT != Security Address Obfuscation != Security Misconfiguration == Insecurity Belief otherwise merely increases risk. Owen From mcr at sandelman.ca Mon Mar 22 13:44:03 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 22 Mar 2010 13:44:03 -0400 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <4BA788C6.3090703@umn.edu> References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net> <4BA76279.9060809@umn.edu> <07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com> <10731.1269268570@marajade.sandelman.ca> <4BA788C6.3090703@umn.edu> Message-ID: <17992.1269279843@marajade.sandelman.ca> >>>>> "David" == David Farmer writes: >> But: a) Is the price the same as for GUA? b) Is the >> needs-requirement the same? If the answer is YES, then it's not >> a policy. Its status quo. If the answer is NO, then there are >> those that will argue that this will be used as a run-around >> "routing" policy. David> Are you suggesting that each sub part of an enterprise should David> be able get its own /48? Are you suggesting there should be David> no limit to the number of /48s a enterprise can get? It David> sounds to me like that is what you are suggesting. Yes. 1,099,511,627,776 Number of /48s in a /8 6,692,030,277 population of planet in 2008. That's 164 /48s for every man/woman/child. There is no scarcity. Stop thinking like there is. These networks are not connected and would be labelled as such. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From owen at delong.com Mon Mar 22 13:39:59 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Mar 2010 10:39:59 -0700 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <10731.1269268570@marajade.sandelman.ca> References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net> <4BA76279.9060809@umn.edu> <07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com> <10731.1269268570@marajade.sandelman.ca> Message-ID: <57C0DA71-77B5-4544-9B2C-CF65C7C64CEA@delong.com> On Mar 22, 2010, at 7:36 AM, Michael Richardson wrote: > >>>>>> "Owen" == Owen DeLong writes: > Owen> I think that it makes far more sense to make a liberal GUA > Owen> policy that allows people to get GUA if they need it > Owen> regardless of whether they need it for internet or not. > > Okay, I can live with this, as long as it's a simple web form w/online > payment and no further questions. Something a manager of a small lab > can get without signatures from twelve other entities in the "IT" > management part of the enterprise. > > But: > a) Is the price the same as for GUA? > b) Is the needs-requirement the same? > > If the answer is YES, then it's not a policy. Its status quo. The answer needs to be yes, but, I believe there need to be changes to (a) and (b) accordingly. > If the answer is NO, then there are those that will argue that this > will > be used as a run-around "routing" policy. > But the RIRs are not supposed to set "routing" policy. "Routing" policy is supposed to be set by those who actually run routers. Owen From owen at delong.com Mon Mar 22 14:00:22 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Mar 2010 11:00:22 -0700 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <28E139F46D45AF49A31950F88C497458058E287D@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458058E287D@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <1107C792-6196-4F16-93BD-E6111F298D15@delong.com> On Mar 22, 2010, at 9:19 AM, wrote: > >> I think that it makes far more sense to make a liberal GUA >> policy that allows people to get GUA if they need it >> regardless of whether they need it for internet or not. >> Then, if they want it from a prefix set aside as >> "non-routable", then, that's available, but, it's a purely >> advisory semantic, not something coded into systems or >> routers or whatever. > > That is as bad as PA addressing. Your address range is > tainted as unroutable, and if you want to change that, > you have to return the addresses and get a new range > and renumber. > Nope... It's as bad as ULA-C _IF_ you choose to get it from the tainted block. If you choose to get it from an un-tainted block, then you have the option whether to connect it or not. e.g.: Printer1 link local, GUA-tainted Printer2 link local, GUA-tainted Fileserver1 linklocal, GUA-tainted Fileserver2 linklocal, GUA Webserver1 linklocal, GUA-tainted Webserver2 linklocal, GUA Mailserver linklocal, GUA-tainted, GUA > ULA-C allocations are what they are, and are permanent > allocations. You simply do not use them for traffic > which needs to be routable on the Internet. > Permanent allocations are an absolutely horrible idea. They create a monotonically decreasing resource which cannot be reclaimed when abandoned. Implementing such a thing reflects a failure to learn from our IPv4 experience. > Everybody has a link local adddress. Things that are only > used inside the org, have a ULA address. FileServer2 is > for customers to upload some data. WebServer1 handles > the company intranet webservices, WebServer2 is the external > Internet webserver. And the Mailserver works for everyone, > everywhere, however they may roam. > s/ULA/GUA-tainted/g And you've got exactly the same scenario as ULA-C. Now, s/GUA-tainted/GUA-not-routed/g And you have an option not afforded to ULA, but, which may be desirable to some enterprises which is that you can make the not-routed block routed if you desire to. A liberal GUA policy which: 1. Does not assume prefixes will be routed 2. Offers the user a choice of "tainted prefixes" if they choose 3. Is coupled with a modest fee structure (much more modest than the current fee structure, on the order of $300 initial and $50 annual, for example) Would offer pretty much all that is good about ULA-C without making it a tool for end-running addressing policy. Owen From owen at delong.com Mon Mar 22 14:03:37 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Mar 2010 11:03:37 -0700 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <28E139F46D45AF49A31950F88C497458058E28AA@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458058E28AA@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: On Mar 22, 2010, at 9:30 AM, wrote: >> Are you suggesting that each sub part of an enterprise should >> be able get its own /48? Are you suggesting there should be >> no limit to the number of /48s a enterprise can get? It >> sounds to me like that is what you are suggesting. > > There is a natural limit on the number of ULA-C prefixes that > an enterprise can get. If they only want to route locally in > some lab or local infrastructure, then they can get a ULA-C > block. Later, if what they have built becomes valuable to the > enterprise, they can route that ULA-C block enterprise wide > with confidence that it won't break anything. But, the new > block will not function enterprise wide unless they can > convice the IT admins to unblock that network in their firewall > ACLs. It is common for there to be multiple layers of firewalls > internal to an enterprise and the policies are roughly to block > all traffic that is not known and registered in their IT registry. > How does that pose a limit on the number of blocks they get? The process you have described allows a very large enterprise to get a ULA-C block for a lab, use it, tear it down, forget they ever had it and apply for another one 3 months later. Lather, rinse, repeat until you actually do manage to burn 40 bits worth of address space. There is nothing in your proposal to prevent failure to return unused ULA-C and nothing to prevent merely applying for more instead of reusing what you already have. Given our experiences with the IPv4 swamp, I'm inclined to believe that such a system is not in the best interests of the internet community and does not represent good stewardship of the address space. Owen From bicknell at ufp.org Mon Mar 22 14:30:36 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 22 Mar 2010 11:30:36 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <9254.1269267155@marajade.sandelman.ca> References: <28E139F46D45AF49A31950F88C497458058E2208@E03MVZ2-UKDY.domain1.systemhost.net> <9254.1269267155@marajade.sandelman.ca> Message-ID: <20100322183036.GA40906@ussenterprise.ufp.org> In a message written on Mon, Mar 22, 2010 at 10:12:35AM -0400, Michael Richardson wrote: > It's not one ISP that customer with $$$$ has to convince, but *all* of > them. A customer with that much money can certainly afford to buy > globablly routable /48, or a /32 or something. It's not that a smart, well run company can afford the cost up front; they can and will do the right thing. Rather, the worry is the company that goes down a ULA path when they should not out of ignorance or poor planning. Then, 5, or 10 years on when they realize the mistake look at the cost of renumbering and compare it to the cost of buying off their ISP's. Forced to spend a few million dollars on renumbering over six months, or to pay an extra $10k/month to their ISP to route the prefix, they may well choose the latter. Already communities of interest are choosing the same ISP for greater SLA's. They may not need it routed to the global Internet, but rather you see ISP's routing these only internal to their network and their customers. In essence, the ULA boundry becomes the ISP, rather than the Enterprise. It's an interesting situation, because it doesn't hurt the "global" routing table, but it does put much the same pressure on the ISP's backbone devices. We must plan for those who are short sighted, ignorant, lazy, and simply dumb. No, that doesn't mean making their lives easier, but it does mean finding ways to prevent them from peeing in the pool and making it unsuitable for all. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From mcr at sandelman.ca Mon Mar 22 15:15:38 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 22 Mar 2010 15:15:38 -0400 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <28E139F46D45AF49A31950F88C497458058E287D@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458058E287D@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <24133.1269285338@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "michael" == michael dillon writes: >> I think that it makes far more sense to make a liberal GUA policy >> that allows people to get GUA if they need it regardless of >> whether they need it for internet or not. Then, if they want it >> from a prefix set aside as "non-routable", then, that's >> available, but, it's a purely advisory semantic, not something >> coded into systems or routers or whatever. michael> That is as bad as PA addressing. Your address range is michael> tainted as unroutable, and if you want to change that, you michael> have to return the addresses and get a new range and michael> renumber. I think that this is something to repeat multiple times. I think that a lot of people regard address space as so valuable that it would be crazy to "waste" it by having two IPs addresses on a single machine. This is where I think the notion that people will pay $$$$ to have their address space routed by ISPs. It won't happen --- getting new PA will be almost free, and getting PI address space is a nominal charge given that you have $$$$ for that bribe. michael> Everybody has a link local adddress. Things that are only Alas, link-local addresses are not as easy to use as you might think. They are specific to a link, and IPv6 implementations insist that you tell the kernel which link they are specific to, so applications actually need to grow additional mechanisms to set that. Some OSes have included textual representations in their pton routines to set this properly, not it's not universal in the APIs. It's a rare organization (or even residential home with a wifi router) that has only one physical link --- many do extensive amounts of L2 bridging (and then filtering of broadcasts) to deal with scarcity of IPv4, and lack of mobility. In IPv6 it really makes no sense to do this --- make them seperate L3 subnets and use properly scoped multicast to do service locating. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBS6fB2YCLcPvd0N1lAQLKVwgAgzEQ05LBAMYbdtg5U0bTy54l7ef+VEsR JtW0OsvIyd3ExM4y9rn7MgEezppfMuB3olvTU1BH9JquqV6fqwlL0DULXM7b8TTs Cosm7AU6jcbzBxboaP4HXD6CEURmq7jH9c3hEppNw99yeFl8JS64A9q7NSmTC+um cebPJPVqrajjSYM/Hps24b8XACZFuGZMLrJBv6MoYrx8dG/WqyoVLRYkBbilDV8A MOCETi12wHJyMpqAm9kXz4ntDBkje/Xl5TYDLQ3cg/Lt8hAFeTFxo59Rzs8siHwd lbMjy8Rh2vkKzrwdfqhKrhf8vKLxi/ZUxUCgBL8HUD0B8USejiSbJA== =FZXy -----END PGP SIGNATURE----- From michael.dillon at bt.com Mon Mar 22 15:22:10 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Mar 2010 19:22:10 -0000 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <1107C792-6196-4F16-93BD-E6111F298D15@delong.com> Message-ID: <28E139F46D45AF49A31950F88C497458058E296A@E03MVZ2-UKDY.domain1.systemhost.net> > Permanent allocations are an absolutely horrible idea. They > create a monotonically decreasing resource which cannot be > reclaimed when abandoned. Implementing such a thing reflects > a failure to learn from our IPv4 experience. You are just playing semantic games. The meaning of a "permanent allocation" will be defined by the global RIR policy. I fully expect that policy to have some form of renewal process, and failure to keep that up will cause the registrant to forfeit their block. There will be some form of waiting period, perhaps 5 or 10 years, after which the block is in play again, and might be snapped up by a new registrant. Part of M&A due diligence will be to check the status of any ULA-C blocks and if they are wholly unregistered or forfeited, then you know that you are dealing with incompetent network administration. That kind of thing increases the risk of merging networks therefore depressing the value of the company. If forfeiture becomes at all common, then after a few instances in which companies failed to get themselves bought, or sold at bargain prices, with this as a factor, you'll start to see annual reports touting the fact that their IP addresses are "in good standing" with the RIRs. > s/ULA/GUA-tainted/g > And you've got exactly the same scenario as ULA-C. No. ULA-C addresses already exist and have been set aside by IANA. There is currently no RFC or RIR policy defining how they are used, so they are dormant. If you create documents which use tainted GUA space for the same kind of usage, then people will start to "pirate" the existing ULA-C space. That is not the same scenario. ULA-C exists. Now we have to put some rules around it, and some management practices. > A liberal GUA policy which: > > 1. Does not assume prefixes will be routed > 2. Offers the user a choice of "tainted prefixes" > if they choose > 3. Is coupled with a modest fee structure (much more modest > than the current fee structure, on the order of > $300 initial > and $50 annual, for example) > > Would offer pretty much all that is good about ULA-C without > making it a tool for end-running addressing policy. No. We have a small problem over here in the corner, dealing with something analogous to private network addresses in IPv4, and mainly concerning enterprise network architects. The solution to that is *NOT* to change the rules for everybody, but to tidy up the corner and make sure that it stays in the corner. --Michael Dillon From info at arin.net Mon Mar 22 15:23:26 2010 From: info at arin.net (Member Services) Date: Mon, 22 Mar 2010 15:23:26 -0400 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests - revised Message-ID: <4BA7C3AE.4020009@arin.net> Draft Policy 2010-1 Waiting List for Unmet IPv4 Requests 2010-1 has been revised. The word "timely" was added before re-validation in 4.1.8.2. Two more questions/answers were added to the rationale. This draft policy is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting in Toronto. Draft Policy 2010-1 is below and can be found at: https://www.arin.net/policy/proposals/2010_1.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2010-1 Waiting List for Unmet IPv4 Requests Version/Date: 22 March 2010 Policy statement: Replace 4.1.6 with: 4.1.6. Aggregation In order to preserve aggregation, ARIN attempts to issue blocks of addresses on appropriate "CIDR-supported" bit boundaries. As long as sufficient space is available, ARIN may reserve space to maximize aggregation possibilities. ARIN will make each allocation and assignment as a single continuous range of addresses. Add new section 4.1.8: 4.1.8 Unmet requests In the event that ARIN does not have a contiguous block of addresses of sufficient size to fulfill a qualified request, ARIN will provide the requesting organization with the option to either modify their request and request a smaller size block, or be placed on a waiting list of pre-qualified recipients. Repeated requests, in a manner that would circumvent 4.1.6, are not allowed: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document an unforeseen change in circumstances since their last request. Qualified requesters whose request cannot be immediately met will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses. 4.1.8.1 Waiting list The position of each qualified request on the waiting list will be determined by the date it was approved. Each organization may have one approved request on the waiting list at a time. 4.1.8.2 Fulfilling unmet needs As address blocks become available for allocation, ARIN will fulfill requests on a first-approved basis, subject to the size of each available address block and a timely re-validation of the original request. Requests will not be partially filled. Any requests met through a transfer will be considered fulfilled and removed from the waiting list. Rationale: ARIN will soon be unable to meet all approved requests for IPv4 address space. In the absence of a policy like this, it is unclear what ARIN should do with subsequent requests. This policy would allocate reclaimed address blocks (and the last of the ARIN free pool) on a first-come-first-served basis, while preserving aggregation to the degree possible. As the free pool shrinks, requests larger than the largest block left would be placed on a waiting list, while smaller requests would use up the rest of it, until all requests have to go on the waiting list. As additional reclaimed addresses become available, the requests that have been waiting the longest would be met first. If a requester gets the addresses they need via transfer, then they would be removed from the waiting list and would need to wait and submit a new request for additional address space, either directly or via transfer. FAQ: Q1: The effect of 2009-8, if implemented by the Board, is to allow transfers to be up to a 12 month supply of resources and up to a 3 month supply for resource from the ARIN free pool. Does that jive with your intent for this policy? A1: Correct. After we get to the last /8, you can request up to a 3-month supply from the free pool, but only every 3 months unless you can document an unforeseen change in circumstances since your last request. However, if you get the space via transfer, you can get a block big enough for 12 month's need, and if you end up using it up faster, you can submit another request after 3 months. Q2: If I were on the waiting list, and subsequently received a transfer via 8.3, would I be removed from the waiting list? A2: Yes. In 4.1.8.2, it says that "Any requests met through a transfer will be considered fulfilled and removed from the waiting list." Q3: Would receipt of an M&A transfer remove you from the waiting list, too? A3: I think that depends on how the M&A is justified. If you acquire a company that is already efficiently utilizing all its IP space, I don't think that would count toward fulfilling an outstanding need that you have a request on the waiting list for. However, if your justification for keeping the space held by the acquired company is that you plan to use it for new stuff, then that would meet an outstanding need, and a request for that same need would be considered fulfilled and removed from the waiting list. Q4: What about Multiple Discrete Networks? A4: Allocations and assignments to organizations using the Multiple Discrete Networks policy must still be made as a single continuous range of addresses. This preserves future aggregatability of the space, and ensures fairness between MDN and ordinary requests. Q5: What would constitute "an unforeseen change in circumstances since their last request" that would allow ARIN to waive the 3-month delay to receive a second block? A5: This would, of course, be a matter of discretion for ARIN, but the idea here is that the burden of proof is on the requester to document some change in circumstances, that could not have been reasonably foreseen at the time of the original request, that now justifies additional space. This is intended to be a rarely used safety valve. Q6: What if an organization goes out of business or no longer needs the space when they get to the top of the waiting list? A6: When a block becomes available to fulfill a request on the waiting list, ARIN will do "a re-validation of the original request". If the original requester cannot be contacted, or their original need is no longer justified, they will be removed from the waiting list, and ARIN will move on to the next qualified requester. Timetable for implementation: Immediate. From info at arin.net Mon Mar 22 15:25:56 2010 From: info at arin.net (Member Services) Date: Mon, 22 Mar 2010 15:25:56 -0400 Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality - staff assessment Message-ID: <4BA7C444.2050008@arin.net> Draft Policy 2010-3 Customer Confidentiality Attached is the ARIN staff assessment of 2010-3. This draft policy is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting in Toronto. 2010-3 is below and available at: https://www.arin.net/policy/proposals/2010_3.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2010-3: Customer Confidentiality Version (Date): 2 February 2010 Date of Assessment: 19 March 2010 1. Summary (Staff Understanding) ARIN staff understands that this policy allows ISPs to substitute their own mailing address and phone number in lieu of their customers? mailing address and phone number when registering reassignment information via SWIP or RWHOIS. It requires ISPs to provide the full customer information to ARIN when asked to do so by ARIN staff. 2. Comments A. ARIN Staff Comments Staff has no comments B. ARIN General Counsel This new proposal permits ARIN to obtain the information it needs to fairly and accurately access utilization. The proposal appears intended to afford privacy protection of customer contact information. However it must be balanced by risks that may create. The proposal defines ARIN's treatment of customer data using a non-legal formulation, e.g. ?strictest confidence?. Such a term conveys an intended sense of how such data should be treated, but is open to wide interpretation. This language, if enacted, could potentially increase ARIN?s legal risk that current ARIN practices might be deemed insufficient under this standard. Current policy attempts to addresses privacy protection for IPv6 reassignment data. For example, NRPM 6.5.5, which states ?IRs shall maintain systems and practices that protect the security of personal and commercial information that is used in request evaluation, but which is not required for public registration.? More precise language, such as that in 6.5.5, might also be considered as a substitute for the term ?strictest confidence?. 3. Resource Impact This policy would have minimal resource impact. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following may be needed in order to implement: Minor updates to the ARIN website Updates to NRPM Sections 4.2.3.7.1 and 6.5.5. 4. Draft Policy Text Draft Policy 2010-3 Customer Confidentiality Version/Date: 2 February 2010 Policy statement: ISPs may choose to enter the customer's name along with the ISP's address and phone number in reassignments and reallocations in lieu of the customer's address and phone number. The customer's actual information must be provided to ARIN on request and will be held in the strictest confidence. Rationale: Version 2.0 clarifies the need for the customer name to remain in the SWIP and RWHOIS information. Customer contact lists are one of the most proprietary and confidential pieces of information in any business. The requirements for ISPs to publish those lists via SWIP or RWHOIS runs contrary to good business practices and invites competitors and others to solicit both individuals and companies receiving reassignments and sub allocations from upstream providers. Timetable for implementation: immediate From mcr at sandelman.ca Mon Mar 22 15:26:27 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 22 Mar 2010 15:26:27 -0400 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <28E139F46D45AF49A31950F88C497458058E289C@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458058E289C@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <24852.1269285987@marajade.sandelman.ca> >>>>> "michael" == michael dillon writes: >> Why not just take the address space and delegate /16s of it to >> each RIR in the same way we do now? michael> We don't want it to be aggregatable. However we could It won't be aggregated by the RIRs. So you can tell who you got the block from by looking it... The RIRs can be trusted to hand out random blocks, I think. The RIR is only 3 bits anyway. michael> P.S. I'm not yet convinced that reverse DNS is needed. If a michael> mobile device, is using ULA-C addresses, then it must have michael> connectivity to a network using ULA-C addresses, therefore michael> it is inside that network and can use private reverse DNS michael> services. a) the mobile device might be using it's ULA-C as an identifier inside some mobility or multihoming mechanism. b) while (a) above could just be MIPv6 or shim6 or IPsec or .... something we do not yet know about. FREQUENTLY, bootstrapping this mechanism is MUCH simpler if it can USE DNS to discover things. Oops. catch-22. c) If one demands that the mobile device do all DNS requests only via it's "home base", then one has created a critical dependancy where none existed before. The "home base" must be reachable at all times, and one has assumed that only a star topology is desireable. MIPv6 provides extensive mechanisms to avoid having to create star topologies!!! You've just made DNS significantly more brittle. Remember: *ALL* DNS requests have to go to the home base, not just reverse DNS requests. This has also been the assumption that all IPsec Remote Access VPN vendors have made for the past 15 years, and it totally fails once you have connections to *TWO* organizations. If you are lucky, they use different RFC1918 adddresses... Lest you think this is uncommon, let me tell you that's is basically a FAQ in the IPsec world. d) If the DNS requests do not flow through a "tunnel", but rather travel to a DNS server that is in the organizations PI or PA address space, then the DNS is less brittle, but two things have just happened: 1) if PA, then organization is now dependant upon PA address provider to be up. DNS can cope with multiple PA addresses sure... 2) if PI, then you didn't need ULA-C in the first place. e) if you are asking why reverse DNS is needed *PERIOD* (for anyone), then that's a different conversation completely. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From michael.dillon at bt.com Mon Mar 22 15:30:30 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Mar 2010 19:30:30 -0000 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458058E296F@E03MVZ2-UKDY.domain1.systemhost.net> > > There is a natural limit on the number of ULA-C prefixes that an > > enterprise can get. If they only want to route locally in > some lab or > > local infrastructure, then they can get a ULA-C block. > Later, if what > > they have built becomes valuable to the enterprise, they can route > > that ULA-C block enterprise wide with confidence that it > won't break > > anything. But, the new block will not function enterprise > wide unless > > they can convice the IT admins to unblock that network in their > > firewall ACLs. It is common for there to be multiple layers of > > firewalls internal to an enterprise and the policies are roughly to > > block all traffic that is not known and registered in their IT > > registry. > > > How does that pose a limit on the number of blocks they get? Because it takes effort to make the ULA-C block usable in the enterprise. That effort is the limiting factor. > The process you have described allows a very large enterprise > to get a ULA-C block for a lab, use it, tear it down, forget > they ever had it and apply for another one 3 months later. Not if the RIR policy has some restrictions around that. Things like renewal payments (or even just process) and membership in good standing as a requirement for 2nd and subsequent ULA-C allocations. > Lather, rinse, repeat until you actually do manage to burn 40 > bits worth of address space. I think you are missing the magnitude of the space available. If it is only done every 3 months, then it will take a long long time to burn through the space. Problems that develop slowly like that are prime targets for new policy development. > There is nothing in your proposal to prevent failure to > return unused ULA-C and nothing to prevent merely applying > for more instead of reusing what you already have. That's because I haven't made a formal proposal for the global RIR policy. Your are shooting at ghosts and phantoms. This is just a discussion of some ideas to scope out the thing before writing another draft, and an RIR policy proposal. > Given our experiences with the IPv4 swamp, I'm inclined to > believe that such a system is not in the best interests of > the internet community and does not represent good > stewardship of the address space. Am I confused here? Didn't our experiences with the swamp give us VLSM and CIDR? These are good things. As is the whole ARIN policy process which also was driven by experiences in the swamp. I remember when I could ask for a /25 allocation, and get two adjacent but non-aggregatable swamp /24 blocks instead. That was due to lack of process, and lack of oversight. The swamp was a good thing. It also drove vendors to better algorithms in the routers (Patricia tries?) and better hardware (TCAMs). --Michael Dillon From owen at delong.com Mon Mar 22 15:35:00 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Mar 2010 12:35:00 -0700 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <24133.1269285338@marajade.sandelman.ca> References: <28E139F46D45AF49A31950F88C497458058E287D@E03MVZ2-UKDY.domain1.systemhost.net> <24133.1269285338@marajade.sandelman.ca> Message-ID: <74FF650D-44AC-40DE-B518-12B3FCDE2EDE@delong.com> On Mar 22, 2010, at 12:15 PM, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "michael" == michael dillon writes: >>> I think that it makes far more sense to make a liberal GUA policy >>> that allows people to get GUA if they need it regardless of >>> whether they need it for internet or not. Then, if they want it >>> from a prefix set aside as "non-routable", then, that's >>> available, but, it's a purely advisory semantic, not something >>> coded into systems or routers or whatever. > > michael> That is as bad as PA addressing. Your address range is > michael> tainted as unroutable, and if you want to change that, you > michael> have to return the addresses and get a new range and > michael> renumber. > > I think that this is something to repeat multiple times. > > I think that a lot of people regard address space as so valuable that it > would be crazy to "waste" it by having two IPs addresses on a single > machine. > > This is where I think the notion that people will pay $$$$ to have their > address space routed by ISPs. It won't happen --- getting new PA will be > almost free, and getting PI address space is a nominal charge given that > you have $$$$ for that bribe. > Getting is cheap. Deploying is another matter. It is the desire to avoid the cost of deployment that will drive this, not the cost of the address space. Leo summed up one likely scenario rather well. > michael> Everybody has a link local adddress. Things that are only > > Alas, link-local addresses are not as easy to use as you might think. > They are specific to a link, and IPv6 implementations insist that you > tell the kernel which link they are specific to, so applications > actually need to grow additional mechanisms to set that. > Some OSes have included textual representations in their pton routines > to set this properly, not it's not universal in the APIs. > Riddle me this... When you have a Link-Local, ULA-C, and a GUA address, how does one decide when to originate a connection from the GUA and when to use the ULA-C address? Until you have an answer for that that does not require updating applications, the multiple different-capability addresses per interface is a nice theory that is fraught with operational peril. > It's a rare organization (or even residential home with a wifi router) > that has only one physical link --- many do extensive amounts of L2 > bridging (and then filtering of broadcasts) to deal with scarcity of > IPv4, and lack of mobility. > While that's true, it's hardly relevant to the topic at hand. > In IPv6 it really makes no sense to do this --- make them seperate L3 > subnets and use properly scoped multicast to do service locating. > Sure, but, that still doesn't change the overall issue of ULA-C. Owen From michael.dillon at bt.com Mon Mar 22 15:41:13 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Mar 2010 19:41:13 -0000 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <20100322183036.GA40906@ussenterprise.ufp.org> Message-ID: <28E139F46D45AF49A31950F88C497458058E2975@E03MVZ2-UKDY.domain1.systemhost.net> > Rather, the worry is the company that goes down a ULA path > when they should not out of ignorance or poor planning. > Then, 5, or 10 years on when they realize the mistake look at > the cost of renumbering and compare it to the cost of buying > off their ISP's. Forced to spend a few million dollars on > renumbering over six months, or to pay an extra $10k/month to > their ISP to route the prefix, they may well choose the latter. I can't imagine how IPv6 renumbering could cost anyone this much short of burning their IPv6 addresses into EPROMS in every device. > Already communities of interest are choosing the same ISP for > greater SLA's. They may not need it routed to the global > Internet, but rather you see ISP's routing these only > internal to their network and their customers. In essence, > the ULA boundry becomes the ISP, rather than the Enterprise. > It's an interesting situation, because it doesn't hurt the > "global" routing table, but it does put much the same > pressure on the ISP's backbone devices. Sounds fine to me. It's based on two-party agreements and the people incurring the cost get paid. If people want to do this kind of thing with ULA-C addresses, there is no reason for us to try and stop them. > We must plan for those who are short sighted, ignorant, lazy, > and simply dumb. No, that doesn't mean making their lives > easier, but it does mean finding ways to prevent them from > peeing in the pool and making it unsuitable for all. Bad attitude. To see what happens if that idea catches on, watch the film Idiocracy. People have to be allowed to make mistakes, fail and learn. In fact, you should expect any policy to have some failures built in, some corner cases where it works out badly. If a policy claims to have none of these, it is either a bad policy in masquerade, or it is a policy that nobody has examined closely. --Michael Dillon From owen at delong.com Mon Mar 22 15:47:40 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Mar 2010 12:47:40 -0700 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <28E139F46D45AF49A31950F88C497458058E296A@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458058E296A@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <497FE8F7-6725-4567-A788-C1B790EC2946@delong.com> On Mar 22, 2010, at 12:22 PM, wrote: > > >> Permanent allocations are an absolutely horrible idea. They >> create a monotonically decreasing resource which cannot be >> reclaimed when abandoned. Implementing such a thing reflects >> a failure to learn from our IPv4 experience. > > You are just playing semantic games. The meaning of a "permanent > allocation" will be defined by the global RIR policy. I fully > expect that policy to have some form of renewal process, and failure > to keep that up will cause the registrant to forfeit their block. > There will be some form of waiting period, perhaps 5 or 10 years, > after which the block is in play again, and might be snapped up > by a new registrant. Part of M&A due diligence will be to check the > status of any ULA-C blocks and if they are wholly unregistered > or forfeited, then you know that you are dealing with incompetent > network administration. That kind of thing increases the risk of > merging networks therefore depressing the value of the company. > If forfeiture becomes at all common, then after a few instances > in which companies failed to get themselves bought, or sold at > bargain prices, with this as a factor, you'll start to see > annual reports touting the fact that their IP addresses are > "in good standing" with the RIRs. > No, I'm not playing semantic games. Permanent Allocation has been used as a term in at least one of the ULA-C proposals which was specifically defined in said proposal as not requiring any form of renewal. > >> s/ULA/GUA-tainted/g >> And you've got exactly the same scenario as ULA-C. > > No. ULA-C addresses already exist and have been set aside > by IANA. There is currently no RFC or RIR policy defining > how they are used, so they are dormant. If you create > documents which use tainted GUA space for the same kind of > usage, then people will start to "pirate" the existing > ULA-C space. That is not the same scenario. > While the block remains reserved by IANA, the RFC attempting to implement it was deprecated or failed to achieve consensus (I don't remember which). I have no problem with assigning the ULA-C space to the RIRs to be administered as the pool of tainted GUA, but, GUA and GUA-tainted must be administered under identical qualification and cost structures or GUA-tainted becomes a tool for abuse. My point is that it is important to make sure there is no incentive to use GUA-tainted other than the desire to have your addresses tainted. I do not care which pool of numbers is set aside for GUA-tainted. I'm perfectly fine with it being the ULA-C prefix which is set aside for this purpose. > ULA-C exists. Now we have to put some rules around it, and > some management practices. > All of the proposals for rules around ULA-C involve alternative policies which create incentives to misuse ULA-C in such a way that it will eventually become GUA. Setting up identical policies which enable GUA and allow for those who want tainted GUA to get it just as easily, but, do not provide additional incentives for (mis)using tainted GUA will remove the incentive for this form of (mis)use because networks that do not specifically want their addresses tainted will receive addresses which can later be routed if they choose. >> A liberal GUA policy which: >> >> 1. Does not assume prefixes will be routed >> 2. Offers the user a choice of "tainted prefixes" >> if they choose >> 3. Is coupled with a modest fee structure (much more modest >> than the current fee structure, on the order of >> $300 initial >> and $50 annual, for example) >> >> Would offer pretty much all that is good about ULA-C without >> making it a tool for end-running addressing policy. > > > No. > > We have a small problem over here in the corner, dealing with > something analogous to private network addresses in IPv4, and > mainly concerning enterprise network architects. The solution > to that is *NOT* to change the rules for everybody, but to tidy > up the corner and make sure that it stays in the corner. > We can agree to disagree about that. I do not think that tidying up the corner by sweeping the dust into the global atmosphere is a better solution. ULA-C on a separate policy framework with a different fee structure will result in the eventual distortion of ULA into GUA usage. There are other problems which also call for more liberalized GUA policy. Solving multiple problems at once is not a bad thing. Owen From mcr at sandelman.ca Mon Mar 22 16:01:23 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 22 Mar 2010 16:01:23 -0400 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: References: <28E139F46D45AF49A31950F88C497458058E28AA@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <27220.1269288083@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Owen" == Owen DeLong writes: Owen> How does that pose a limit on the number of blocks they get? Owen> The process you have described allows a very large enterprise Owen> to get a ULA-C block for a lab, use it, tear it down, forget Owen> they ever had it and apply for another one 3 months later. Owen> Lather, rinse, repeat until you actually do manage to burn 40 Owen> bits worth of address space. You are right, we can burn 40 bits easily (recalling it's 0.4% of our address space). Assume 60,000,000 organizations as before. (Remember that due to recently discovered anomalies in how the universe is layered, each time you route v6 address space on top of another layer-4, such as when using an SSL VPN, you open a worm hole, which permits corporations registered in the 1800s to use address space as well) EACH one applies for a new /48 every 3 months. That's 240,000,000 /48s being consumed each year by these 60M unscrupulous labs. So, 4581 years (in the year 6591) the initial /8 that we allocate to this effort will be full. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBS6fMjYCLcPvd0N1lAQJ00wgAtlMcESwvGnk74hf+3kc6nclb2+DdCU+x /VToTlRAtQ9nfSPr4iUTDbujI0GsudvKlRBpZw7T3ZQGvNwQn2ikVZKZb512ubgp SSnPHQsQf4celoCNs8OllnAQ7pQPBD7qc4jpkXzr6ndj8NTVaRss/57M48pGoImZ pWxH3SQKLwEBcnLLf/iO6A/tmgHE7t5qQQJ0V3MsnQeCJ87kmfeqfxAXpSzKH6Ih LTyJEe8Lm9CQ5Zdv7ewwHwgCljGbEkavaIEMMo1yvhGM6xlJRZrt4EV7CsOW5EIB iDfqj8TjByP17kaL4y0gaT+iC594qr6u1ufStCHCCD3XkyTorNXtug== =95N3 -----END PGP SIGNATURE----- From mcr at sandelman.ca Mon Mar 22 16:08:27 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 22 Mar 2010 16:08:27 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: References: <28E139F46D45AF49A31950F88C497458058E2208@E03MVZ2-UKDY.domain1.systemhost.net> <9254.1269267155@marajade.sandelman.ca> Message-ID: <27748.1269288507@marajade.sandelman.ca> >>>>> "Owen" == Owen DeLong writes: >> It's not one ISP that customer with $$$$ has to convince, but >> *all* of them. A customer with that much money can certainly >> afford to buy globablly routable /48, or a /32 or something. Owen> If there were enough reliably good filtering, sure. There Owen> isn't, and, as long as one ISP somewhere accepts it, it'll get Owen> to a surprisingly large fraction of the internet and Owen> eventually, it'll end up getting accepted. Uhm. I thought: From: Owen DeLong Date: Mon, 22 Mar 2010 10:39:59 -0700 X-Mailer: Apple Mail (2.936) > If the answer is NO, then there are those that will argue that this will > be used as a run-around "routing" policy. > But the RIRs are not supposed to set "routing" policy. "Routing" policy is supposed to be set by those who actually run routers. ====== which is it? Does ARIN set routing policy or not? Owen> ULA-C isn't going to be blocks which don't work on the Owen> internet. It's going to be blocks which people expect not to Owen> work on the internet, but, really they do under some Owen> circumstances. End result, a false sense of security which is Owen> worse than no security. Owen> NAT != Security Address Obfuscation != Security Owen> Misconfiguration == Insecurity Owen> Belief otherwise merely increases risk. What's your point? Stupid people do stupid things? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr at sandelman.ca Mon Mar 22 16:18:01 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 22 Mar 2010 16:18:01 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <20100322183036.GA40906@ussenterprise.ufp.org> References: <28E139F46D45AF49A31950F88C497458058E2208@E03MVZ2-UKDY.domain1.systemhost.net> <9254.1269267155@marajade.sandelman.ca> <20100322183036.GA40906@ussenterprise.ufp.org> Message-ID: <28386.1269289081@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Leo" == Leo Bicknell writes: >> It's not one ISP that customer with $$$$ has to convince, but >> *all* of them. A customer with that much money can certainly >> afford to buy globablly routable /48, or a /32 or something. Leo> It's not that a smart, well run company can afford the cost up Leo> front; they can and will do the right thing. Leo> Rather, the worry is the company that goes down a ULA path when Leo> they should not out of ignorance or poor planning. Then, 5, or okay. Leo> Already communities of interest are choosing the same ISP for Leo> greater SLA's. They may not need it routed to the global Leo> Internet, but rather you see ISP's routing these only internal Leo> to their network and their customers. In essence, the ULA Sounds like a COIN to me. Sounds like *PROPER* application of a NCN to me. What is the problem? Leo> boundry becomes the ISP, rather than the Enterprise. It's an Leo> interesting situation, because it doesn't hurt the "global" Leo> routing table, but it does put much the same pressure on the Leo> ISP's backbone devices. ISP gets significant revenue, and significant lock in. Sounds like a win for the ISP. Said ISP could have used PA space too. Why should we have a address allocation policy preventing ISPs and customers from having this routing policy behind closed doors? Leo> We must plan for those who are short sighted, ignorant, lazy, Leo> and simply dumb. No, that doesn't mean making their lives Leo> easier, but it does mean finding ways to prevent them from Leo> peeing in the pool and making it unsuitable for all. It's not a pool. It's a VAST OCEAN. It's nice environmentalism to realize that even the oceans are not infinite, but it's not ARINs place. What you describe is a ROUTING POLICY. This concern over theoretical situations that have occured in IPv4-land only due to significant scarcity and only reported in "heresay" (due to NDA, etc.) are preventing deployment of IPv6 by many smaller, more innovative enterprises. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBS6fQeICLcPvd0N1lAQLjNAf/QPTBOQkiKC1Lg6rsRUOIQhnnch5bVp9J 04ZHoOIi/U4SuemA15BCUqQ1olEeEC+4N67qd94SYDmU6oVG3EGiS1eYfrvu0K5x R2mgaeHpPuNMJ484WNRAhYCp9Y2CSNI0E6fnV37uIQoWBEQGdoEFp5M4uieCjrXC jxrtSe3Epf0OIFYI/KxKuvuSPDIxdz1IaToL+lfnvEInWBcD9sdC0kOA7lm3KW4g hWilwcxU+JacCgeNOb2QzJ4Yy+ZkodiOCPHAlvhhaQrWEsQW8DwAEZln+0tVqDCD d69PleePgHPuCvMMVsKwP8JoX8aT5axhWvmCt6WmBYCmJwaIbw5FrA== =rnM/ -----END PGP SIGNATURE----- From mcr at sandelman.ca Mon Mar 22 16:31:47 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 22 Mar 2010 16:31:47 -0400 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <74FF650D-44AC-40DE-B518-12B3FCDE2EDE@delong.com> References: <28E139F46D45AF49A31950F88C497458058E287D@E03MVZ2-UKDY.domain1.systemhost.net> <24133.1269285338@marajade.sandelman.ca> <74FF650D-44AC-40DE-B518-12B3FCDE2EDE@delong.com> Message-ID: <30742.1269289907@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Owen" == Owen DeLong writes: >> I think that this is something to repeat multiple times. >> >> I think that a lot of people regard address space as so valuable >> that it would be crazy to "waste" it by having two IPs addresses >> on a single machine. >> >> This is where I think the notion that people will pay $$$$ to >> have their address space routed by ISPs. It won't happen --- >> getting new PA will be almost free, and getting PI address space >> is a nominal charge given that you have $$$$ for that bribe. Owen> Getting is cheap. Deploying is another matter. It is the Owen> desire to avoid the cost of deployment that will drive this, Owen> not the cost of the address space. Leo summed up one likely Owen> scenario rather well. I disagree strongly. This is not IPv4. Maybe some organizations prefer to bribe their ISP. Why is it is ARIN's business to set routing policy? Owen> Riddle me this... When you have a Link-Local, ULA-C, and a GUA Owen> address, how does one decide when to originate a connection Owen> from the GUA and when to use the ULA-C address? Owen> Until you have an answer for that that does not require Owen> updating applications, the multiple different-capability Owen> addresses per interface is a nice theory that is fraught with Owen> operational peril. RFC3484 describes this: Default Address Selection for Internet Protocol version 6 (IPv6) published Feb.2003. If you know the IETF of the early 2000s, some drafts took many many months to get through the queue, so this represents 10 year old work. On my Linux desktop I have a configuration file /etc/gai.conf that lets me tweak some of the values. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBS6fTsYCLcPvd0N1lAQLnEQf/YPYIhS5xWhClPcggfyeRdrdzYwVF3Bq0 V5rv+TAq4bJu8EDo8YkDrQpaDSuIEoDH5d83wJGRrt03d33umBs97mxzFXSOgWjN 7FkUwh7JZ7hVCImkGnrsuWvXPIKgt2200ytC6OhXh6ThMQ9eC5ucfudjmX0+jgRx rh4lpkY9k4lvt3Ezxi7nYJoZICiQ3PM1v0zydJKzcdULkZw6NElqj6JP9qBuJ+ug RtZUmQf8JePhGCRhViMWrzWnQ0IXoFHencWLh9AY3XKWcA8/vArld7QD3MX76xPx uI5+IJFe1GSVuLd4DErJAYkTqdvQ/P+O84rwvZm7aTXqaBYHdfAM5w== =tf0L -----END PGP SIGNATURE----- From mcr at sandelman.ca Mon Mar 22 16:33:20 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 22 Mar 2010 16:33:20 -0400 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <28E139F46D45AF49A31950F88C497458058E296A@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458058E296A@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <30849.1269290000@marajade.sandelman.ca> >>>>> "michael" == michael dillon writes: >> Would offer pretty much all that is good about ULA-C without >> making it a tool for end-running addressing policy. michael> No. michael> We have a small problem over here in the corner, dealing michael> with something analogous to private network addresses in michael> IPv4, and mainly concerning enterprise network michael> architects. The solution to that is *NOT* to change the michael> rules for everybody, but to tidy up the corner and make michael> sure that it stays in the corner. What he said. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From owen at delong.com Mon Mar 22 16:40:54 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Mar 2010 13:40:54 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <27748.1269288507@marajade.sandelman.ca> References: <28E139F46D45AF49A31950F88C497458058E2208@E03MVZ2-UKDY.domain1.systemhost.net> <9254.1269267155@marajade.sandelman.ca> <27748.1269288507@marajade.sandelman.ca> Message-ID: <12905003-1701-4E87-A147-DE2F64B08539@delong.com> On Mar 22, 2010, at 1:08 PM, Michael Richardson wrote: > >>>>>> "Owen" == Owen DeLong writes: >>> It's not one ISP that customer with $$$$ has to convince, but >>> *all* of them. A customer with that much money can certainly >>> afford to buy globablly routable /48, or a /32 or something. > > Owen> If there were enough reliably good filtering, sure. There > Owen> isn't, and, as long as one ISP somewhere accepts it, it'll get > Owen> to a surprisingly large fraction of the internet and > Owen> eventually, it'll end up getting accepted. > > Uhm. I thought: > > From: Owen DeLong > Date: Mon, 22 Mar 2010 10:39:59 -0700 > X-Mailer: Apple Mail (2.936) > > >> If the answer is NO, then there are those that will argue that this will >> be used as a run-around "routing" policy. >> > But the RIRs are not supposed to set "routing" policy. "Routing" policy > is supposed to be set by those who actually run routers. > > > ====== > > which is it? > Does ARIN set routing policy or not? > ARIN doesn't set routing policy, but, ARIN does set addressing policy. Absent sufficient reliable filtration, ULA-C under a different set of rules from GUA serves as an end-run on those addressing policies. > Owen> ULA-C isn't going to be blocks which don't work on the > Owen> internet. It's going to be blocks which people expect not to > Owen> work on the internet, but, really they do under some > Owen> circumstances. End result, a false sense of security which is > Owen> worse than no security. > > Owen> NAT != Security Address Obfuscation != Security > Owen> Misconfiguration == Insecurity > > Owen> Belief otherwise merely increases risk. > > What's your point? > Stupid people do stupid things? I guess my primary point is that enabling them to do stupid things to the detriment of the internet in general seems like a stupid thing to do. Owen From michael.dillon at bt.com Mon Mar 22 16:43:57 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Mar 2010 20:43:57 -0000 Subject: [arin-ppml] ULA-C and reverse DNS Message-ID: <28E139F46D45AF49A31950F88C497458058E29AA@E03MVZ2-UKDY.domain1.systemhost.net> Corrected fragment below. As some may have guessed, I really meant to say /23. ------------------ Am I confused here? Didn't our experiences with the swamp give us VLSM and CIDR? These are good things. As is the whole ARIN policy process which also was driven by experiences in the swamp. I remember when I could ask for a /23 allocation, and get two adjacent but non-aggregatable swamp /24 blocks instead. That was due to lack of process, and lack of oversight. The swamp was a good thing. It also drove vendors to better algorithms in the routers (Patricia tries?) and better hardware (TCAMs). --Michael Dillon From farmer at umn.edu Mon Mar 22 16:52:04 2010 From: farmer at umn.edu (David Farmer) Date: Mon, 22 Mar 2010 15:52:04 -0500 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <17992.1269279843@marajade.sandelman.ca> References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net> <4BA76279.9060809@umn.edu> <07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com> <10731.1269268570@marajade.sandelman.ca> <4BA788C6.3090703@umn.edu> <17992.1269279843@marajade.sandelman.ca> Message-ID: <4BA7D874.5080309@umn.edu> Michael Richardson wrote: >>>>>> "David" == David Farmer writes: > >> But: a) Is the price the same as for GUA? b) Is the > >> needs-requirement the same? If the answer is YES, then it's not > >> a policy. Its status quo. If the answer is NO, then there are > >> those that will argue that this will be used as a run-around > >> "routing" policy. > > David> Are you suggesting that each sub part of an enterprise should > David> be able get its own /48? Are you suggesting there should be > David> no limit to the number of /48s a enterprise can get? It > David> sounds to me like that is what you are suggesting. > > Yes. > > 1,099,511,627,776 Number of /48s in a /8 > 6,692,030,277 population of planet in 2008. > > That's 164 /48s for every man/woman/child. Since I don't see how you are recycling any of the ULA-C in the process you are talking about, you need to factor in the death and birth rates (using 2008 figures) at 50 years it is about the population. So that is more like half that per person or about 82 per person. Yes, it is still a lot, but that is only about one /48 per person per year of their life or so. Also, I'm sure some will want and justify larger than just a /48 at a time. That reduces it some more. > There is no scarcity. Stop thinking like there is. > These networks are not connected and would be labelled as such. There is no scarcity, and I don't think there will ever be one if we can be a little rational about how we give things out. Furthermore, if we create a process that recycles numbers that are no longer in use, I'll bet we can virtually guarantee that there will never be a scarcity. The fact that there is no scarcity, is no excuse to be overly wasteful and to not think things through. I know it is hard for people that work for organizations that think 2 to 5 year planning horizon are a long time. But, we should be thinking about 50 to 100 year planning horizon on this one. This is easily possible given the size of number space and the complete lack of scarcity that exists in IPv6. There is no reason for the 128bit address field to be the driving factor for the next version of IP. Other issues will likely be the driver for a new version of IP in the future, if or when that day comes. Without some kind of limit or back pressure and with the trivial expense and justification that I've seen talked about there, it is not hard for me to imagine a large number of organizations that could consume thousands of ULA-C /48 blocks. Some kind of back pressure to cause multiple groups from within the same organization requesting blocks to try to organize their requests and a mechanism that will effect the return unused blocks, would go a long way to providing long-term sustainability for ULA-C. So no, there is not a scarcity, but thinking about sustainability now will prevent problems in the long-term future. Also, creating sustainable solutions is the best way for the technical community to retail control of these issues and not have the political powers of governments step in. Please remember that ITU thread. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From owen at delong.com Mon Mar 22 16:54:51 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Mar 2010 13:54:51 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <28386.1269289081@marajade.sandelman.ca> References: <28E139F46D45AF49A31950F88C497458058E2208@E03MVZ2-UKDY.domain1.systemhost.net> <9254.1269267155@marajade.sandelman.ca> <20100322183036.GA40906@ussenterprise.ufp.org> <28386.1269289081@marajade.sandelman.ca> Message-ID: <4A880690-3EF4-49DC-9CCE-783ADEB34EBF@delong.com> On Mar 22, 2010, at 1:18 PM, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "Leo" == Leo Bicknell writes: >>> It's not one ISP that customer with $$$$ has to convince, but >>> *all* of them. A customer with that much money can certainly >>> afford to buy globablly routable /48, or a /32 or something. > > Leo> It's not that a smart, well run company can afford the cost up > Leo> front; they can and will do the right thing. > > Leo> Rather, the worry is the company that goes down a ULA path when > Leo> they should not out of ignorance or poor planning. Then, 5, or > > okay. > > Leo> Already communities of interest are choosing the same ISP for > Leo> greater SLA's. They may not need it routed to the global > Leo> Internet, but rather you see ISP's routing these only internal > Leo> to their network and their customers. In essence, the ULA > > Sounds like a COIN to me. > Sounds like *PROPER* application of a NCN to me. > > What is the problem? > > Leo> boundry becomes the ISP, rather than the Enterprise. It's an > Leo> interesting situation, because it doesn't hurt the "global" > Leo> routing table, but it does put much the same pressure on the > Leo> ISP's backbone devices. > > ISP gets significant revenue, and significant lock in. > Sounds like a win for the ISP. Said ISP could have used PA space too. > > Why should we have a address allocation policy preventing ISPs and > customers from having this routing policy behind closed doors? > We shouldn't. The bigger question is why do we need an addressing policy which relegates this to a separate fraction of address space rather than simply letting addresses be addresses and allowing ISPs and their customers to determine the routing policy on a block-by-block basis. > Leo> We must plan for those who are short sighted, ignorant, lazy, > Leo> and simply dumb. No, that doesn't mean making their lives > Leo> easier, but it does mean finding ways to prevent them from > Leo> peeing in the pool and making it unsuitable for all. > > It's not a pool. It's a VAST OCEAN. It's nice environmentalism to > realize that even the oceans are not infinite, but it's not ARINs place. > Sure it is. ARIN is charged with stewardship of that particular ocean and environmentalism is exactly their charter. > What you describe is a ROUTING POLICY. > What he describes is routing consequence. There is a difference between policies which dictate routing and considering the routing consequences of a candidate policy. > This concern over theoretical situations that have occured in IPv4-land > only due to significant scarcity and only reported in "heresay" (due to > NDA, etc.) are preventing deployment of IPv6 by many smaller, more > innovative enterprises. Here, I must disagree. A liberalized PI policy would serve those smaller more innovative enterprises at least as well as ULA-C, if not better. Especially if it provided for an equal ability to get "tainted" addresses on request. Owen From owen at delong.com Mon Mar 22 17:50:39 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Mar 2010 14:50:39 -0700 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <30742.1269289907@marajade.sandelman.ca> References: <28E139F46D45AF49A31950F88C497458058E287D@E03MVZ2-UKDY.domain1.systemhost.net> <24133.1269285338@marajade.sandelman.ca> <74FF650D-44AC-40DE-B518-12B3FCDE2EDE@delong.com> <30742.1269289907@marajade.sandelman.ca> Message-ID: <0B420FAC-CC61-439D-94F7-4C1E09C95FA9@delong.com> On Mar 22, 2010, at 1:31 PM, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "Owen" == Owen DeLong writes: >>> I think that this is something to repeat multiple times. >>> >>> I think that a lot of people regard address space as so valuable >>> that it would be crazy to "waste" it by having two IPs addresses >>> on a single machine. >>> >>> This is where I think the notion that people will pay $$$$ to >>> have their address space routed by ISPs. It won't happen --- >>> getting new PA will be almost free, and getting PI address space >>> is a nominal charge given that you have $$$$ for that bribe. > > Owen> Getting is cheap. Deploying is another matter. It is the > Owen> desire to avoid the cost of deployment that will drive this, > Owen> not the cost of the address space. Leo summed up one likely > Owen> scenario rather well. > > I disagree strongly. This is not IPv4. > Maybe some organizations prefer to bribe their ISP. > > Why is it is ARIN's business to set routing policy? > It's not. However, if people are going to present arguments claiming something won't happen because X, then, if X is specious, I will point that out. > Owen> Riddle me this... When you have a Link-Local, ULA-C, and a GUA > Owen> address, how does one decide when to originate a connection > Owen> from the GUA and when to use the ULA-C address? > > Owen> Until you have an answer for that that does not require > Owen> updating applications, the multiple different-capability > Owen> addresses per interface is a nice theory that is fraught with > Owen> operational peril. > > RFC3484 describes this: > Default Address Selection for Internet Protocol version 6 (IPv6) > And the mechanism for maintaining this "policy table" defined in section 2.1 are still missing from any implementation I'm aware of. (No, I don't consider rsync a scalable solution to this problem). Leaving network stack source address selection up to the local administrator of the host is a far from ideal solution. Basically you're passing routing policy to the systems administrator and taking it away from the network administrator. What is needed is a way for RA/DHCPv6 to affect this decision. Let's look at an example, Host A with one of each (link local, ULA-C, GUA) wants to talk to Host B with Link local+GUA on a remote network. Rule 1 does not apply, no equal addresses. As I read Rule 2 of the Source Address selection algorithm proposed, UAL and GUA would both have Scope: Global. The link local is eliminated by this rule. Rule 3 doesn't apply in this case (neither is deprecated) Rule 4 doesn't apply, let's not complicate the example with IP mobility. Rule 5 doesn't help, both addresses are on the same interface. Rule 6 Since we're assuming no changes to application, labels do not apply. Rule 7 No temporary addresses involved, does not apply. Rule 8 is where we hit paydirt. Because only the first 3 bits are common on the global unicast prefix, but, the first 8 bits are common in the ULA-C prefix, we will choose the ULA-C prefix, even though it cannot reach the destination. -- FAIL! Interestingly there is a second rule 2 after rule 8 which talks about scope as preferring appropriate scope. I think this is a typo. I cannot tell whether this should be incorporated into the rule 2 in the logical location or whether this was an older rule 2 which was supposed to be superseded by newer rules 2-8. My best guess is the latter to be the case. > published Feb.2003. If you know the IETF of the early 2000s, some drafts > took many many months to get through the queue, so this represents 10 > year old work. > Yep. > On my Linux desktop I have a configuration file /etc/gai.conf that lets > me tweak some of the values. > Good thing, otherwise, rule 8 would screw you royally on a regular basis. Owen > - -- > ] He who is tired of Weird Al is tired of life! | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > Kyoto Plus: watch the video > then sign the petition. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Finger me for keys > > iQEVAwUBS6fTsYCLcPvd0N1lAQLnEQf/YPYIhS5xWhClPcggfyeRdrdzYwVF3Bq0 > V5rv+TAq4bJu8EDo8YkDrQpaDSuIEoDH5d83wJGRrt03d33umBs97mxzFXSOgWjN > 7FkUwh7JZ7hVCImkGnrsuWvXPIKgt2200ytC6OhXh6ThMQ9eC5ucfudjmX0+jgRx > rh4lpkY9k4lvt3Ezxi7nYJoZICiQ3PM1v0zydJKzcdULkZw6NElqj6JP9qBuJ+ug > RtZUmQf8JePhGCRhViMWrzWnQ0IXoFHencWLh9AY3XKWcA8/vArld7QD3MX76xPx > uI5+IJFe1GSVuLd4DErJAYkTqdvQ/P+O84rwvZm7aTXqaBYHdfAM5w== > =tf0L > -----END PGP SIGNATURE----- > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From cengel at sponsordirect.com Mon Mar 22 18:34:21 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Mon, 22 Mar 2010 18:34:21 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: Message-ID: Owen Delong wrote: # ULA-C isn't going to be blocks which don't work on the internet. It's # going to be blocks which people expect not to work on the internet, but, # really they do under some circumstances. End result, a false sense of security which is # worse than no security. # NAT != Security # Address Obfuscation != Security # Misconfiguration == Insecurity # Belief otherwise merely increases risk. I've got to take some issue with your above statements Owen. NAT and Address Obfuscation ARE security mechanisms (albiet not fool-proof ones, but I've yet to see a fool-proof mechanism). Most Enterprise Admins I know commonly regard them as such...MOST dedicated IT Security people I've talked to regard them as such. PCI reg's require them as such... and pretty much every security audit I've been through that involves a regulated industry (Financial, Health, etc) has included them as such. You may think we're all pretty much brain-dead for thinking so....but there IS a pretty strong consensus there among people who actualy get paid specificaly for IT Security. Realisticaly RFC 1918 space (the space people use with NAT in IPv4) tends to fail closed rather then open and that's the botom line. 99.99% of the worlds routers aren't going to have a route in thier routing tables for RFC1918 space that leads to my network. If you hit my external router with a RFC1918 address it's not going to know to send it to my firewall or internal network.... and if you hit my firewalls external interface with a request for an RFC 1918 address, it's going to tell you to get lost because it's got no entry in it's table for an address on that interface that corresponds to it. Practicaly speaking.... using that space tends to DECREASE the damage done when a misconfiguration occurs... in my dictionary, we call something that does that a "Security Mechanism". I will agree that ULA-C sounds like a bit of a different animal though, as it would be registered to a particular organization and therefore unique to it. Personaly, I would just end up using what you guys are terming ULA-Random for private space.... but I can see why an organization might want to grab space that is uniquely assigned to it but generaly recognized not to be routed. If you ARE looking for Private space.... you are better off going with something that is indicated it SHOULD NOT be routed (ULA-C).... even if that indication is ignored sometimes then going with something that provides no indication at all (GUA). Not addressing the other aspects of it...like fee's, etc.... just this one aspect. Personaly, I would use split DNS anyways....don't really like the idea of advertising internal host names & IP's in a publicaly accessable zone somewhere....but that's just me. Christopher Engel From bill at herrin.us Mon Mar 22 18:50:19 2010 From: bill at herrin.us (William Herrin) Date: Mon, 22 Mar 2010 18:50:19 -0400 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <3c3e3fca1003221550o5f2753d2ibbce366b9e0eb214@mail.gmail.com> On Mon, Mar 22, 2010 at 7:03 AM, wrote: > Addresses intended for use on the public Internet come with > reverse DNS delegations, but ULA-C addresses only come with > guaranteed global uniqueness. Michael, This doesn't make sense to me. It seems like the RDNS should be registrant's choice. If they don't want public RDNS, fine. If they want public RDNS pointing into the ULA space so that leaky DNS servers find their way back inside, fine. If they want public RDNS pointing to routed address space, still fine. I think would personally want my DNS to lead back to my ULA-side DNS servers so that folks in my private internetwork could find their way to my servers by name without having to implement a shared private DNS root. Remember, the whole point of ULA (instead of just a repeat of RFC1918) is to *facilitate* connecting private networks together. Making them somehow manage a DNS root infrastructure seems like it would be the opposite of facilitate... Particularly when you consider that A and B may both connect to C but A might not pass packets with B and he may connect to D who doesn't pass packets with C or B. Systemically, RDNS may not be possible in these interconnected private networks without a boost from Internet's DNS system. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Mon Mar 22 19:01:20 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Mar 2010 16:01:20 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: References: Message-ID: On Mar 22, 2010, at 3:34 PM, Chris Engel wrote: > > > Owen Delong wrote: > > > > # ULA-C isn't going to be blocks which don't work on the internet. It's > # going to be blocks which people expect not to work on the internet, but, > # really they do under some circumstances. End result, a false sense of security which is > # worse than no security. > > # NAT != Security > # Address Obfuscation != Security > # Misconfiguration == Insecurity > > # Belief otherwise merely increases risk. > > > I've got to take some issue with your above statements Owen. NAT and Address Obfuscation ARE security mechanisms (albiet not fool-proof ones, but I've yet to see a fool-proof mechanism). Most Enterprise Admins I know commonly regard them as such...MOST dedicated IT Security people I've talked to regard them as such. PCI reg's require them as such... and pretty much every security audit I've been through that involves a regulated industry (Financial, Health, etc) has included them as such. > Nope... Stateful inspection is a security mechanism. NAT and Address Obfuscation are crutches which most people use to make sure that Stateful Inspection is working because they cannot work without it. The mere fact that this myth is wide spread among things like PCI does not make it any more accurate. > You may think we're all pretty much brain-dead for thinking so....but there IS a pretty strong consensus there among people who actualy get paid specificaly for IT Security. > Actually, most of the people I know who get paid for IT security, including a number who are responsible for it in environments where physical access is protected by fingerprint and retinal scanners and guards carrying firearms, agree that this is a widespread myth. > Realisticaly RFC 1918 space (the space people use with NAT in IPv4) tends to fail closed rather then open and that's the botom line. 99.99% of the worlds routers aren't going to have a route in thier routing tables for RFC1918 space that leads to my network. If you hit my external router with a RFC1918 address it's not going to know to send it to my firewall or internal network.... and if you hit my firewalls external interface with a request for an RFC 1918 address, it's going to tell you to get lost because it's got no entry in it's table for an address on that interface that corresponds to it. > RFC-1918 provides some measure of closed failure because the addresses overlap so a leak is contained by virtue of the fact that worst-case it's an anycast candidate destination for a limited scope of the internet. However, that closed failure is far from reliable, thus, providing more of a false sense of security than actual security. ULA-C, however, wouldn't have this overlapping address property, thus further reducing the efficacy of this supposed closed failure. I'm assuming that if I hit your firewall with a GUA on your internal network, the ruleset wouldn't let the packet in unless it conformed to other properties that specified an intended public service. I don't see a difference between getting an RFC-1918 destination address to your firewall and a GUA that belongs to some other network. Both should and would be rejected. Assuming proper configuration, the same would happen with a packet to a valid GUA on your network that isn't used for providing public services. > Practicaly speaking.... using that space tends to DECREASE the damage done when a misconfiguration occurs... in my dictionary, we call something that does that a "Security Mechanism". > OK, I'll accept that using address space which is guaranteed to overlap some fraction of other users can be called a "security mechanism", albeit a very weak one. However, I will say: Security Mechanism != Security Security == Security Mechanisms[n] properly applied where n >1 and usually n>3 > I will agree that ULA-C sounds like a bit of a different animal though, as it would be registered to a particular organization and therefore unique to it. Personaly, I would just end up using what you guys are terming ULA-Random for private space.... but I can see why an organization might want to grab space that is uniquely assigned to it but generaly recognized not to be routed. If you ARE looking for Private space.... you are better off going with something that is indicated it SHOULD NOT be routed (ULA-C).... even if that indication is ignored sometimes then going with something that provides no indication at all (GUA). Not addressing the other aspects of it...like fee's, etc.... just this one aspect. > My proposal was for a block which I've termed "GUA-Tainted" instead of ULA-C only to distinguish the fact that the tainted block is administered under the same allocation policies as GUA so that it does not offer an incentive to (mis)use ULA-C as GUA. Afterall, if the world de facto starts routing ULA-C, then, your purpose for it suffers right along side of the internet addressing policies that it would circumvent. In other words, I don't think we are disagreeing about substance, but, about form. > Personaly, I would use split DNS anyways....don't really like the idea of advertising internal host names & IP's in a publicaly accessable zone somewhere....but that's just me. > Exactly. I'm all for letting those that want to use split DNS do so, but, making it easy for those that do not want to as well. I want to put choice in the hand of the end user and their ISP. In summary: Current situation: ULA-C Proposed, previously deprecated RFC which does not conform to current GUA allocation policies - Provides a cost incentive to use this instead of GUA in environments where GUA may be desirable. - Provides a policy incentive (easier to get) vs. GUA in environments where GUA may be desirable. GUA Existing, Globally Unique Addresses. What we're all used to getting from the RIRs already. Generally expected to be used for connecting to the internet, limited to organizations meeting certain (arbitrary minimum criteria) Routing Table Size aspects of routing policy Abdicated by ISPs to management by the RIRs (sort of) My proposed alternative: GUA Much like GUA in the current situation, but, easier to get and not limited by (arbitrary) minimum organization size/topology criteria. GUA-Tainted Much like the ULA-C proposal. Could even come from ULA-C block. A block set aside specifically for networks that want addresses known to not be routable on the internet. Routing Policy Entirely the purview of ISPs and their customer(s)/user(s). The difference: A relaxed criteria for GUA and GUA-Tainted allows both types of addresses to be allocated in such a way that the only difference between them is the preference of the receiving organization as to which type of address they want, thus removing any incentives that would exist for the use of ULA-C in a context more appropriate to GUA. I hope this clarifies that I am not opposed to the concept of private addresses. I am opposed to creating a situation where private addresses are likely to be (ab)used as global addresses thus reducing their utility for both purposes. Owen From mcr at sandelman.ca Mon Mar 22 20:40:25 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 22 Mar 2010 20:40:25 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <12905003-1701-4E87-A147-DE2F64B08539@delong.com> References: <28E139F46D45AF49A31950F88C497458058E2208@E03MVZ2-UKDY.domain1.systemhost.net> <9254.1269267155@marajade.sandelman.ca> <27748.1269288507@marajade.sandelman.ca> <12905003-1701-4E87-A147-DE2F64B08539@delong.com> Message-ID: <16990.1269304825@marajade.sandelman.ca> >>>>> "Owen" == Owen DeLong writes: >> >>>>>>> "Owen" == Owen DeLong writes: >>>> It's not one ISP that customer with $$$$ has to convince, but >>>> *all* of them. A customer with that much money can certainly >>>> afford to buy globablly routable /48, or a /32 or something. >> Owen> If there were enough reliably good filtering, sure. There Owen> isn't, and, as long as one ISP somewhere accepts it, it'll get Owen> to a surprisingly large fraction of the internet and Owen> eventually, it'll end up getting accepted. >> Uhm. I thought: >> >> From: Owen DeLong Date: Mon, 22 Mar 2010 >> 10:39:59 -0700 X-Mailer: Apple Mail (2.936) >> >> >>> If the answer is NO, then there are those that will argue that >>> this will be used as a run-around "routing" policy. >>> >> But the RIRs are not supposed to set "routing" policy. "Routing" >> policy is supposed to be set by those who actually run routers. >> >> >> ====== >> >> which is it? Does ARIN set routing policy or not? >> Owen> ARIN doesn't set routing policy, but, ARIN does set addressing Owen> policy. Owen> Absent sufficient reliable filtration, ULA-C under a different Owen> set of rules from GUA serves as an end-run on those addressing Owen> policies. So what I hear you saying is that, since one can't write routing policy (i.e. "reliable filtration"), one has to write routing policy in the form of addressing policy. Which is why I keep coming back to the point that the objections to NNC seems to be because it violates some unwritten routing policy. What I hear is that private enterprises are not permitted to implement routing policy behind closed doors if it violates the "addressing" policy in question. If in fact ARIN is not in the business of regulating routing policy, then it should stop trying to do that via addressing policy. DFZ slots cost money, it is true. In IPv4 land, because addresses were scarce and DFZ slots are a commons, one can get a handle on DFZ slot allocations via allocation policy. In IPv6 land, linking a DFZ slot to allocation policy is not only wrong, but it is a major disincentive towards deployment of IPv6. Please stop trying regulate a market that is outside of your mandate. What is this quest to keep stupid people from doing stupid things? This quest is keeping the rest of us from doing smart things. (Well, back to IETF work) -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr at sandelman.ca Mon Mar 22 20:41:21 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 22 Mar 2010 20:41:21 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4A880690-3EF4-49DC-9CCE-783ADEB34EBF@delong.com> References: <28E139F46D45AF49A31950F88C497458058E2208@E03MVZ2-UKDY.domain1.systemhost.net> <9254.1269267155@marajade.sandelman.ca> <20100322183036.GA40906@ussenterprise.ufp.org> <28386.1269289081@marajade.sandelman.ca> <4A880690-3EF4-49DC-9CCE-783ADEB34EBF@delong.com> Message-ID: <17061.1269304881@marajade.sandelman.ca> >>>>> "Owen" == Owen DeLong writes: >> This concern over theoretical situations that have occured in >> IPv4-land only due to significant scarcity and only reported in >> "heresay" (due to NDA, etc.) are preventing deployment of IPv6 by >> many smaller, more innovative enterprises. Owen> Here, I must disagree. A liberalized PI policy would serve Owen> those smaller more innovative enterprises at least as well as Owen> ULA-C, if not better. Especially if it provided for an equal Owen> ability to get "tainted" addresses on request. If "tainted" address space is $10, then great. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr at sandelman.ca Mon Mar 22 20:48:52 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 22 Mar 2010 20:48:52 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: References: Message-ID: <17546.1269305332@marajade.sandelman.ca> >>>>> "Chris" == Chris Engel writes: Chris> Owen Delong wrote: Chris> # ULA-C isn't going to be blocks which don't work on the Chris> internet. It's # going to be blocks which people expect not Chris> to work on the internet, but, # really they do under some Chris> circumstances. End result, a false sense of security which Chris> is # worse than no security. Chris> # NAT != Security # Address Obfuscation != Security # Chris> Misconfiguration == Insecurity Chris> # Belief otherwise merely increases risk. Chris> I've got to take some issue with your above statements Chris> Owen. NAT and Address Obfuscation ARE security mechanisms Chris> (albiet not fool-proof ones, but I've yet to see a fool-proof This is what security experts (LIKE MYSELF) call: depth-in-security I regularly argue with these johnny-come-lately security "experts", because they rarely understand the tradeoffs of each layer of security. The major advantage of ULA-C is that is provides a much better way to audit what is what, particularly when there are multiple organizations connecting together in various ways. It also permits sane auditing of multiple remote-access connections from laptops/etc. for visiting consultants, etc. ULA-C for NCN is much more robust than "tainted" GUA as far as failing closed. But, for it to have any value over RFC1918 (i.e. NOT USING IPv6), it has to solve problems which RFC1918 has caused. Split-DNS is one of those things. (I started implementing split-DNS systems back in 1992... It was useable then because nobody had laptops. By the time it became universal for enterprises, it was unworkably useless, and /etc/hosts or literal IPs began to replace it) -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr at sandelman.ca Mon Mar 22 21:35:31 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 22 Mar 2010 21:35:31 -0400 Subject: [arin-ppml] ULA-C and reverse DNS In-Reply-To: <3c3e3fca1003221550o5f2753d2ibbce366b9e0eb214@mail.gmail.com> References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net> <3c3e3fca1003221550o5f2753d2ibbce366b9e0eb214@mail.gmail.com> Message-ID: <20944.1269308131@marajade.sandelman.ca> >>>>> "William" == William Herrin writes: William> Remember, the whole point of ULA (instead of just a repeat William> of RFC1918) is to *facilitate* connecting private networks William> together. Making them somehow manage a DNS root William> infrastructure seems like it would be the opposite of William> facilitate... Particularly when you consider that A and B William> may both connect to C but A might not pass packets with B William> and he may connect to D who doesn't pass packets with C or William> B. Systemically, RDNS may not be possible in these William> interconnected private networks without a boost from William> Internet's DNS system. Yes. Getting rid of private root DNS is a "savings" of moving to IPv6. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From owen at delong.com Mon Mar 22 22:57:41 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Mar 2010 19:57:41 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <17061.1269304881@marajade.sandelman.ca> References: <28E139F46D45AF49A31950F88C497458058E2208@E03MVZ2-UKDY.domain1.systemhost.net> <9254.1269267155@marajade.sandelman.ca> <20100322183036.GA40906@ussenterprise.ufp.org> <28386.1269289081@marajade.sandelman.ca> <4A880690-3EF4-49DC-9CCE-783ADEB34EBF@delong.com> <17061.1269304881@marajade.sandelman.ca> Message-ID: <158D0231-44EF-4F31-8114-50FA07C02EA3@delong.com> On Mar 22, 2010, at 5:41 PM, Michael Richardson wrote: > >>>>>> "Owen" == Owen DeLong writes: >>> This concern over theoretical situations that have occured in >>> IPv4-land only due to significant scarcity and only reported in >>> "heresay" (due to NDA, etc.) are preventing deployment of IPv6 by >>> many smaller, more innovative enterprises. > > Owen> Here, I must disagree. A liberalized PI policy would serve > Owen> those smaller more innovative enterprises at least as well as > Owen> ULA-C, if not better. Especially if it provided for an equal > Owen> ability to get "tainted" addresses on request. > > If "tainted" address space is $10, then great. > It won't be $10. It shouldn't be $10. It shouldn't be a whole lot more than that. I'm thinking on the order of $50/year, tainted or otherwise. Owen From owen at delong.com Mon Mar 22 23:04:05 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Mar 2010 20:04:05 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <16990.1269304825@marajade.sandelman.ca> References: <28E139F46D45AF49A31950F88C497458058E2208@E03MVZ2-UKDY.domain1.systemhost.net> <9254.1269267155@marajade.sandelman.ca> <27748.1269288507@marajade.sandelman.ca> <12905003-1701-4E87-A147-DE2F64B08539@delong.com> <16990.1269304825@marajade.sandelman.ca> Message-ID: On Mar 22, 2010, at 5:40 PM, Michael Richardson wrote: > >>>>>> "Owen" == Owen DeLong writes: > >>> >>>>>>>> "Owen" == Owen DeLong writes: >>>>> It's not one ISP that customer with $$$$ has to convince, but >>>>> *all* of them. A customer with that much money can certainly >>>>> afford to buy globablly routable /48, or a /32 or something. >>> > Owen> If there were enough reliably good filtering, sure. There > Owen> isn't, and, as long as one ISP somewhere accepts it, it'll get > Owen> to a surprisingly large fraction of the internet and > Owen> eventually, it'll end up getting accepted. >>> Uhm. I thought: >>> >>> From: Owen DeLong Date: Mon, 22 Mar 2010 >>> 10:39:59 -0700 X-Mailer: Apple Mail (2.936) >>> >>> >>>> If the answer is NO, then there are those that will argue that >>>> this will be used as a run-around "routing" policy. >>>> >>> But the RIRs are not supposed to set "routing" policy. "Routing" >>> policy is supposed to be set by those who actually run routers. >>> >>> >>> ====== >>> >>> which is it? Does ARIN set routing policy or not? >>> > Owen> ARIN doesn't set routing policy, but, ARIN does set addressing > Owen> policy. > > Owen> Absent sufficient reliable filtration, ULA-C under a different > Owen> set of rules from GUA serves as an end-run on those addressing > Owen> policies. > > So what I hear you saying is that, since one can't write routing policy > (i.e. "reliable filtration"), one has to write routing policy in the > form of addressing policy. > I don't consider filtration of bogons to be routing policy so much as a mechanism to enforce addressing policy. If it is a matter of addressing policy to claim that "these addresses are reserved for purposes not including routing on the global internet", then, it is a matter of addressing policy to be able to rely on some mechanism to prevent that, or, recognize that such an addressing policy is unlikely to be respected. > Which is why I keep coming back to the point that the objections to NNC > seems to be because it violates some unwritten routing policy. > I don't object to NCN. I object to NCN on different terms from GUA which encourage the possibility of abuse of the NCN which would degrade the utility of NCN for either the NCN purpose or the "it's not usable as GUA" purpose. > What I hear is that private enterprises are not permitted to implement > routing policy behind closed doors if it violates the "addressing" > policy in question. > If in fact ARIN is not in the business of regulating routing policy, > then it should stop trying to do that via addressing policy. > DFZ slots cost money, it is true. > Actually, I don't care what you do behind closed doors. However, if it's truly behind closed doors, then, you don't need to globally coordinate it, you can create a registry behind those same closed doors to handle it. What I'm saying is that if you want ARIN and/or the RIRs in general involved, it should be done in such a way that it does not become a well known easy path to end-running GUA policies set by the RIR system. > In IPv4 land, because addresses were scarce and DFZ slots are a commons, > one can get a handle on DFZ slot allocations via allocation policy. > Agreed. > In IPv6 land, linking a DFZ slot to allocation policy is not only wrong, > but it is a major disincentive towards deployment of IPv6. > Agreed. > Please stop trying regulate a market that is outside of your mandate. > I'm not trying to do any such thing. I want GUA to be easy and cheap for all. I want it untied from routing. I want to offer GUA and GUA tainted on the same simple terms of justified need. > What is this quest to keep stupid people from doing stupid things? > This quest is keeping the rest of us from doing smart things. > No such thing. I just don't want to stupidly break global addressing policy in the process. If you want to do something stupid behind your own closed doors using your own registry, feel free. If you want to do something stupid in a globally unique way that is guaranteed the ability to be perceived as harmless to the internet while doing great actual harm, then, I have an issue because that's not stupid people doing stupid things to themselves, it's stupid people doing stupid things to everyone else while feeling no consequences themselves. In general, policies that allow such actions do not lead to good stewardship. Owen From owen at delong.com Mon Mar 22 23:22:23 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Mar 2010 20:22:23 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <17546.1269305332@marajade.sandelman.ca> References: <17546.1269305332@marajade.sandelman.ca> Message-ID: <4FFC743F-3E70-4337-8421-64BF4DA974A1@delong.com> > > This is what security experts (LIKE MYSELF) call: > depth-in-security > This is most definitely the shallow end of "defense-in-depth" which is what those of us who have been around long enough to remember the era before Brent Chapman wrote a book on the subject call it. > > The major advantage of ULA-C is that is provides a much better way to > audit what is what, particularly when there are multiple organizations > connecting together in various ways. > A better way to audit than what? Since you haven't identified what you are comparing it to in this statement, it is unclear whether you mean GUA, ULA-Random, what I am calling GUA-Tainted (which does not necessarily have any distinction on the wire from ULA-C, only in the policy and fee structure details), or some other idea. > It also permits sane auditing of multiple remote-access connections from > laptops/etc. for visiting consultants, etc. > Again, I don't see the distinction here, but, maybe with a distinct point of comparison, that would be easier. > ULA-C for NCN is much more robust than "tainted" GUA as far as failing > closed. > Still not seeing it. ULA-C is a set of numbers tagged as not-routable by address policy convention. GUA-Tainted is a set of numbers tagged as not-routable by address policy convention. In fact, I have repeatedly explained that implementation of GUA-Tainted from the ULA-C number block would be a fine idea. As such, I'm not sure what distinction you are seeing in GUA-Tainted from ULA-C. There must be some depth to the on-wire security implications of address assignment methodologies not apparent on the wire that I am not getting. Please do enlighten me. > But, for it to have any value over RFC1918 (i.e. NOT USING IPv6), it has > to solve problems which RFC1918 has caused. > Exactly. > Split-DNS is one of those things. (I started implementing split-DNS > systems back in 1992... It was useable then because nobody had > laptops. By the time it became universal for enterprises, it was > unworkably useless, and /etc/hosts or literal IPs began to replace it) > Agreed. As Is said earlier, we are, I believe, arguing over form and not substance. In addition to the community of users who want tainted address space (whether you call it ULA-C or GUA-Tainted), there exists a community of users that wants non-tainted address space for networks that are not connected now, but, may be connected at some other time or may connect and disconnect multiple times over some time period. My proposal is to meet BOTH sets of needs using broader GUA policies with an ability to provide "tainted" GUA (as I said, this could _BE_ ULA-C) to those who request it. However, I stand by the assertion that ULA-C or GUA-Tainted being made available on a basis which is different (easier or cheaper) from the policies under which GUA is made available will lead to accepted (ab)use of ULA-C/GUA-Tainted in ways which: 1. Reduce its value as distinct for security purposes 2. Reduce its value as distinct for routing purposes. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Tue Mar 23 03:26:47 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 23 Mar 2010 07:26:47 -0000 Subject: [arin-ppml] Acronyms run riot In-Reply-To: <17546.1269305332@marajade.sandelman.ca> Message-ID: <28E139F46D45AF49A31950F88C4974580594E71A@E03MVZ2-UKDY.domain1.systemhost.net> > ULA-C for NCN is much more robust than "tainted" GUA as far > as failing closed. In your previous message you used NNC and I couldn't remember what it stands for. In any case, I think we have gone a bit too far in introducing new acronyms. The only new acronym that saw a lot of use in the thread was GUA which is a reasonable acronym, but which should not refer to what Owen said. To anyone who dipped into this thread, and even to me, it seems that GUA stands for Global Unicast Addresses, i.e. the 1/8th of the IPv6 address space in 2000::3, and if we keep using this acronym, I think that is what it should stand for. There is no need to label globally unique addresses like ULA-C and GUA and RFC 3306 multicast addresses. Sometimes it is better to use the words "unique" or "globally unique". NCN is actually a misnomer because these are not non-connected networks. In the past I have called these internetworks, or private internets. Obviously they are connected networks, just not connected to the public Internet. I don't think they should all be lumped together in a policy discussion under some label. > Split-DNS is one of those things. (I started implementing > split-DNS systems back in 1992... It was useable then because > nobody had laptops. By the time it became universal for > enterprises, it was unworkably useless, and /etc/hosts or > literal IPs began to replace it) This DNS issue really needs to go to the IETF because this is the kind of thing that would be specified in an RFC. --Michael Dillon From stephen at sprunk.org Tue Mar 23 12:10:43 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 23 Mar 2010 11:10:43 -0500 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <158D0231-44EF-4F31-8114-50FA07C02EA3@delong.com> References: <28E139F46D45AF49A31950F88C497458058E2208@E03MVZ2-UKDY.domain1.systemhost.net> <9254.1269267155@marajade.sandelman.ca> <20100322183036.GA40906@ussenterprise.ufp.org> <28386.1269289081@marajade.sandelman.ca> <4A880690-3EF4-49DC-9CCE-783ADEB34EBF@delong.com> <17061.1269304881@marajade.sandelman.ca> <158D0231-44EF-4F31-8114-50FA07C02EA3@delong.com> Message-ID: <4BA8E803.5030106@sprunk.org> On 22 Mar 2010 21:57, Owen DeLong wrote: > On Mar 22, 2010, at 5:41 PM, Michael Richardson wrote: >>> Here, I must disagree. A liberalized PI policy would serve those smaller more innovative enterprises at least as well as ULA-C, if not better. Especially if it provided for an equal ability to get "tainted" addresses on request. >> If "tainted" address space is $10, then great. >> > It won't be $10. It shouldn't be $10. It shouldn't be a whole lot more than that. I'm thinking on the order of $50/year, tainted or otherwise. > GUAs currently cost $100/yr for end-user assignments, after the initial fee. I don't see a meaningful difference between $50/yr and $100/yr, especially when any organization with a legitimate reason to use ULA-C space (rather than ULA-R space) would see either as no more than a rounding error in their budget. If we liberalized the GUA policy (which would be tough, since it's already ridiculously easy to qualify for), the Board might lower the initial assignment fee because less work would need to be done. Still, I think the current fee for a /48 is reasonable and provides a valuable deterrent to using GUAs when ULA-R would work just fine. Viewed in that light, I see no reason for it to be lower for ULA-C than for GUAs, and therefore no reason for ULA-C to exist at all. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From cengel at sponsordirect.com Tue Mar 23 12:38:30 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Tue, 23 Mar 2010 12:38:30 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: Message-ID: Michael Richardson wrote: # This is what security experts (LIKE MYSELF) call: # depth-in-security # I regularly argue with these johnny-come-lately security "experts", because they rarely # understand the tradeoffs of each layer of security. So how many years does one have to have in the industry to not be considered a johnny-come-lately or to get the quotes removed from around "expert" ? I've been in the industry since '90...is that enough time for you? Note...I don't claim to be a security "expert" ....as the scope of my job isn't limited to security alone...like many IT Pros in small to mid-size Enterprises...I wear ALOT of hats and my job involves alot of different areas of IT. Never-the-less, I've had a fair amount of experience with security...I'm very familiar with the concept of "Defense-in-Depth", "Mutil-Layered Security" or whatever euphamisim is in vogue this month. You don't have to read a book to understand the concept. The people who configure security mechanisms are human beings. Human beings make mistakes. If you rely on a single control for security then chances are you are going to get burned by it sooner or later. "Single point of failure"... that's something any IT pro can understand regardless of what area of IT they work in. OF COURSE there are trade-offs with each layer...there are trade-offs with pretty much EVERY security mechanism implimented. That doesn't mean the trade-offs aren't worth it in the majority of cases ...though they may not be in some? Let's look at a simple example..... STRONG PASSWORDS.... The most straight-forward trade-off with requiring strong passwords as opposed to weak ones is that they are harder for the human brain to remember...and easier to mistype. You impliment a STRONG PASSWORD policy...you WILL get more account lockouts, more complaints, etc. That doesn't mean that the policy isn't worth it in many cases. Furthermore people CAN misbehave in thier use of such passwords in ways which partialy invalidate thier value...write them on yellow post-it notes stuck to thier monitor, etc.... just like people can route RFC 1918 space when they aren't supposed to... Does that mean that strong passwords are no longer considered a viable security mechanism? (Not that there aren't other mechanisms which are as good or better...but all come with thier own trade-offs). As far as the value of NAT and Address Obfuscation. I've seen it listed as a reccomended security measure in PCI, DISA, & NIST guidelines to name just a few (Not to mention just about every one of the dozens of security audits I've been put through)...so you'll have to forgive me if I place a little more stock in those (not to mention my own personal experiences) then what I hear from a couple of posters on an Address Policy mailing list. It's NOT a substitute for good filtering rules...but as an adjunct it DOES have value. # The major advantage of ULA-C is that is provides a much better way to audit what is what, # particularly when there are multiple organizations connecting together in various ways. Not really sure what you mean by this....other then the implication that ULA-C is uniquely assigned to an organization.... so less chance of it being duplicated in multiple org's when they connect together... I think we all get that advantage over RFC1918 or ULA-Random (although it comes with it's own trade-off too)... but I don't really see a significant difference here from Owens GUA-tainted....a rose is a rose and all that. # It also permits sane auditing of multiple remote-access connections from laptops/etc. for # visiting consultants, etc. # ULA-C for NCN is much more robust than "tainted" GUA as far as failing closed. # But, for it to have any value over RFC1918 (i.e. NOT USING IPv6), it has to solve problems # which RFC1918 has caused. # Split-DNS is one of those things. (I started implementing split-DNS systems back in 1992... # It was useable then because nobody had laptops. By the time it became universal for # enterprises, it was unworkably useless, and /etc/hosts or literal IPs began to replace it) I agree that the option for using public DNS/RDNS for owners of that space that WANT to use it. However, for many situations Split-DNS is a perfectly workable solution and not even neccesarly much of a head-ache. Laptops need not be some sort of special mystical animal..where all the rules for working with them go out the window. If you provide connectivity for them to your network (say via VPN) they CAN use your internal DNS servers...just like any other device directly cabled to that network. There are alot of mechanisms provided within DNS for working with name spaces that aren't local (Forwarders, Conditional Forwarders, Stub Zones & replication, etc) so it's not impossible to do in most cases. I could see how some organizations might just say... screw it, there are just too many hoops to jump through to do this internaly...lets just make everything public.... and I think that should be an option for those who WANT it. However, lets not pretend there aren't trade-offs with that either. Personaly....beyond the issue of publishing internal host-names & IP's... if I have apps that are designed for use with internal resources...I like the idea of them NOT being able to resolve the names of resources they need to connect to if they don't have internal connectivity. Sometimes you WANT things to break....and break in predictable ways...if the conditions under which they were designed to run don't exist. Christopher Engel From owen at delong.com Tue Mar 23 13:44:38 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 23 Mar 2010 10:44:38 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BA8E803.5030106@sprunk.org> References: <28E139F46D45AF49A31950F88C497458058E2208@E03MVZ2-UKDY.domain1.systemhost.net> <9254.1269267155@marajade.sandelman.ca> <20100322183036.GA40906@ussenterprise.ufp.org> <28386.1269289081@marajade.sandelman.ca> <4A880690-3EF4-49DC-9CCE-783ADEB34EBF@delong.com> <17061.1269304881@marajade.sandelman.ca> <158D0231-44EF-4F31-8114-50FA07C02EA3@delong.com> <4BA8E803.5030106@sprunk.org> Message-ID: On Mar 23, 2010, at 9:10 AM, Stephen Sprunk wrote: > On 22 Mar 2010 21:57, Owen DeLong wrote: >> On Mar 22, 2010, at 5:41 PM, Michael Richardson wrote: >>>> Here, I must disagree. A liberalized PI policy would serve those smaller more innovative enterprises at least as well as ULA-C, if not better. Especially if it provided for an equal ability to get "tainted" addresses on request. >>> If "tainted" address space is $10, then great. >>> >> It won't be $10. It shouldn't be $10. It shouldn't be a whole lot more than that. I'm thinking on the order of $50/year, tainted or otherwise. >> > > GUAs currently cost $100/yr for end-user assignments, after the initial > fee. I don't see a meaningful difference between $50/yr and $100/yr, > especially when any organization with a legitimate reason to use ULA-C > space (rather than ULA-R space) would see either as no more than a > rounding error in their budget. > > If we liberalized the GUA policy (which would be tough, since it's > already ridiculously easy to qualify for), the Board might lower the > initial assignment fee because less work would need to be done. Still, > I think the current fee for a /48 is reasonable and provides a valuable > deterrent to using GUAs when ULA-R would work just fine. Viewed in that > light, I see no reason for it to be lower for ULA-C than for GUAs, and > therefore no reason for ULA-C to exist at all. > There is a group of people who believe having tainted addresses that are guaranteed unique is valuable. I don't agree with them, but, I can't deny that they exist and do not feel I should tell them their opinion is not valid. As such, I would rather see us implement a one-policy, one- price strategy for both tainted and non-tainted addresses and have the RIRs issuing both types than have some other system outside of the RIRs develop for the administration of tainted addresses. The former will keep policy consistent. The latter will lead to an incentive to use "tainted" addresses in an "untainted" context which will blur the definitions over time and eventually become an end-run on RIR policy. Owen From bill at herrin.us Tue Mar 23 14:24:06 2010 From: bill at herrin.us (William Herrin) Date: Tue, 23 Mar 2010 14:24:06 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: References: Message-ID: <3c3e3fca1003231124y701a9fc0of12effbc87987419@mail.gmail.com> On Mon, Mar 22, 2010 at 7:01 PM, Owen DeLong wrote: > On Mar 22, 2010, at 3:34 PM, Chris Engel wrote: >> Owen Delong wrote: >> # ULA-C isn't going to be blocks which don't work on the internet. It's >> # going to be blocks which people expect not to work on the internet, but, >> # really they do under some circumstances. ?End result, a false sense of security which is >> # worse than no security. >> >> # NAT != Security >> # Address Obfuscation != Security >> # Misconfiguration == Insecurity >> >> # Belief otherwise merely increases risk. >> >> >> I've got to take some issue with your above statements Owen. NAT and Address Obfuscation ARE security mechanisms (albiet not fool-proof ones, but I've yet to see a fool-proof mechanism). Most Enterprise Admins I know commonly regard them as such...MOST dedicated IT Security people I've talked to regard them as such. PCI reg's require them as such... and pretty much every security audit I've been through that involves a regulated industry (Financial, Health, etc) has included them as such. >> > Nope... Stateful inspection is a security mechanism. ?NAT and Address Obfuscation are crutches which most people use to make sure that Stateful Inspection is working because they cannot work without it. > > The mere fact that this myth is wide spread among things like PCI does not make it any more accurate. No offense Owen, but you're talking out the wrong hole on this one. Security devices which tend to fail closed are more secure than devices which tend to fail open. Firewalls fail towards being routers. It's the nature of TCP/IP - all but the most trivial of hosts are also capable of being routers. With translation in effect, that failure process renders the system non-operational and is immediately noticeable. Without translation the failure process renders the system open to attack and won't be promptly noticed since everything expected to work still does. It's part and parcel to TCP/IP's basic architecture, an architecture that hasn't appreciably changed in IPv6. > not valid. As such, I would rather see us implement a one-policy, one- > price strategy for both tainted and non-tainted addresses and have > the RIRs issuing both types than have some other system outside of > the RIRs develop for the administration of tainted addresses. Because "one size fits all" works so well in general and the needs of the non-connected or privately interconnected network are so obviously identical to the needs of the Internet-connected network. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Tue Mar 23 15:33:02 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 23 Mar 2010 12:33:02 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <3c3e3fca1003231124y701a9fc0of12effbc87987419@mail.gmail.com> References: <3c3e3fca1003231124y701a9fc0of12effbc87987419@mail.gmail.com> Message-ID: On Mar 23, 2010, at 11:24 AM, William Herrin wrote: > On Mon, Mar 22, 2010 at 7:01 PM, Owen DeLong wrote: >> On Mar 22, 2010, at 3:34 PM, Chris Engel wrote: >>> Owen Delong wrote: >>> # ULA-C isn't going to be blocks which don't work on the internet. It's >>> # going to be blocks which people expect not to work on the internet, but, >>> # really they do under some circumstances. End result, a false sense of security which is >>> # worse than no security. >>> >>> # NAT != Security >>> # Address Obfuscation != Security >>> # Misconfiguration == Insecurity >>> >>> # Belief otherwise merely increases risk. >>> >>> >>> I've got to take some issue with your above statements Owen. NAT and Address Obfuscation ARE security mechanisms (albiet not fool-proof ones, but I've yet to see a fool-proof mechanism). Most Enterprise Admins I know commonly regard them as such...MOST dedicated IT Security people I've talked to regard them as such. PCI reg's require them as such... and pretty much every security audit I've been through that involves a regulated industry (Financial, Health, etc) has included them as such. >>> >> Nope... Stateful inspection is a security mechanism. NAT and Address Obfuscation are crutches which most people use to make sure that Stateful Inspection is working because they cannot work without it. >> >> The mere fact that this myth is wide spread among things like PCI does not make it any more accurate. > > > No offense Owen, but you're talking out the wrong hole on this one. My level of offense is irrelevant to the discussion. > Security devices which tend to fail closed are more secure than > devices which tend to fail open. Firewalls fail towards being routers. While that is a true statement, NAT has nothing to do with it. A properly constructed stateful inspection firewall can fail just as closed without NAT as it does with it. No entry in the flow table = no forwarding. > It's the nature of TCP/IP - all but the most trivial of hosts are also > capable of being routers. With translation in effect, that failure > process renders the system non-operational and is immediately > noticeable. Without translation the failure process renders the system > open to attack and won't be promptly noticed since everything expected > to work still does. > Sorry, I can't figure out what particular scenario is envisioned in all the missing steps there... If you're talking about a scenario where you have hosts that should not be routers connected to networks on both sides of a firewall, then, that's a generally bad design to begin with. No host that is not a security boundary device should ever be directly connected to more than one security zone. Doing so isn't a failure of a security device, it's a deliberate effort to bypass it. If someone is allowed to bypass your security at this level, the mode in which it tends to fail is the least of your concerns. If the host is connected by accident, then, the upstream router shouldn't be likely to ask it to forward packets towards your interior, so, things still fail closed. If your forward interior-bound packets to something which isn't a defined security device, then, you have a second failure in your security policy already. Still, when the outbound firewall gets a non-initiation packet for an unestablished session, it should block the outbound reply. In other words, without NAT, we've already seen a need for 3 failures in your security policy to make things work. I suppose it could be argued that requiring the host in question to implement NAT in order to function makes for a 4th failure, but, I'll point out that if the undesired forward does implement NAT, it makes it easier for it to completely bypass the firewall by substituting it's own interior address for the outbound destination in all the packets. So, in the scenario I think you are most likely referring to, NAT giveth one additional layer and NAT removeth one additional layer of security, making NAT roughly a zero-sum game at best. Given the high cost to NAT in terms of application development time wasted on constructing and maintaining NAT traversal schemes and the high degree of incompatibility of various NAT traversal solutions, that's an awful lot of capital for something that is a wash at best in terms of security. > It's part and parcel to TCP/IP's basic architecture, an architecture > that hasn't appreciably changed in IPv6. > Sure. If you're building a TCP/IP network with security, no host should straddle a security boundary that is not a security border device. That's true in IPv4. It's true in IPv6. It doesn't change with or without NAT and NAT doesn't do anything for you or against you if you don't have such a host. If you do have such a host, NAT can represent the fourth required failure on the intentional security device, but, if said host is configured with NAT, it can bypass the third required failure on the same device. > >> not valid. As such, I would rather see us implement a one-policy, one- >> price strategy for both tainted and non-tainted addresses and have >> the RIRs issuing both types than have some other system outside of >> the RIRs develop for the administration of tainted addresses. > > Because "one size fits all" works so well in general and the needs of > the non-connected or privately interconnected network are so obviously > identical to the needs of the Internet-connected network. > Because having disparate policies for the two classes of address space will create an incentive for the one that is easier to get to be (mis)used in environments where the other would be more appropriate. If it's easy to get the addresses you need of whichever type you need, why is that a bad thing? Owen From cengel at sponsordirect.com Tue Mar 23 17:04:31 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Tue, 23 Mar 2010 17:04:31 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: Message-ID: Owen Delong wrote: > Sorry, I can't figure out what particular scenario is > envisioned in all the missing steps there... Owen, Not trying to speak for Bill here...but I'll give you a simple common usage example of how NAT has value in protecting networks against misconfigurations. Scenerio #1 Firewall with NAT deployed - You have a private address space network (RFC 1918 space in IPv4) internaly. At the edge of it you have deployed a Firewall. You have a certain number of public addresses that you use to provide limited access to services (SMTP Server, Web Server, etc) to external users. On the Firewall you create a static mapping of each external address that provides an advertised service to the internal address of the device which provides it. Now you also create filtering rules on the firewall to control what packets are allowed to pass through. Lets say your Firewall Admin, being human, screws up and misconfigures one rule. Instead of allowing HTTP incoming only to the Web Server (which presumably has been hardened to accept external traffic) he allows HTTP incoming to ALL. So now you have a potential disaster on your hands as your misconfigured filter allows HTTP traffic to EVERY device on your network....including possibly web applications that are in development and testing and haven't been hardened against misuse yet. However here is where NAT comes in to help save your butt. You have no address mapping to any of those internal only devices on your firewalls EXTERNAL interface. So an external user has no way to address them. Even if that user was able to route a packet destined to an internal IP address to your Firewalls EXTERNAL interface.... that interface wouldn't pick it up...because as far as it's concerned no such IP address is bound to that interface. So the misconfigured rule still only results in external traffic to devices which are configured for external access. Scenerio #2 Firewall no NAT - You are using only public address space. You have a firewall deployed at your network boundary. It's in "Pass Through" configuration...meaning that it inspects each packet passing through it's interfaces and applies it's filtering rules. For anything that isn't restricted by those rules...it allows the packet through to it's destination address. Same mistake as above. Your all too human Firewall Admin has misconfigured the rule that filters inbound HTTP traffic. Instead of the just allowing it to the Web Server that is advertised for external access...he allows it through to ALL. However, in this case there is no NAT, no "compensating control" to account for the single point of failure. An external user sends a packet destined for one of your "internal only" devices. In this case, since all devices use public address space...it's entirely addressable to that external user. The firewalls external interface picks up the packet... see's that it's allowed by the filtering rules...and passes it through to the destination address. Just as it thinks it's supposed to. Note in both cases Statefull Inspection is present....It's just been made completely irrelevent as the Admin has misconfigured the rule which would use it to block unwanted traffic. In scenerio #1 end result is that the traffic gets blocked anyways (fails closed), in scenerio #2 it gets through (fails open). Am I wrong? Christopher Engel From JOHN at egh.com Tue Mar 23 17:21:21 2010 From: JOHN at egh.com (John Santos) Date: Tue, 23 Mar 2010 17:21:21 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: Message-ID: <1100323171651.39337A-100000@Ives.egh.com> On Tue, 23 Mar 2010, Chris Engel wrote: > > Owen Delong wrote: > > > Sorry, I can't figure out what particular scenario is > > envisioned in all the missing steps there... > > > Owen, > > Not trying to speak for Bill here...but I'll give you a simple common usage example of how NAT has value in protecting networks against misconfigurations. > > Scenerio #1 Firewall with NAT deployed - > > You have a private address space network (RFC 1918 space in IPv4) internaly. At the edge of it you have deployed a Firewall. You have a certain number of public addresses that you use to provide limited access to services (SMTP Server, Web Server, etc) to > external users. On the Firewall you create a static mapping of each external address that provides an advertised service to the internal address of the device which provides it. > > Now you also create filtering rules on the firewall to control what packets are allowed to pass through. Lets say your Firewall Admin, being human, screws up and misconfigures one rule. Instead of allowing HTTP incoming only to the Web Server (which presu > mably has been hardened > to accept external traffic) he allows HTTP incoming to ALL. So now you have a potential disaster on your hands as your misconfigured filter allows HTTP traffic to EVERY device on your network....including possibly web applications that are in development > and testing and haven't been hardened against misuse yet. > > However here is where NAT comes in to help save your butt. You have no address mapping to any of those internal only devices on your firewalls EXTERNAL interface. So an external user has no way to address them. Even if that user was able to route a packet > destined to an internal IP address to your Firewalls EXTERNAL interface.... that interface wouldn't pick it up...because as far as it's concerned no such IP address is bound to that interface. So the misconfigured rule still only results in external traf > fic to devices which are configured for external access. > > > Scenerio #2 Firewall no NAT - > > You are using only public address space. You have a firewall deployed at your network boundary. It's in "Pass Through" configuration...meaning that it inspects each packet passing through it's interfaces and applies it's filtering rules. For anything that > isn't restricted by those rules...it allows the packet through to it's destination address. Same mistake as above. Your all too human Firewall Admin has misconfigured the rule that filters inbound HTTP traffic. Instead of the just allowing it to the Web > Server that is advertised for external access...he allows it through to ALL. Actually, more likely case is there's a default rule the blocks all otherwise unaccounted for inbound traffic, but the same mistake as above, instead of allowing inbound HTTP only to the web server, the rule for HTTP allows inbound HTTP to ALL hosts. > > However, in this case there is no NAT, no "compensating control" to > account for the single point of failure. An external user sends a packet > destined for one of your "internal only" devices. In this case, since all > devices use public address space...it's > entirely addressable to that external user. The firewalls external > interface picks up the packet... > see's that it's allowed by the filtering rules...and passes it through to > the destination address. Just as it thinks it's supposed to. > > Note in both cases Statefull Inspection is present....It's just been > made completely irrelevent as the Admin has misconfigured the rule which > would use it to block unwanted traffic. In scenerio #1 end result is that > the traffic gets blocked anyways (fails closed), in scenerio #2 it gets > through (fails open). > > Am I wrong? > Nope. > > > Christopher Engel -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From owen at delong.com Tue Mar 23 21:01:39 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 23 Mar 2010 18:01:39 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: References: Message-ID: On Mar 23, 2010, at 2:04 PM, Chris Engel wrote: > > Owen Delong wrote: > >> Sorry, I can't figure out what particular scenario is >> envisioned in all the missing steps there... > > > Owen, > > Not trying to speak for Bill here...but I'll give you a simple common usage example of how NAT has value in protecting networks against misconfigurations. > > Scenerio #1 Firewall with NAT deployed - > > You have a private address space network (RFC 1918 space in IPv4) internaly. At the edge of it you have deployed a Firewall. You have a certain number of public addresses that you use to provide limited access to services (SMTP Server, Web Server, etc) to external users. On the Firewall you create a static mapping of each external address that provides an advertised service to the internal address of the device which provides it. > > Now you also create filtering rules on the firewall to control what packets are allowed to pass through. Lets say your Firewall Admin, being human, screws up and misconfigures one rule. Instead of allowing HTTP incoming only to the Web Server (which presumably has been hardened > to accept external traffic) he allows HTTP incoming to ALL. So now you have a potential disaster on your hands as your misconfigured filter allows HTTP traffic to EVERY device on your network....including possibly web applications that are in development and testing and haven't been hardened against misuse yet. > Why on earth is your web server on the same network as your internal hosts to begin with? Machines which do not belong in the same security zone shouldn't be on the same network any more than a box which is not a security boundary device should have interfaces in multiple security zones. Ideally, you would also want a different firewall either between the DMZ and your internal network or between the external network and your internal network so that this can not occur. > However here is where NAT comes in to help save your butt. You have no address mapping to any of those internal only devices on your firewalls EXTERNAL interface. So an external user has no way to address them. Even if that user was able to route a packet destined to an internal IP address to your Firewalls EXTERNAL interface.... that interface wouldn't pick it up...because as far as it's concerned no such IP address is bound to that interface. So the misconfigured rule still only results in external traffic to devices which are configured for external access. > How is the firewall administrator less likely to misconfigure the address mapping than the rule? Perhaps I'm confused, but, I would think that one mistake would not preclude the other. Especially when you consider the scenario most likely in IPv6 NAT where it is more than likely we would at least abandon address overloading in favor of 1:1 mappings for simple prefix rewriting. > > Scenerio #2 Firewall no NAT - > > You are using only public address space. You have a firewall deployed at your network boundary. It's in "Pass Through" configuration...meaning that it inspects each packet passing through it's interfaces and applies it's filtering rules. For anything that isn't restricted by those rules...it allows the packet through to it's destination address. Same mistake as above. Your all too human Firewall Admin has misconfigured the rule that filters inbound HTTP traffic. Instead of the just allowing it to the Web Server that is advertised for external access...he allows it through to ALL. > Well, the default permit scenario you described is far more of a security issue than the lack of NAT. Why would anyone configure their firewall that way? > However, in this case there is no NAT, no "compensating control" to account for the single point of failure. An external user sends a packet destined for one of your "internal only" devices. In this case, since all devices use public address space...it's entirely addressable to that external user. The firewalls external interface picks up the packet... see's that it's allowed by the filtering rules...and passes it through to the destination address. Just as it thinks it's supposed to. > More than likely even if there is NAT, the following configuration NAT External: 2001:db8:4f00::/48 Internal: 2001:db8:9200::/48 1:1 Would exist in IPv6, so, even if you got NAT, you most likely lose that. However, I think your erstwhile firewall admin is not significantly less likely to target the rule at the wrong host/host group than to target the mapping in the identical incorrect way, so, I'm not convinced this is much in the way of security. > Note in both cases Statefull Inspection is present....It's just been made completely irrelevent as the Admin has misconfigured the rule which would use it to block unwanted traffic. In scenerio #1 end result is that the traffic gets blocked anyways (fails closed), in scenerio #2 it gets through (fails open). > Yes, in both cases, the admin can circumvent the stateful inspection either through willful or accidental misconfiguration. I think this will remain true in both cases. It also remains true that a firearm, whether a .22, or a shotgun can be used to inflict injury to one's own foot. I'm also opposed to gun control and believe that the second amendment is an important protection even if we have at this point neutered it such that it is unlikely to remain actually effective for its original intent. > Am I wrong? > You're not entirely wrong, but, I think you overestimate the value and underestimate the cost of this alleged benefit, especially in the most likely IPv6 scenario where address availability would render 1:many NAT unlikely. Owen From michael.dillon at bt.com Wed Mar 24 05:17:59 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 24 Mar 2010 09:17:59 -0000 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BA8E803.5030106@sprunk.org> Message-ID: <28E139F46D45AF49A31950F88C4974580594F154@E03MVZ2-UKDY.domain1.systemhost.net> > I see no reason for it to be lower for ULA-C than for GUAs, > and therefore no reason for ULA-C to exist at all. If the final version of ULA-C comes without any global reverse DNS service on the public Internet, that is sufficient reason for the annual fees to be cheaper. Of course, it is not up to us to decide the fees and policy can't do much more than state that there will be or won't be an annual fee. The rest of the decision is up to ARIN members whose criteria are likely to be less related to policy and more related to ensuring that ARIN does not charge too much for anything, to avoid huge surpluses, and to ensure that the fee structure more or less covers the actual effort that ARIN makes in providing service. --Michael Dillon From michael.dillon at bt.com Wed Mar 24 05:21:11 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 24 Mar 2010 09:21:11 -0000 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C4974580594F160@E03MVZ2-UKDY.domain1.systemhost.net> > # ULA-C for NCN is much more robust than "tainted" GUA as far > as failing closed. This is the *PUBLIC* policy mailing list. Please speak English. --Michael Dillon From cengel at sponsordirect.com Wed Mar 24 11:50:00 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Wed, 24 Mar 2010 11:50:00 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: Message-ID: Owen DeLong wrote: > Why on earth is your web server on the same network as your > internal hosts to begin with? Machines which do not belong in > the same security zone shouldn't be on the same network any > more than a box which is not a security boundary device > should have interfaces in multiple security zones. > > Ideally, you would also want a different firewall either > between the DMZ and your internal network or between the > external network and your internal network so that this can not occur. Owen this is largely irrelevent. Most commercial grade firewalls come with multiple interfaces so that you can setup different security zones off the same physical device. Saves the cost and labor of maintaining 15 different physical devices when you can simply have one or two. Many firewalls are written where you can have rules that span multiple interfaces or that apply across all interfaces. Furthermore alot of small to medium size Enterprises are going to have some mixing of devices in zones. It's not ideal but people do operate under resource constraints. Alot of Enterprises are going to go with simply a mail server.... rather then one that acts as a mailbox store and access for internal mail.... another that's used to exchange SMTP with other mail servers... another that provides Webmail (i.e. a Webserver) for mobile users.... another to provide synching services for Blackberries and mobile phones, etc. Even in cases where you do have a strict seperation of devices into zones.... that seperation though valuable isn't as strong a security measure as most assume. Since often those external facing devices are going to need SOME connectivity to internal resources (i.e. a Webmail server is going to need to connect to the information store that holds the mailbox data) and thus can be used as a proxy to attack into the private zone. This is just the way things tend to work in real world scenerios. All this is beside the point however. The point is that at your network bounderies you ARE going to deploy firewalls and those firewalls are going to have rules to filter traffic that passes across thier boundary. If those rules are misconfigured, ANY device that is advertised on the firewalls external interface becomes vulnerable. Regardless of the segmentation of zones that happens behind it, chances are that ANY edge firewall is going to be getting both INBOUND and OUTBOUND traffic on it's EXTERNAL interface.... unless you use different ISP's for INBOUND and OUTBOUND which is a pretty bizzare arrangement that I haven't personaly heard of anyone doing before. Yet even then you ARE going to be getting INBOUND traffic on that interface....even if it's all traffic that you don't want and ALL it takes is one misconfiguration of a rule that breaks the DENY ALL IN default rule you've setup. > How is the firewall administrator less likely to misconfigure > the address mapping than the rule? Perhaps I'm confused, but, > I would think that one mistake would not preclude the other. He's not and one mistake does not preclude the other. The point is under this scenerio he has to make 2 mistakes (the address mapping and the filtering rule) rather then just one. That's the whole point behind the Defense in Depth approach. Putting in controls that require multiple mistakes to happen (the more the better) in order for damage to actualy be done. > Well, the default permit scenario you described is far more > of a security issue than the lack of NAT. Why would anyone > configure their firewall that way? The scenerio I posited didn't require a "default permit" situation. In fact it would work just the same with a DENY ALL IN & DENY ALL OUT (the most secure default setting...other then unplugging the network cable). The point is that in all firewall configs you poke holes in those default settings to allow the traffic that needs to get through. The Admin makes a mistake and allows a much broader hole then intended. It's not hard to do if the Admin isn't paying attention. Lets say for example both those default DENY rules are in place. The Admin is configuring a firewall through a GUI (most have them these days) and he intends to create a rule that allows all workstations to ALLOW HTTP OUT (so they can browse the web). If he accidently clicks the checkbox IN/OUT instead... he's just exposed them (if they have public addresses) and probably doesn't even know about it...since they have the access they need. If they don't have public addresses...they still aren't exposed. > More than likely even if there is NAT, the following configuration > > NAT External: 2001:db8:4f00::/48 Internal: 2001:db8:9200::/48 1:1 > > Would exist in IPv6, so, even if you got NAT, you most likely > lose that. Yes, I agree...if you staticly NAT your entire network then you DO loose most of the security value of NAT and may as well be running Public Address Space on your network and save yourself the hassle of a seperate address scheme. However, I don't know anyone who values NAT that would actualy DO THAT. It's why I've lobbied so hard that BOTH 1:1 and Many:1 Address translation should exist under IPV6. Lack of support for that is one of the reasons (though certainly not the only) that IPV6 is a bit of a disaster in the making.... and why alot of Admins are shaking thier heads at IPv6 and saying "Naw I really don't WANT to deploy that unless I'm forced to". You guys would have had ALOT more buy-in (and saved a good chunk of the pain/cost in adoption) if you had kept pretty much everything the same as it worked in IPv4 and just doubled or tripled the number of octets used. Christopher Engel From bill at herrin.us Wed Mar 24 11:59:26 2010 From: bill at herrin.us (William Herrin) Date: Wed, 24 Mar 2010 11:59:26 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: References: Message-ID: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> On Tue, Mar 23, 2010 at 5:04 PM, Chris Engel wrote: > Owen Delong wrote: >> Sorry, I can't figure out what particular scenario is >> envisioned in all the missing steps there... > > Not trying to speak for Bill here... Chris, Feel free. Owen needs as much help understanding the network security process as he can get. > However here is where NAT comes in to help save > your butt. You have no address mapping to any of > those internal only devices on your firewalls > EXTERNAL interface. So an external user has > no way to address them. Even if that user was able > to route a packet destined to an internal IP address > to your Firewalls EXTERNAL interface.... that interface > wouldn't pick it up...because as far as it's concerned > no such IP address is bound to that interface. Exactamundo. > However, in this case there is no NAT, no > "compensating control" to account for the single > point of failure. An external user sends a packet destined > for one of your "internal only" devices. In this case, > since all devices use public address space...it's > entirely addressable to that external user. The firewalls > external interface picks up the packet... see's that it's > allowed by the filtering rules...and passes it through > to the destination address. Just as it thinks it's supposed to. Another win. > Am I wrong? No, you're spot on. On Tue, Mar 23, 2010 at 9:01 PM, Owen DeLong wrote: > On Mar 23, 2010, at 2:04 PM, Chris Engel wrote: >> Am I wrong? > I think you overestimate > the value and underestimate the cost Owen, I wouldn't bet on it, but in this one respect you're finally talking about a value judgment where two competent engineers can reasonably disagree. Regards, Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mksmith at adhost.com Wed Mar 24 12:41:25 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 24 Mar 2010 09:41:25 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> References: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> Message-ID: <17838240D9A5544AAA5FF95F8D52031607D2BDD1@ad-exh01.adhost.lan> > On Tue, Mar 23, 2010 at 5:04 PM, Chris Engel > wrote: > > Owen Delong wrote: > >> Sorry, I can't figure out what particular scenario is > >> envisioned in all the missing steps there... > > > > Not trying to speak for Bill here... > > Chris, > > Feel free. Owen needs as much help understanding the network security > process as he can get. > > > However here is where NAT comes in to help save > > your butt. You have no address mapping to any of > > those internal only devices on your firewalls > > EXTERNAL interface. So an external user has > > no way to address them. Even if that user was able > > to route a packet destined to an internal IP address > > to your Firewalls EXTERNAL interface.... that interface > > wouldn't pick it up...because as far as it's concerned > > no such IP address is bound to that interface. > > Exactamundo. > I'm not sure I understand how NAT fixes this any more than properly applied firewall rules would. If I want to block incoming traffic or, more specifically, only allow specific traffic to and through an IP address, I can do that as readily with an ACL as I can with the inclusion of a static mapping. I appreciate your belief that NAT helps limit operator error, but using any technology in replacement of proper policies in procedures is not a good idea, security or no. The other thing no one is discussing is the outbound complexities of NAT and specifically PAT, given that your various models support only some hosts with static mappings. Given that a significant amount of problems on the network are initiated from the inside by infected hosts, you now have to go through your translation tables to determine which of your multitudinous inside hosts is responsible for sending out cruft. Me: "Hi, we just got scanned/DDOS'd/spammed from at 1:00 local" You: "Wow, that's when everybody got back from lunch, so it will take me a month to go through the translation logs to find out how sent that traffic." Me: Plonk > > However, in this case there is no NAT, no > > "compensating control" to account for the single > > point of failure. An external user sends a packet destined > > for one of your "internal only" devices. In this case, > > since all devices use public address space...it's > > entirely addressable to that external user. The firewalls > > external interface picks up the packet... see's that it's > > allowed by the filtering rules...and passes it through > > to the destination address. Just as it thinks it's supposed to. > > Another win. > > No, that would be an improperly applied ACL. If you want to block traffic to an address, block that traffic. Again, it's a matter of proper procedure. Your compensating control is in the verification that a policy was applied correctly. > > Am I wrong? > > No, you're spot on. > That's certainly one opinion. As with any technology NAT is like any other, with good and bad characteristics. One of the main issues is that NAT is used ubiquitously in almost all consumer devices and touted as a panacea for keeping out the bad guys. The number of bad guys that get in due to uninitiated outside traffic pales in comparison to the number who are invited in by the user through an application-based vector. Apparently NAT is religion. The one thing Chris has spot on is the mistake of not having feature parity between IPv4 and IPv6. If we're going to get all of the enterprises on board with v6 we're going to have to have some sort of protected space, or a sound methodology for splitting your assigned space into public/non-public addresses. It seems to me the latter is doable given the huge number of addresses that are assigned, even with "only" a /48. Regards, Mike From owen at delong.com Wed Mar 24 12:42:43 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 24 Mar 2010 09:42:43 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: References: Message-ID: <84604233-F0E2-433F-97D2-1025E99F6E82@delong.com> On Mar 24, 2010, at 8:50 AM, Chris Engel wrote: > Owen DeLong wrote: > >> Why on earth is your web server on the same network as your >> internal hosts to begin with? Machines which do not belong in >> the same security zone shouldn't be on the same network any >> more than a box which is not a security boundary device >> should have interfaces in multiple security zones. >> >> Ideally, you would also want a different firewall either >> between the DMZ and your internal network or between the >> external network and your internal network so that this can not occur. > > Owen this is largely irrelevent. Most commercial grade firewalls come with multiple interfaces so that you can setup different security zones off the same physical device. Saves the cost and labor of maintaining 15 different physical devices when you can simply have one or two. Many firewalls are written where you can have rules that span multiple interfaces or that apply across all interfaces. Furthermore alot of small to medium size Enterprises are going to have some mixing of devices in zones. It's not ideal but people do operate under resource constraints. Alot of Enterprises are going to go with simply a mail server.... rather then one that acts as a mailbox store and access for internal mail.... another that's used to exchange SMTP with other mail servers... another that provides Webmail (i.e. a Webserver) for mobile users.... another to provide synching services for Blackberries and mobile phones, etc. On such a firewall, you would want software which specifies valid entry/exit interface combinations in addition to IP addresses which would also preclude the error you describe since the DMZ would be on a different interface than the internal network. So, again, NAT still doesn't actually do anything that you can't accomplish with good software and topology without NAT. Furhtermore, your alleged "mail server" should live in the DMZ, like the web server. The server should be reachable for IMAP/SMTP from inside. It should also be reachable for SMTP and possibly IMAP from outside. It should NOT have physical interfaces on the internal and external networks which would allow it to act as a router bypassing your firewall. In such a topology, there is, again, no gain from NAT. > Even in cases where you do have a strict seperation of devices into zones.... that seperation though valuable isn't as strong a security measure as most assume. Since often those external facing devices are going to need SOME connectivity to internal resources (i.e. a Webmail server is going to need to connect to the information store that holds the mailbox data) and thus can be used as a proxy to attack into the private zone. This is just the way things tend to work in real world scenerios. > Arguably the information store belongs in the DMZ rather than the inside, but, even if that is the case, NAT won't help you there. My point wasn't that this separation is absolute security. My point was that in a properly structured network, NAT doesn't improve security. Even if the webmail server is a proxy for attacking the internal mailstore, NAT won't prevent that attack. It won't even make it more difficult. > All this is beside the point however. The point is that at your network bounderies you ARE going to deploy firewalls and those firewalls are going to have rules to filter traffic that passes across thier boundary. If those rules are misconfigured, ANY device that is advertised on the firewalls external interface becomes vulnerable. Regardless of the segmentation of zones that happens behind it, chances are that ANY edge firewall is going to be getting both INBOUND and OUTBOUND traffic on it's EXTERNAL interface.... unless you use different ISP's for INBOUND and OUTBOUND which is a pretty bizzare arrangement that I haven't personaly heard of anyone doing before. Yet even then you ARE going to be getting INBOUND traffic on that interface....even if it's all traffic that you don't want and ALL it takes is one misconfiguration of a rule that breaks the DENY ALL IN default rule you've setup. > This is true. However, the point is that the addition or subtraction of NAT from the equation does not improve or reduce security if you have good firewall software and a well designed topology. > >> How is the firewall administrator less likely to misconfigure >> the address mapping than the rule? Perhaps I'm confused, but, >> I would think that one mistake would not preclude the other. > > He's not and one mistake does not preclude the other. The point is under this scenerio he has to make 2 mistakes (the address mapping and the filtering rule) rather then just one. That's the whole point behind the Defense in Depth approach. Putting in controls that require multiple mistakes to happen (the more the better) in order for damage to actualy be done. > Not really... With good firewall software, he already needs to make two mistakes (misconfigure IP and exit interface), so, bungling the address map becomes a third mistake. While I'll agree anyone is likely to make one mistake, I'll argue that the guy who makes both of the earlier mistakes is pretty likely to make the third as well. > >> Well, the default permit scenario you described is far more >> of a security issue than the lack of NAT. Why would anyone >> configure their firewall that way? > > The scenerio I posited didn't require a "default permit" situation. In fact it would work just the same with a DENY ALL IN & DENY ALL OUT (the most secure default setting...other then unplugging the network cable). The point is that in all firewall configs you poke holes in those default settings to allow the traffic that needs to get through. The Admin makes a mistake and allows a much broader hole then intended. It's not hard to do if the Admin isn't paying attention. Lets say for example both those default DENY rules are in place. The Admin is configuring a firewall through a GUI (most have them these days) and he intends to create a rule that allows all workstations to ALLOW HTTP OUT (so they can browse the web). If he accidently clicks the checkbox IN/OUT instead... he's just exposed them (if they have public addresses) and probably doesn't even know about it...since they have the access they need. If they don't have public addresses...they still aren't exposed. > If the checkbox is IN/OUT rather than requiring separate rules for IN and OUT, then, yes, you fall victim to terrible software design on your firewall GUI and your 1:MANY NAT may save your bacon. In IPv6 where even if NAT is implemented, it would hopefully be limited to 1:1, it probably won't help. > > >> More than likely even if there is NAT, the following configuration >> >> NAT External: 2001:db8:4f00::/48 Internal: 2001:db8:9200::/48 1:1 >> >> Would exist in IPv6, so, even if you got NAT, you most likely >> lose that. > > Yes, I agree...if you staticly NAT your entire network then you DO loose most of the security value of NAT and may as well be running Public Address Space on your network and save yourself the hassle of a seperate address scheme. However, I don't know anyone who values NAT that would actualy DO THAT. It's why I've lobbied so hard that BOTH 1:1 and Many:1 Address translation should exist under IPV6. Lack of support for that is one of the reasons (though certainly not the only) that IPV6 is a bit of a disaster in the making.... and why alot of Admins are shaking thier heads at IPv6 and saying "Naw I really don't WANT to deploy that unless I'm forced to". I'd much rather fix the firewall software than break the internet, but, perhaps I'm the only one who things that problems should be resolved where they are broken rather than break something else instead. > You guys would have had ALOT more buy-in (and saved a good chunk of the pain/cost in adoption) if you had kept pretty much everything the same as it worked in IPv4 and just doubled or tripled the number of octets used. > I didn't design IPv6. I wasn't much involved in its development. However, I do remember the IPv4 internet before NAT and a non-NATted network is well worth the effort to fix those things which are deficient in such a way as to make NAT seem attractive. Owen From cengel at sponsordirect.com Wed Mar 24 14:52:41 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Wed, 24 Mar 2010 14:52:41 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <84604233-F0E2-433F-97D2-1025E99F6E82@delong.com> Message-ID: Owen DeLong wrote: > On such a firewall, you would want software which specifies > valid entry/exit interface combinations in addition to IP > addresses which would also preclude the error you describe > since the DMZ would be on a different interface than the > internal network. So, again, NAT still doesn't actually do > anything that you can't accomplish with good software and > topology without NAT. I don't really know what you are getting at here. Yes you could write a specific rule that Denys ALL IN to Private from External. We've already said that. You could write a rule that DENYs ALL IN to Private from ANY. You could even write a rule that Denys ALL IN to ANY from ANY. You could write 50 rules that all cover the same ground. It doesn't matter. The volume of rules that you write is irrelevant since they are all invalidated by an error in a single rule that that takes precedence over them and flubs scope or direction. I don't know what sort of devices you've worked with but pretty much every firewall I've worked with impliments some sort of logic to determine what rules take precedence when they are in conflict. Sometimes these devices use logic that is IMPLICIT to determine precedence (i.e. more specific takes precedence over general, allow takes precedence over deny, etc), sometimes they impliment logic that lets the user configure precedence (rule weight 10 takes precedence over 20) sometimes it's a combination of the two. They all have their own quirks about how they work... but they all pretty much have some functionality to allow one rule to take precedence over X number of other rules. As long as that exists...it doesn't matter how many rules you write if the Admin flubs one that takes precedence. What you wrote doesn't change anything about the usage scenario I described. > Furhtermore, your alleged "mail server" should live in the > DMZ, like the web server. The server should be reachable for > IMAP/SMTP from inside. It should also be reachable for SMTP > and possibly IMAP from outside. It should NOT have physical > interfaces on the internal and external networks which would > allow it to act as a router bypassing your firewall. In such > a topology, there is, again, no gain from NAT. No it would have an interface on the internal network only in this scenario. It would accept certain traffic (say SMTP) from the external interface and be hardened for such traffic as it was expecting it. It wouldn't "bypass" the firewall as all traffic going to it would still be getting filtered by the Firewall. It would certainly be a "point of attack"...just as e-mail on that server that goes to an end user is....but it would be a well anticipated and limited point of attack. However this is digressing from the main point of the discussion and entirely tangential...so not worth me spending too much more time on. > Arguably the information store belongs in the DMZ rather than > the inside, but, even if that is the case, NAT won't help you there. One wonders if you are putting an organizations internal information stores and all the data they contain in the DMZ, what resources you actually believe you are protecting in the private zone.... but again this discussion is getting pretty far afield and is entirely tangential to the real issue. > My point wasn't that this separation is absolute security. My > point was that in a properly structured network, NAT doesn't > improve security. I'll concede that if no admin EVER makes ANY mistake in ANY aspect of configuring network security (including filter rules) then NAT would be largely unusefull for security. By that same token...If no one ever made ANY mistakes in the handling of a firearm, the safety would be an entirely superfluous device and would not be useful for safety either. However, I don't live in this perfect world that academics love to theorize on paper. I live in the real world where human beings make mistakes ALL the time. Network Admins do misconfigure security settings... and despite safeties, trigger locks and the many layers of rules regarding fire-arm safety (which I'm intimately familiar with as a life-long hunter and gun owner) that every fire-arm owner should be able to recite in his/her sleep people still get shot by accident. In the world I live in... safeties just like NAT ARE useful (albeit imperfect) controls in improving the security of the devices they are associated with.... specifically because people DO screw up and they provide some measure of safety net. > I'd much rather fix the firewall software than break the > internet, but, perhaps I'm the only one who things that > problems should be resolved where they are broken rather than > break something else instead. I'd much rather have standards and policies that account for a wide variety of circumstances and situations, ones that exist in the real world for real people and give people the option to choose the ones that they believe best fit their situation rather then to try to shove everyone in one little box and say "this way or the highway".... but perhaps I'm the only one that things that there is room for people to make different and sometimes even incompatible choices. Remember, one mans "broken" is another's "working as intended". More to the point, NAT hardly breaks the "internet"... it breaks certain specific protocols when they try to go from some end points to certain other end-points. I never read the definition of a working internet that said it guarantied every single protocol would function from every single end point to every other single end point. For any organization that doesn't even guaranty the routability of the addresses they assign that seems like a pretty stringent standard to insist upon. Christopher Engel From cengel at sponsordirect.com Wed Mar 24 15:29:02 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Wed, 24 Mar 2010 15:29:02 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <17838240D9A5544AAA5FF95F8D52031607D2BDD1@ad-exh01.adhost.lan> Message-ID: Michael K. Smith wrote: > I'm not sure I understand how NAT fixes this any more than > properly applied firewall rules would. If I want to block > incoming traffic or, more specifically, only allow specific > traffic to and through an IP address, I can do that as > readily with an ACL as I can with the inclusion of a static > mapping. I appreciate your belief that NAT helps limit > operator error, but using any technology in replacement of > proper policies in procedures is not a good idea, security or no. Michael, I certainly don't consider NAT as a replacement for good policies and procedures. It's usefull as an adjunct for them to provide a bit of a safety net when things aren't setup as they should have been. > Me: "Hi, we just got scanned/DDOS'd/spammed from address> at 1:00 local" > You: "Wow, that's when everybody got back from lunch, so it > will take me > a month to go through the translation logs to find out how sent > that traffic." > Me: Plonk Yeah...there is a trade off here....as there is with pretty much every other implimentation of technology. Personaly I don't think it should be that difficult to search through a set of logs to find some troublesome traffic if you know the destination address...the rough time and something about the nature of the traffic.... at least if you have decent logging software... I mean it's not like the Admin needs to search through each line by hand... how difficult is typing into a filter "destination address = (whatever address got hit), time frame = 12:30 - 1:30 " and hitting enter? > No, that would be an improperly applied ACL. If you want to > block traffic to an address, block that traffic. Again, it's > a matter of proper procedure. Your compensating control is > in the verification that a policy was applied correctly. Michael, I'm all for audits...but they tend to catch things at some point after the problem has occured. So unless you are having a 2nd Engineer go through and verify every piece of work that one of your Engineers does immediately after he does it... then it's not a replacement for NAT. If you have that kind of spare man-power to devote...then god bless you... and are you hiring? Most orginizations I know can't afford to do anything remotely close to that. You are right that procedure is very, very important and so is verifying what you do. I don't know about you...but I know that I personaly have been guilty of setting some configuration, staring at it to make sure I had it right, remember triple checking it....and still come back the next day to find that I had done something wrong...even though at the time things seemed to be working as I thought they should. Some-times the mind and eyes do strange things at the end of an 18 hour shift. > That's certainly one opinion. As with any technology NAT is > like any other, with good and bad characteristics. One of > the main issues is that NAT is used ubiquitously in almost > all consumer devices and touted as a panacea for keeping out > the bad guys. The number of bad guys that get in due to > uninitiated outside traffic pales in comparison to the number > who are invited in by the user through an application-based vector. Well, I'm right there with you with in tearing apart the guys that tout NAT as a panacea solution. In my book those guys are as bad or worse as the ones that claim NAT has absolutely no value. NAT is just one tool in our toolkit. Sometimes is a good fit to be deployed in the package of tools we deploy to secure an environment....other times not. I would never rely on it in isolution of other tools.... but it CAN help as one supporting piece in the overall structure we build. Christopher Engel From bill at herrin.us Wed Mar 24 16:03:55 2010 From: bill at herrin.us (William Herrin) Date: Wed, 24 Mar 2010 16:03:55 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <17838240D9A5544AAA5FF95F8D52031607D2BDD1@ad-exh01.adhost.lan> References: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> <17838240D9A5544AAA5FF95F8D52031607D2BDD1@ad-exh01.adhost.lan> Message-ID: <3c3e3fca1003241303u57033bedl4bc44f3a66feb214@mail.gmail.com> On Wed, Mar 24, 2010 at 12:41 PM, Michael K. Smith - Adhost wrote: > I'm not sure I understand how NAT fixes this any more than properly > applied firewall rules would. Hi Michael, Properly applied firewall rules secure a system regardless of the methodology. Dwelling on that misunderstands the nature of security. Strength of security lies in depth: people being people, mistakes will be made. In the config. In the code. Everywhere. What happens then? A firewall is a door with a lock. Unlock the door, forget to re-lock it and you're done. A NAT firewall is a door with a pneumatic closer, a prox card reader and a pin code. This latter is less vulnerable to attack: stealing or duplicating the prox card is as hard or harder than picking a lock and even once you have the card, you still need the matching pin code for entry. Either way you're screwed when an authorized entrant politely holds the door, but that remaining vulnerability doesn't diminish the difference in security between the two. > The other thing no one is discussing is the outbound complexities of NAT > and specifically PAT, given that your various models support only some > hosts with static mappings. ?Given that a significant amount of problems > on the network are initiated from the inside by infected hosts, you now > have to go through your translation tables to determine which of your > multitudinous inside hosts is responsible for sending out cruft. NAT has a price tag. In fact, it has several. An increase in post-breach forensics complexity is one of those prices. What discussion would you like about a fact that isn't disputed? > As with any technology NAT is like any > other, with good and bad characteristics. Of course it is, and I wouldn't suggest otherwise. Nor would I suggest that the strongest security always the best choice. Strong security tends to come at a usability price that can be inappropriate for the situation. However, everything else being equal, an address-overloaded NAT firewall is stronger security than a non-overloaded NAT firewall which is stronger security than a merely stateful firewall which is stronger security than a packet filter which is stronger security than relying solely on the individual hosts to be resilient to attack. And I will suggest that for any given firewall configuration, the otherwise-identical configuration that also does NAT has implemented stronger security. I'll also claim that while address-overloaded NAT's conservation benefit is more or less pointless in IPv6, its impact on security remains significant, no different than in IPv4. Where the decision to use NAT did not revolve around address conservation, there is little reason to believe a substantially different decision will be reached when implementing IPv6. > Apparently NAT is religion. I've seen that before too but I don't see it here. What I see here is folks trying to address the forceful ignorance that lies in the claim from a certain individual who should know better to the effect that the presence of NAT is a security no-op. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Wed Mar 24 16:25:12 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 24 Mar 2010 13:25:12 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <3c3e3fca1003241303u57033bedl4bc44f3a66feb214@mail.gmail.com> References: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> <17838240D9A5544AAA5FF95F8D52031607D2BDD1@ad-exh01.adhost.lan> <3c3e3fca1003241303u57033bedl4bc44f3a66feb214@mail.gmail.com> Message-ID: <5359E60B-6E2F-4183-86DA-3E939858A93F@delong.com> On Mar 24, 2010, at 1:03 PM, William Herrin wrote: > On Wed, Mar 24, 2010 at 12:41 PM, Michael K. Smith - Adhost > wrote: >> I'm not sure I understand how NAT fixes this any more than properly >> applied firewall rules would. > > Hi Michael, > > Properly applied firewall rules secure a system regardless of the > methodology. Dwelling on that misunderstands the nature of security. > Strength of security lies in depth: people being people, mistakes will > be made. In the config. In the code. Everywhere. What happens then? > Agreed. > A firewall is a door with a lock. Unlock the door, forget to re-lock > it and you're done. > Sort of. > A NAT firewall is a door with a pneumatic closer, a prox card reader > and a pin code. This latter is less vulnerable to attack: stealing or > duplicating the prox card is as hard or harder than picking a lock and > even once you have the card, you still need the matching pin code for > entry. > No. A NAT firewall is a door with a lock and a deadbolt at best unless rules must be expressed in terms of entry/exit zone in addition to source/destination address. In the case where rules must be expressed in both therms, then: A firewall is a door with a lock and a deadbolt. A NAT firewall of this type is a door with a lock, a deadbolt, and a prox-card reader capable of unlocking both the lock and deadbolt (NAT). > Either way you're screwed when an authorized entrant politely holds > the door, but that remaining vulnerability doesn't diminish the > difference in security between the two. > Yep. > > > And I will suggest that for any given firewall configuration, the > otherwise-identical configuration that also does NAT has implemented > stronger security. > Nope... I provided an example earlier where NAT actually reduced security. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mksmith at adhost.com Wed Mar 24 16:47:01 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 24 Mar 2010 13:47:01 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <3c3e3fca1003241303u57033bedl4bc44f3a66feb214@mail.gmail.com> References: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> <17838240D9A5544AAA5FF95F8D52031607D2BDD1@ad-exh01.adhost.lan> <3c3e3fca1003241303u57033bedl4bc44f3a66feb214@mail.gmail.com> Message-ID: <17838240D9A5544AAA5FF95F8D52031607D2BE35@ad-exh01.adhost.lan> > > On Wed, Mar 24, 2010 at 12:41 PM, Michael K. Smith - Adhost > wrote: > > I'm not sure I understand how NAT fixes this any more than properly > > applied firewall rules would. > > Hi Michael, > > Properly applied firewall rules secure a system regardless of the > methodology. Dwelling on that misunderstands the nature of security. > Strength of security lies in depth: people being people, mistakes will > be made. In the config. In the code. Everywhere. What happens then? > > A firewall is a door with a lock. Unlock the door, forget to re-lock > it and you're done. > > A NAT firewall is a door with a pneumatic closer, a prox card reader > and a pin code. This latter is less vulnerable to attack: stealing or > duplicating the prox card is as hard or harder than picking a lock and > even once you have the card, you still need the matching pin code for > entry. > > Either way you're screwed when an authorized entrant politely holds > the door, but that remaining vulnerability doesn't diminish the > difference in security between the two. > > Obviously I don't subscribe to the analogy. A firewall works in exactly the same way whether or not there is a NAT boundary included. Personally, I haven't found that the perceived added security of obfuscating inside host information has been of enough benefit to outweigh the issues with NAT. Forensics are more difficult, IPSec is more difficult, etc. The configuration for hosts and host-types and their access are exactly the same for NAT and no-NAT. > > The other thing no one is discussing is the outbound complexities of > NAT > > and specifically PAT, given that your various models support only > some > > hosts with static mappings. ?Given that a significant amount of > problems > > on the network are initiated from the inside by infected hosts, you > now > > have to go through your translation tables to determine which of your > > multitudinous inside hosts is responsible for sending out cruft. > > NAT has a price tag. In fact, it has several. An increase in > post-breach forensics complexity is one of those prices. What > discussion would you like about a fact that isn't disputed? > The point is that proving NAT is valuable based solely upon its perceived benefits for inbound traffic doesn't address the issue with all its complexities. > > > As with any technology NAT is like any > > other, with good and bad characteristics. > > Of course it is, and I wouldn't suggest otherwise. Nor would I suggest > that the strongest security always the best choice. Strong security > tends to come at a usability price that can be inappropriate for the > situation. > > However, everything else being equal, an address-overloaded NAT > firewall is stronger security than a non-overloaded NAT firewall which > is stronger security than a merely stateful firewall which is stronger > security than a packet filter which is stronger security than relying > solely on the individual hosts to be resilient to attack. > I don't follow the logic. All stateful firewalls perform exactly the same function regardless of NAT. All NAT does is obfuscate the number of internal hosts. Personally, if I have all the addresses I need, I prefer to use them without NAT. I control every connection in and out from the IP's and I know exactly where each one is allocated. > And I will suggest that for any given firewall configuration, the > otherwise-identical configuration that also does NAT has implemented > stronger security. > > I'll also claim that while address-overloaded NAT's conservation > benefit is more or less pointless in IPv6, its impact on security > remains significant, no different than in IPv4. Where the decision to > use NAT did not revolve around address conservation, there is little > reason to believe a substantially different decision will be reached > when implementing IPv6. > > Actually, RFC 1631 says that NAT is for addressing address conservation specifically. And, ironically, in Section 3.2, subsection "Privacty, Security and Debugging Considerations," it says "Unfortunately, NAT reduces the number of options for providing security" and "On the other hand, NAT itself can be seen as providing a kind of privacy mechanism." Privacy equates to obfuscation without the pejoratives overtones of the latter term. > > Apparently NAT is religion. > > I've seen that before too but I don't see it here. What I see here is > folks trying to address the forceful ignorance that lies in the claim > from a certain individual who should know better to the effect that > the presence of NAT is a security no-op. > How about a topic that engenders passionate debate. Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From bill at herrin.us Wed Mar 24 17:49:34 2010 From: bill at herrin.us (William Herrin) Date: Wed, 24 Mar 2010 17:49:34 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <5359E60B-6E2F-4183-86DA-3E939858A93F@delong.com> References: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> <17838240D9A5544AAA5FF95F8D52031607D2BDD1@ad-exh01.adhost.lan> <3c3e3fca1003241303u57033bedl4bc44f3a66feb214@mail.gmail.com> <5359E60B-6E2F-4183-86DA-3E939858A93F@delong.com> Message-ID: <3c3e3fca1003241449g29a4a22fjbc175258aee3a1c7@mail.gmail.com> On Wed, Mar 24, 2010 at 4:25 PM, Owen DeLong wrote: > On Mar 24, 2010, at 1:03 PM, William Herrin wrote: >> A NAT firewall is a door with a pneumatic closer, a prox card reader >> and a pin code. This latter is less vulnerable to attack: stealing or >> duplicating the prox card is as hard or harder than picking a lock and >> even once you have the card, you still need the matching pin code for >> entry. > > No. ?A NAT firewall is a door with a lock and a deadbolt at best unless > rules must be expressed in terms of entry/exit zone in addition to > source/destination address. Owen, Believe it or not, I picked the door analogies deliberately. Adding a door with a key is like adding a firewall. You can no walk packets freely in and out of the network. The addition of a "pneumatic closer" is consistent with any stateful firewall. Unlike a basic packet filter, the stateful firewall pulls the door closed behind the permitted transport sessions, denying other packets. Adding a pin pad is consistent with adding any form of NAT. A mistake which causes bare routing or any subset of it has to somehow also use the right translation code. Switching from a key to a prox card is consistent with address-overloaded NAT specifically. Just as the prox card facilitates maintaining physical security a little better than keeping track of metal keys, address overloading saves you from a few more oopses that would cause mere nat to accept and translate connections where the single-to-many nature of address overloading can at worst expose a single host on a given port. So I have to give you a FAIL. Adding address-overloaded NAT is considerably more than adding a deadbolt. >> And I will suggest that for any given firewall configuration, the >> otherwise-identical configuration that also does NAT has implemented >> stronger security. > > Nope... I provided an example earlier where NAT actually reduced security. No, you provided an example where you boldly but mistakenly claimed that NAT reduced security. On Wed, Mar 24, 2010 at 4:47 PM, Michael K. Smith - Adhost wrote: >The point is that proving NAT is valuable based solely >upon its perceived benefits for inbound traffic doesn't address >the issue with all its complexities. Hi Mike, No argument. > Actually, RFC 1631 says that NAT is for addressing >address conservation specifically. RFC 1631 spoke to the then mostly theoretical concept of NAT as discussed inside the IETF circa 1993-4. The basic idea was a one-to-one mapping of internal to external addresses. Only those very few internal hosts who needed to talk to the Internet would claim an external address and the external address space was flat, requiring no per-lan reserve slack and no subnet-oriented reserved IPs. In other words, it was almost exactly nothing like modern address-overloaded NAT as found in any commodity "DSL router." As modern NAT evolved out of transparent TCP proxies (which had evolved from the bastion host proxy firewalls), there were a number of folks who complained it should be called PAT (port address translation) because it wasn't really NAT. In a sense, they're right... the NAT name was hijacked by the new, vastly more popular process even though it bore only a passing resemblance to the old. My point is: RFC 1631 describes an obsolete process that has limited bearing here. >>> Apparently NAT is religion. >> I've seen that before too but I don't see it here. > How about a topic that engenders passionate debate. Hah! I have to give you that one. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Wed Mar 24 18:47:03 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 24 Mar 2010 15:47:03 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <3c3e3fca1003241449g29a4a22fjbc175258aee3a1c7@mail.gmail.com> References: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> <17838240D9A5544AAA5FF95F8D52031607D2BDD1@ad-exh01.adhost.lan> <3c3e3fca1003241303u57033bedl4bc44f3a66feb214@mail.gmail.com> <5359E60B-6E2F-4183-86DA-3E939858A93F@delong.com> <3c3e3fca1003241449g29a4a22fjbc175258aee3a1c7@mail.gmail.com> Message-ID: <4D8A62A3-63AA-4D4E-9F7C-F34639B085AC@delong.com> On Mar 24, 2010, at 2:49 PM, William Herrin wrote: > On Wed, Mar 24, 2010 at 4:25 PM, Owen DeLong wrote: >> On Mar 24, 2010, at 1:03 PM, William Herrin wrote: >>> A NAT firewall is a door with a pneumatic closer, a prox card reader >>> and a pin code. This latter is less vulnerable to attack: stealing or >>> duplicating the prox card is as hard or harder than picking a lock and >>> even once you have the card, you still need the matching pin code for >>> entry. >> >> No. A NAT firewall is a door with a lock and a deadbolt at best unless >> rules must be expressed in terms of entry/exit zone in addition to >> source/destination address. > > Owen, > > Believe it or not, I picked the door analogies deliberately. > > Adding a door with a key is like adding a firewall. You can no walk > packets freely in and out of the network. > > The addition of a "pneumatic closer" is consistent with any stateful > firewall. Unlike a basic packet filter, the stateful firewall pulls > the door closed behind the permitted transport sessions, denying other > packets. > OK, I'll give you stateful = pneumatic. > Adding a pin pad is consistent with adding any form of NAT. A mistake > which causes bare routing or any subset of it has to somehow also use > the right translation code. > Not really, or, at least not any more so that requiring rulesets to be expressed in forms which include source and destination security zones as well as IP addresses. > Switching from a key to a prox card is consistent with > address-overloaded NAT specifically. Just as the prox card facilitates > maintaining physical security a little better than keeping track of > metal keys, address overloading saves you from a few more oopses that > would cause mere nat to accept and translate connections where the > single-to-many nature of address overloading can at worst expose a > single host on a given port. > Nope. I still don't buy this argument. The prox card allows you to know who opened the door. It doesn't tell you anything more about who went through the door. NAT does nothing of the sort. It doesn't tell you any more about who opened the door. It doesn't tell you anything more about who went through the door. In fact, it arguably tells you less, or, at least it tells anyone that one of your internal hosts attacks less. It requires the (accidental or deliberate) opening of one more lock, just like a deadbolt. > >>> And I will suggest that for any given firewall configuration, the >>> otherwise-identical configuration that also does NAT has implemented >>> stronger security. >> >> Nope... I provided an example earlier where NAT actually reduced security. > > No, you provided an example where you boldly but mistakenly claimed > that NAT reduced security. > My example was unrefuted. My above example shows that while NAT may offer an additional deadbolt for the site deploying NAT, it certainly can reduce security for sites which are attacked by the hosts you are protecting. Perhaps that is not your concern, since you are still choosing to remain in support of this toxic-polluter model of networking, but, some of us have to look at the whole picture, not just the benefits of individual sites. > > On Wed, Mar 24, 2010 at 4:47 PM, Michael K. Smith - Adhost > wrote: >> The point is that proving NAT is valuable based solely >> upon its perceived benefits for inbound traffic doesn't address >> the issue with all its complexities. > > Hi Mike, > > No argument. > > >> Actually, RFC 1631 says that NAT is for addressing >> address conservation specifically. > > RFC 1631 spoke to the then mostly theoretical concept of NAT as > discussed inside the IETF circa 1993-4. The basic idea was a > one-to-one mapping of internal to external addresses. Only those very > few internal hosts who needed to talk to the Internet would claim an > external address and the external address space was flat, requiring no > per-lan reserve slack and no subnet-oriented reserved IPs. > Ummm... FAIL. If RFC 1631 had not contemplated 1:many NAT, then, there would have been no address conservation aspect to it, as 1:1 NAT does not conserve addresses, it is, at best, a no-op in the number of public addresses consumed, and, could actually double the number of public addresses consumed if the numbers on both sides of the NAT are public addresses. > In other words, it was almost exactly nothing like modern > address-overloaded NAT as found in any commodity "DSL router." > Actually, it was almost EXACTLY what is currently deployed in almost any commodity DSL router. > As modern NAT evolved out of transparent TCP proxies (which had > evolved from the bastion host proxy firewalls), there were a number of > folks who complained it should be called PAT (port address > translation) because it wasn't really NAT. In a sense, they're > right... the NAT name was hijacked by the new, vastly more popular > process even though it bore only a passing resemblance to the old. > While you continue to cling to this revisionist history of NAT/PAT, it continues to remain false. I remember talking extensively on the subject with John Mayes back when he was starting Translation.com (also known as Network Address Translation, Inc.) which was later purchased by Cisco and rebranded into a little known product called a "PIX" Firewall. NAT/PAT grew out of NAT as an extension to Stateful Inspection Firewalls which were then being touted as a superior solution to the TCP proxies which often failed to be sufficiently transparent. > My point is: RFC 1631 describes an obsolete process that has limited > bearing here. > I think someone should re-read RFC-1631. It's not as far out of date as you appear to think. Owen From Lee at dilkie.com Wed Mar 24 18:51:14 2010 From: Lee at dilkie.com (Lee Dilkie) Date: Wed, 24 Mar 2010 18:51:14 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <17838240D9A5544AAA5FF95F8D52031607D2BE35@ad-exh01.adhost.lan> References: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> <17838240D9A5544AAA5FF95F8D52031607D2BDD1@ad-exh01.adhost.lan> <3c3e3fca1003241303u57033bedl4bc44f3a66feb214@mail.gmail.com> <17838240D9A5544AAA5FF95F8D52031607D2BE35@ad-exh01.adhost.lan> Message-ID: <4BAA9762.3000507@dilkie.com> Is no one concerned that NAT breaks a lot of networking, especially peer-to-peer, and forces some really inefficient technologies, like SBC's, to exist? There is a lot of network media traffic (example, VoIP) that is unnecessarily backhauled across the internet because of NAT and in an NAT-less IPv6 world could use less network resources and be more reliable. -lee From bill at herrin.us Wed Mar 24 19:00:11 2010 From: bill at herrin.us (William Herrin) Date: Wed, 24 Mar 2010 19:00:11 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4D8A62A3-63AA-4D4E-9F7C-F34639B085AC@delong.com> References: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> <17838240D9A5544AAA5FF95F8D52031607D2BDD1@ad-exh01.adhost.lan> <3c3e3fca1003241303u57033bedl4bc44f3a66feb214@mail.gmail.com> <5359E60B-6E2F-4183-86DA-3E939858A93F@delong.com> <3c3e3fca1003241449g29a4a22fjbc175258aee3a1c7@mail.gmail.com> <4D8A62A3-63AA-4D4E-9F7C-F34639B085AC@delong.com> Message-ID: <3c3e3fca1003241600m284fd673k53014b036f9e597a@mail.gmail.com> On Wed, Mar 24, 2010 at 6:47 PM, Owen DeLong wrote: > Ummm... FAIL. ?If RFC 1631 had not contemplated 1:many NAT, then, > there would have been no address conservation aspect to it, as 1:1 > NAT does not conserve addresses, Owen, RTFM or I guess in this case, RTFR. 1631 expected conservation because "many (if not most) hosts never communicate outside of their stub domain" and thus "only a subset of the IP addresses inside a stub domain, need be translated into IP addresses that are globally unique when outside communications is required." -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ggiesen at akn.ca Wed Mar 24 19:06:17 2010 From: ggiesen at akn.ca (Gary T. Giesen) Date: Wed, 24 Mar 2010 19:06:17 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BAA9762.3000507@dilkie.com> References: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> <17838240D9A5544AAA5FF95F8D52031607D2BDD1@ad-exh01.adhost.lan> <3c3e3fca1003241303u57033bedl4bc44f3a66feb214@mail.gmail.com> <17838240D9A5544AAA5FF95F8D52031607D2BE35@ad-exh01.adhost.lan> <4BAA9762.3000507@dilkie.com> Message-ID: <1269471977.5400.106.camel@ggiesen-workstation.netsurf.net> I'm inclined to agree. Any perceived benefits from NAT are washed away by the breaking of end-to-end connectivity. Which is partly what IPv6 was designed to rectify. Anything that NAT does can be achieved with a firewall and a well-designed security architecture (such as segregation of hosts into proper security zones, etc). Don't break IPv6 for the rest of us because some people don't know how to design their networks. Let those few suffer the consequences rather than the rest of us. GG On Wed, 2010-03-24 at 18:51 -0400, Lee Dilkie wrote: > Is no one concerned that NAT breaks a lot of networking, especially > peer-to-peer, and forces some really inefficient technologies, like > SBC's, to exist? > > There is a lot of network media traffic (example, VoIP) that is > unnecessarily backhauled across the internet because of NAT and in an > NAT-less IPv6 world could use less network resources and be more reliable. > > -lee > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From asteingruebl at paypal.com Wed Mar 24 19:01:57 2010 From: asteingruebl at paypal.com (Steingruebl, Andy) Date: Wed, 24 Mar 2010 17:01:57 -0600 Subject: [arin-ppml] Comments on Draft Policy 2010-3: Customer Confidentiality Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEA3274E221@DEN-MEXMS-001.corp.ebay.com> This is a response to the suggested policy change 2010-3: Customer Confidentiality - https://www.arin.net/policy/proposals/2010_3.html ARIN has a responsibility to maintain proper records, ensure the accuracy of their database and implement controls to prevent the abuse and inaccuracy of their data. However, we believe this change will create many unintended consequences that will ultimately increase the costs and workload of both ARIN and the ISPs. Among the various unintended consequences, we can see the following as a result of this change: * ISPs will receive abuse complaints related to their customer activity, may or may not take action, may or may not forward to actual customer involved. This will cause increased workload and burden to the ISP. * An ISP may be implicated in illegal activity their customer was engaged in since the party responsible for the IP space is not clearly denoted. * In the event an ISP customer contact shared the same name as an ISP employee, confusion and problems serving legal process will also arise. * A simple traceroute will still allow a competitor to determine what ISP is servicing what customer, thereby providing no confidentiality as suggested by the policy modification. Should we also do away with ICANN domain contact information since it too provides contact details on who owns a specific domain name and may be used to obtain customer contact lists? We don't believe that would serve the public interest either. The concerns we raise above to be aren't purely hypothetical either. Just this week we've seen the publishing of data about possibly malicious ISPs that paints with a fairly broad brush because of how registration data is represented to the outside world. http://maliciousnetworks.org/index.php http://www.krebsonsecurity.com/2010/03/naming-and-shaming-bad-isps/ Without better visibility into the actual bad actors the community is forced to view certain large ISPs with more suspicion than they may be due. More accurate records in WHOIS can help to prevent this situation. -- Andy Steingruebl and Jon Orbeton PayPal Information Risk Management? From owen at delong.com Wed Mar 24 19:15:09 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 24 Mar 2010 16:15:09 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BAA9762.3000507@dilkie.com> References: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> <17838240D9A5544AAA5FF95F8D52031607D2BDD1@ad-exh01.adhost.lan> <3c3e3fca1003241303u57033bedl4bc44f3a66feb214@mail.gmail.com> <17838240D9A5544AAA5FF95F8D52031607D2BE35@ad-exh01.adhost.lan> <4BAA9762.3000507@dilkie.com> Message-ID: I am... Hence my arguments against NAT as "breaking the internet" or, more accurately, operating on a toxic-polluter economic model of the internet. Owen On Mar 24, 2010, at 3:51 PM, Lee Dilkie wrote: > Is no one concerned that NAT breaks a lot of networking, especially > peer-to-peer, and forces some really inefficient technologies, like > SBC's, to exist? > > There is a lot of network media traffic (example, VoIP) that is > unnecessarily backhauled across the internet because of NAT and in an > NAT-less IPv6 world could use less network resources and be more reliable. > > -lee > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bill at herrin.us Wed Mar 24 20:20:54 2010 From: bill at herrin.us (William Herrin) Date: Wed, 24 Mar 2010 20:20:54 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BAA9762.3000507@dilkie.com> References: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> <17838240D9A5544AAA5FF95F8D52031607D2BDD1@ad-exh01.adhost.lan> <3c3e3fca1003241303u57033bedl4bc44f3a66feb214@mail.gmail.com> <17838240D9A5544AAA5FF95F8D52031607D2BE35@ad-exh01.adhost.lan> <4BAA9762.3000507@dilkie.com> Message-ID: <3c3e3fca1003241720t72c387eah366a22576cc7fa6e@mail.gmail.com> On Wed, Mar 24, 2010 at 6:51 PM, Lee Dilkie wrote: > Is no one concerned that NAT breaks a lot of networking, especially > peer-to-peer, and forces some really inefficient technologies, like > SBC's, to exist? Lee, Of course, but the point is largely moot. You can't make me choose not to use NAT and if (when) enough others make the same choice, you won't choose to limit your application's market by failing to design for NAT compatibility. Well, you might but the people whose applications sell and dominate the mindshare won't. > There is a lot of network media traffic (example, VoIP) that is > unnecessarily backhauled across the internet because of NAT The enterprise security guy doesn't want you connecting to his VoIP phones. He wants you connecting to his call proxy firewall (if he had one) where he'll scan for viruses and hacking before passing the voice data on to the phone. If you could talk to the phones you could craft the buffer overflow that pwns the phones and he doesn't want you pwning his phones. You imagine he'd make a different choice about allowing you to send voip traffic to his phones if he was using a non-translating stateful firewall? The '90s Internet is gone man. The benign environment in which the US Office of Naval Research could place its Lan Manager servers bare on the Internet where I could access my file shares via my 28.8 Internet link using Samba, well it's never coming back. Heck, look up the "switchport protected" command. The big corps *use this feature*. They love the idea that the workstations can only talk to the routers and servers! As a business concept, peer to peer is dead. Do not want. NAT didn't kill it. Enterprise network security did. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From farmer at umn.edu Thu Mar 25 00:18:36 2010 From: farmer at umn.edu (David Farmer) Date: Wed, 24 Mar 2010 23:18:36 -0500 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> References: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> Message-ID: <4BAAE41C.2080109@umn.edu> William Herrin wrote: > On Tue, Mar 23, 2010 at 9:01 PM, Owen DeLong wrote: >> On Mar 23, 2010, at 2:04 PM, Chris Engel wrote: >>> Am I wrong? >> I think you overestimate >> the value and underestimate the cost > > Owen, > > I wouldn't bet on it, but in this one respect you're finally talking > about a value judgment where two competent engineers can reasonably > disagree. I'll just say from a technical point of view I can argue both sides to this with a completely strait face. :| However, the real factors that decide security issues are not generally technical, they are risk management issues driven by business factors. In the EDU networking space, we are generally not fans of NAT or Firewalls. But, several years ago, many of us realized that we were spending an order of magnitude more time arguing about how wrong and bad firewalls, than it would actually take to implement them and operate them. So, the business issue was it was better to implement firewalls than to keep arguing about them all the time. We have been able to avoid NAT most up to now, because in general we have had enough IPv4 addresses. But we are starting to implement some NAT for things like open wireless networks, but we use public IP addresses for our WPA2 wireless network. Personally, I would prefer to have public PI addressing for everyone. Even setting aside the global route table politics that creates, in the enterprise would there are to many auditors, risk managers, security consultants, and compliance officers, that think they need/want private addresses. Especially for PCI, HIPPA, and other private protected data. I don't want to argue with them, it will be easier and better for me to get ahead of them and provide them what they think want, but in the way I want to do it. So while I don't personally like it, some kind of tainted, not to be routed, address space will be necessary for IPv6. There will be a lot of different ways we use it, just like we have today with RFC1918. NAT, not connected networks, infrastructure management networks, VPNs, and many many more ways, some we haven't even thought of yet. However, could I suggest that we drop the discussion of competing technical engineering views of network security. NAT v. no NAT, etc... There is no one size fits all solution, your mileage will very, I'll do it my way, you do your way, etc... Can we just leave it at that and try to bring the conversation back to how we want policy in this area to work. We need to enable as many people to implement the right solution for them. And not be arguing about what those solutions are, which one is best, and who understands them better then the other guy. I have seen some good discussion here, but we need to find a consensus that we all can live with. The only way I see that happening is for some compromise to start to taking place. ULA-Random (RFC 4193) with statistical uniqueness seems a slight improvement on and a basic replacement for RFC 1918 in the IPv6 world. However, I think something like ULA-Central provides even more improvement, and would allow a lot of people to rethink the private addressing issue in the IPv6 world. I believe such a solution should have the following properties; - Guaranteed uniqueness, via registration, probably the RIRs - The registration processes should recover assignments no longer in use - Reverse DNS for those that want it - Be designated as not to be routed by default, or only routed by special agreement, A.K.A not for global reachability - It should be justified separately from PA or PI addressing, you can have both one of these and a PI or PA assignment - The amount of space an end-user organization qualifies for should be based on the number of sites they have - The amount of space a service provider qualifies for should be based on the number of sites they have, not their customer's sites Personally, I'm agnostic if we do this with FC00::/8 or within Global Unicast in 2000::/3. But, if we don't use FC00::/8 we shouldn't call it ULA-C. However, a rose or a cow patty by any other name... Remember we already have 6.10.2 Micro-allocations for Internal Infrastructure, this is basically the same thing. The policies involved should prevent the temptation of turning ULA-C into a substitute for PI. Declaring it as not routable by default my not be enough by itself to prevent abuse. I believe ULA-C is an important part of the IPv6 addressing ecosystem, but it needs to work in harmony and co-exist with with the rest of the IPv6 addressing ecosystem, PA, PI, ULA-C, and ULA-L. We need to define policies that make this whole IPv6 addressing ecosystem work for everyone, not just the national backbone ISPs, the regional ISPs, the broadband to the home ISPs, the content providers, or the enterprise network operators, but all of us equally. People ask what the killer app for IPv6 is, I believe it is long-term cost reduction of network operations, IPv4 networks are expensive to operate. Ask the big cable providers why they want to go to IPv6, it is to reduce there cost of network operation. As a large scale enterprise network operator I want to reduce our cost of network operations. Like eliminating (or avoiding, in our specific case) the cost of NAT, /64 subnets in IPv6 will eliminate a whole class of network management costs, managing subnets in IPv4 is an expensive pain in the backside, especially at our scale 2500+ subnets. So, where do we go from here???? -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From marquis at roble.com Thu Mar 25 01:21:41 2010 From: marquis at roble.com (Roger Marquis) Date: Wed, 24 Mar 2010 22:21:41 -0700 (PDT) Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: References: Message-ID: <20100325052141.713742B208E@mx5.roble.com> Lee Dilkie wrote: > Is no one concerned that NAT breaks a lot of networking, especially > peer-to-peer, and forces some really inefficient technologies, like > SBC's, to exist? Statements like this make me wonder if they don't teach the value of field testing in networking curriculums. Without field testing you wouldn't know if the packet filtering that will be needed to replace the privacy and security NAT provides are worse than NAT itself. Field testing would also show that consumers don't want to register their internal IPs, don't want end-to-end transparency, and don't want to give a free pass to badly designed protocols (like SIP) that they require deep packet inspection to work well with NAT. The need for deep inspection is what "breaks a lot of networking". It is a mistake to blame this on NAT. Continuing to make this mistake, and ignore the past few years field trails, or the overwhelming consumer demand (for NAT), will only continue to limit the adoption of IPv6 to those few sites who don't need NAT (mainly carriers). Because of the results of IPv6 field testing I'm willing to bet good money that NAT will be around long after we are all gone, and future network engineers will look back and wonder what those NAT-dissing engineers were smoking. I obviously value field testing. > There is a lot of network media traffic (example, VoIP) that is > unnecessarily backhauled across the internet because of NAT and in an > NAT-less IPv6 world could use less network resources and be more reliable. I don't see that. I see quite the opposite. My own VOIP sites for example, which work seamlessly with NAT. It just works because the firewalls do deep inspection where they have to (SIP) and we use well designed protocols (IAX2) where we can. Roger Marquis From michael.dillon at bt.com Thu Mar 25 07:21:46 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 25 Mar 2010 11:21:46 -0000 Subject: [arin-ppml] The definitive solution to NAT security layers in IPv6 In-Reply-To: <3c3e3fca1003241449g29a4a22fjbc175258aee3a1c7@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C4974580599E1E7@E03MVZ2-UKDY.domain1.systemhost.net> > Adding a door with a key is like adding a firewall. You can > no walk packets freely in and out of the network. > > The addition of a "pneumatic closer" is consistent with any > stateful firewall. Unlike a basic packet filter, the stateful > firewall pulls the door closed behind the permitted transport > sessions, denying other packets. Seems to me that the essence of the IPv4 multilayer defense is to have one box that is a firewall and another box that is a NAT device. In IPv6, it is entirely possible that the stateful inspection function of the IPv4 NAT device, would be incorporated into the IPv6 gateway device which handles the demarcation between ISP and end user network. The specs for these customer edge routers are currently under discussion in the IETF's v6ops working group here: May I suggest that this discussion should move to v6ops where they would welcome input from people experienced in network operations. Seems to me that this has nothing much to do with ARIN policy, at least not until v6ops has issues their RFC. Also, please note that NAT means network address translation and strictly speaking, it is possible to implement network address translation in such a way that it fails wide open to the outside world. In the IPv6 world, it is likely that there will be some form of network address translation but it would be dangerous to assume that IPv6 NAT will have all of the same characteristics of IPv4 NAT. --Michael Dillon From michael.dillon at bt.com Thu Mar 25 07:29:56 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 25 Mar 2010 11:29:56 -0000 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <1269471977.5400.106.camel@ggiesen-workstation.netsurf.net> Message-ID: <28E139F46D45AF49A31950F88C4974580599E20B@E03MVZ2-UKDY.domain1.systemhost.net> > Anything that > NAT does can be achieved with a firewall and a well-designed > security architecture (such as segregation of hosts into > proper security zones, etc). No. You cannot have two layers if you stuff all your security eggs into one firewall basket. IPv4 NAT allows you to use the CE router as an additional security layer. > Don't break IPv6 for the rest of > us because some people don't know how to design their > networks. Let those few suffer the consequences rather than > the rest of us. First, what you ask is impossible. If the so-called "few" misconfigure their networks, we all suffer when our customers cannot make our services work across the other guy's firewall. Secondly, if you want to do something about this in the IETF's 6ops working group, it would be best to not use the term "NAT" which is ambiguous and refers to at least 3 different functions depending on what implementation you are referring to. It seems quite reasonable to ask that IPv6 CE routers have a default configuration that fails in the OFF position, and which only allows incoming packets to sockets that were originated by devices inside the network. This would still break things like incoming phonecalls, unless these CE routers had some way to register devices willing to accept incoming calls. Again, in an IETF WG, you can make the argument for such technology, help create it, and make it so. On ARIN PPML, all you can do is to blow hot air like the rest of us in this thread. Why choose to be an airbag when you could whoosh on over to 6ops and build that pneumatic door locker. --Michael Dillon > > GG > > On Wed, 2010-03-24 at 18:51 -0400, Lee Dilkie wrote: > > Is no one concerned that NAT breaks a lot of networking, especially > > peer-to-peer, and forces some really inefficient technologies, like > > SBC's, to exist? > > > > There is a lot of network media traffic (example, VoIP) that is > > unnecessarily backhauled across the internet because of NAT > and in an > > NAT-less IPv6 world could use less network resources and be > more reliable. > > > > -lee > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed > to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From bill at herrin.us Thu Mar 25 08:19:31 2010 From: bill at herrin.us (William Herrin) Date: Thu, 25 Mar 2010 08:19:31 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BAAE41C.2080109@umn.edu> References: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> <4BAAE41C.2080109@umn.edu> Message-ID: <3c3e3fca1003250519p6bb6c423uc7e56a2c2c2e967f@mail.gmail.com> On Thu, Mar 25, 2010 at 12:18 AM, David Farmer wrote: > Can we just leave it at that and try to bring the conversation back to how > we want policy in this area to work. ?We need to enable as many people to > implement the right solution for them. ?And not be arguing about what those > solutions are, which one is best, and who understands them better then the > other guy. > [...] > However, I think something like ULA-Central provides even more improvement, > and would allow a lot of people to rethink the private addressing issue in > the IPv6 world. Concur. > I believe such a solution should have the following properties; > > - Guaranteed uniqueness, via registration, probably the RIRs > > - The registration processes should recover assignments no longer in use > > - Reverse DNS for those that want it > > - Be designated as not to be routed by default, or only routed by special > agreement, A.K.A not for global reachability > > - It should be justified separately from PA or PI addressing, you can have > both one of these and a PI or PA assignment > > - The amount of space an end-user organization qualifies for should be based > on the number of sites they have > > - The amount of space a service provider qualifies for should be based on > the number of sites they have, not their customer's sites We have a respectable infrastructure in place which implements this kind of work reasonably well: the RIRs. Seems to me that a good starting point would be to add some space and policies for the assignment and management of ULA-C space, whether we carve that out of some portion of GUA space or get it from IANA's reserved FC00::/8. Once we have a policy structure that works for the ULA-C users, we can reasonably step back and see to what degree the ULA-C practices and the GUA practices are in close enough sync to unify the policies. > So, where do we go from here???? If we want to capture FC00::/8 space (which was set aside for this kind of task) then we should write an internet draft and pass it to the appropriate IETF WG. Once published as an RFC, the IANA will be able to delegate portions of FC00::/8 to the RIRs. In the mean time we can start drafting policies that are agnostic to whether ULA assignments come from a block of GUA space that ARIN sets aside from its existing allocation or a new ULA-dedicated one from IANA. To do this, we put an activation date in the policy proposal and direct the board to set aside a distinct block of address space for the purpose as of that date and leave it to the board's discretion as to whether they use a ULA-C delegation if one is available. If ULA-C delegation has made it through IETF by then, great. If not, great. Either way, we're able to move forward. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cengel at sponsordirect.com Thu Mar 25 12:02:30 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Thu, 25 Mar 2010 12:02:30 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: Message-ID: David Farmer wrote: > However, could I suggest that we drop the discussion of competing > technical engineering views of network security. NAT v. no > NAT, etc... There is no one size fits all solution, your > mileage will very, I'll do > it my way, you do your way, etc... > > Can we just leave it at that and try to bring the > conversation back to > how we want policy in this area to work. We need to enable as many > people to implement the right solution for them. And not be arguing > about what those solutions are, which one is best, and who > understands > them better then the other guy. David, Thank you for an injection of a good dose of reason into this discussion. As an aside....one of the largest stumbling blocks to my adoption of IPv6 ...aside from the immense cost of testing hardware/software compatability is the concern that functionality I depend upon every single day (including NAT) won't be supported under it. You are spot on...anything designed to appeal to a wide audience needs to be flexible enough to allow members of that audience to work in different ways....to work in ways that EACH of them feels comfortable with...rather then trying to force everyone into a single box. For me...all I really want is something roughly the equivalent of RFC 1918 space in IPv6... ULA-Random should roughly cover that. Then hopefully if there are enough people with concerns like myself we can drive some vendors to provide NAT like solutions for us to use under IPv6... and those that aren't interested in them can use whatever solution they see best. Even though I'm not particularly interested ULA-C myself...it seems pretty clear to me that there will be a significant segment of folks that want Address space that is both registered uniquely to them...AND designated as "Not to be routed globaly". Christopher Engel From mcr at sandelman.ca Thu Mar 25 12:08:07 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 25 Mar 2010 12:08:07 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BAAE41C.2080109@umn.edu> References: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> <4BAAE41C.2080109@umn.edu> Message-ID: <8037.1269533287@marajade.sandelman.ca> >>>>> "David" == David Farmer writes: David> Personally, I would prefer to have public PI addressing for David> everyone. Even setting aside the global route table politics David> that creates, in the enterprise would there are to many David> auditors, risk managers, security consultants, and compliance David> officers, that think they need/want private David> addresses. Especially for PCI, HIPPA, and other private David> protected data. I don't want to argue with them, it will be David> easier and better for me to get ahead of them and provide David> them what they think want, but in the way I want to do it. I think that these folks will re-evaluate their thinking once they realize that it wasn't the NAT that protected them but the other defenses, and that the NAT got into the way of appropriate responses. I have a customer who is busy trying to figure out which of his thousand VoIP ATA units is misconfiguring, and trying to direct calls to 192.168.1.101... David> So while I don't personally like it, some kind of tainted, David> not to be routed, address space will be necessary for IPv6. ... David> Can we just leave it at that and try to bring the David> conversation back to how we want policy in this area to work. David> We need to enable as many people to implement the right David> solution for them. And not be arguing about what those David> solutions are, which one is best, and who understands them David> better then the other guy. Thank you. I don't care about ULA-R. It doesn't solve the problems I have. TUNNELS. I can get address space from tunnel brokers, and they often give me reverse DNS as well, but not whois, but usually I have do something like route that space somewhere. (i.e. keep the tunnel up). I did this at one place where we decided that we wanted an unrouted IPv6 management network, because we planned to have more nodes than rfc1918 would accomodate. (Plan for success!) We kept the tunnel end point up, and we used one /64 for DNS stuff, and the rest was blackholed routed, and never connected to the management network. Yes, you could see our management infrastructure in public reverse DNS. I can't tell you how much time our operations people saved by being able to just read logs and not have to have endless cheat sheets around to map hex numbers, and the like. (This is a company that had otherwise given up on DNS for all internal things, because, they could never configure all the machines to talk to the right DNS servers...) Tunnels can reclaim address space. 6TO4 I have always liked 6to4 addressing. If you have some IPv4, you have plentiful amount of IPv6. But there was no reverse DNS... Well, it seems that http://6to4.nro.net now lets you populate it... I don't know what the status of this, I recall it being proposed, but it wasn't until December 2009 that I learnt that it been done. I don't know if it will continue. My whois client is smart enough to do a query on the IPv4 block when given a 6to4 network. This is almost good enough: it's good enough for anyone who has a /29 SWIP'ed to get what they want, and recent policy changes mean that I think it could be good enough for everyone, even the smallest mom+pop enterprise on commodity DSL w/static-IP, if the commodity DSL providers would SWIP. 6to4 reclaims IPv6 address space when it recovers IPv4 space. I don't know what 6to4.nro.net will do when someone new comes along in the same address space. I think they just get the new reverse. ULA-C The major reason for this over ULA-R is to get reverse DNS and whois. If there isn't that, then forget it. Just use ULA-R. ULA can be reclaimed if the policy says so. "tainted" GUA. My feeling is that this is better than ULA-C only from the point of view of ARIN. ARIN can do this without cooperation of any other body. I really don't think anyone is going to start with the wrong kind of block and want it converted. Due to fact that we write addressing policy as a work around for allocating DFZ routing slots, I don't see how "tainted" GUA can be allocated for any significant amount less than GUA. $1250 initial fee really is a problem for many organizations. In small organizations because it's expensive. In big organizations because it causes an addititional level of approval. $1250 buys you high-end rack-mounted NAT device, and I'll bet it will do NAT66 very soon. Combine that with PA or 6to4 and ULA-R, and you have a repeat of mid-1990s coconut security. GUA is obviously reclaimable. David> - The amount of space an end-user organization qualifies for David> should be based on the number of sites they have Do you mean, the number of allocations, or the size of the allocations? David> Personally, I'm agnostic if we do this with FC00::/8 or David> within Global Unicast in 2000::/3. But, if we don't use David> FC00::/8 we shouldn't call it ULA-C. However, a rose or a David> cow patty by any other name... Remember we already have David> 6.10.2 Micro-allocations for Internal Infrastructure, this is David> basically the same thing. Everyone has understood that micro-allocation was for IXs. David> People ask what the killer app for IPv6 is, I believe it is David> long-term cost reduction of network operations, IPv4 networks David> are expensive to operate. Ask the big cable providers why David> they want to go to IPv6, it is to reduce there cost of David> network operation. As a large scale enterprise network David> operator I want to reduce our cost of network David> operations. Like eliminating (or avoiding, in our specific David> case) the cost of NAT, /64 subnets in IPv6 will eliminate a David> whole class of network management costs, managing subnets in David> IPv4 is an expensive pain in the backside, especially at our David> scale 2500+ subnets. I concur 200%. I think the AC needs to tell come to some consensus about "tainted"GUA, or ULA-C. I think that the IETF will cooperate if it's ULA-C. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From Lee at Dilkie.com Thu Mar 25 12:32:19 2010 From: Lee at Dilkie.com (Lee Dilkie) Date: Thu, 25 Mar 2010 12:32:19 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <20100325052141.713742B208E@mx5.roble.com> References: <20100325052141.713742B208E@mx5.roble.com> Message-ID: <4BAB9013.3090801@Dilkie.com> On 3/25/2010 1:21 AM, Roger Marquis wrote: > Lee Dilkie wrote: >> Is no one concerned that NAT breaks a lot of networking, especially >> peer-to-peer, and forces some really inefficient technologies, like >> SBC's, to exist? > > Statements like this make me wonder if they don't teach the value of > field testing in networking curriculums. Without field testing you > wouldn't know if the packet filtering that will be needed to replace the > privacy and security NAT provides are worse than NAT itself. Field > testing would also show that consumers don't want to register their > internal IPs, don't want end-to-end transparency, and don't want to give > a free pass to badly designed protocols (like SIP) that they require deep > packet inspection to work well with NAT. I feel like I've been patted on the head. Thanks old timer! > ... > > I don't see that. I see quite the opposite. My own VOIP sites for > example, which work seamlessly with NAT. It just works because the > firewalls do deep inspection where they have to (SIP) and we use well > designed protocols (IAX2) where we can. > > Roger Marquis > Indeed. You must be servicing sites that are either large enough, rich enough, or have no choice but to accept your firewalls to be installed, with it's "deep inspection". I don't have that luxury, my sites are either too small or won't pay for an expensive CRE firewall. Many use very low end devices. And on "deep packet inspection", how does your firewall handle SIP TLS to negotiate a secure media stream (SRTP)? How are you able to inspect that encrypted SIP and SDP? Mine works because it relies on technologies like SBC's to backhaul medai streams to solve the (dumb)NAT issue. Which was the whole point of my original post, NAT makes things less efficient and less reliable because it introduces the need for rendezvous servers (and, for the most part, protocol specific ones at that). I was just voicing the concern that bringing NAT into ipv6 is not a good way to proceed. My own product supports both ipv4 and ipv6 VoIP and I really like being able to get two ipv6 endpoints to stream media directly to each other while ipv4 ones must make use of my SBC. It makes engineering (network load) a whole lot easier (not to mention a lot cheaper). -lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Vissers at opta.nl Thu Mar 25 12:44:52 2010 From: P.Vissers at opta.nl (Vissers, Pepijn) Date: Thu, 25 Mar 2010 17:44:52 +0100 Subject: [arin-ppml] Comments on proposal 2010-3 Message-ID: <10EFE64C262B034C80E92ABECBD4AE4303C4271B@ex2041.bk.opta.nl> On behalf of the Team Internetsafety of the Dutch Telecommunications Authority OPTA, I'd like to comment on the draft proposal 2010-3. The Team Internetsafety conducts spam- and malware investigations related to the Netherlands. All of these investigations have an international component, some of which require us to use ARIN for WHOIS information. As such, we'd like to comment on three possible problem fields with anonymizing the public WHOIS and with that plea AGAINST this proposal. 1. Access to public WHOIS service 2. Access to accurate information 3. Some EU WHOIS situations and their impact on investigations Ad 1. There is a worldwide trend of anonymizing WHOIS databases. ARIN now wants to jump on that wagon as well. In general, as pointed out by previous commenters, WHOIS data is used by good guys as well as bad guys. That publicly available (reliable) WHOIS data is essential to the good guys in the private and public sector is evident: NOT having access to such information, or only through slow mutual legal assistance treaties, severely hampers or even stops investigations and private internet security initiatives. This is a cumulative effect of worldwide anonymisation of WHOIS and is not bound to ARIN data only. However, the more registries decide to take this path, the worse the effect on the investigations of the good guys. A risk with publicly available WHOIS information is the mapping of sensitive data by bad guys. Whereas the good guys tend to use a sniper rifle to pinpoint WHOIS data, the scattershot approach is one more often used by miscreants: get all information and filter out the interesting bits. Restricting large scale ACCESS to WHOIS data, for instance by using web access + captcha only and no CLI, would make scattershot approaches tedious and difficult. Sniper techniques would still be usable for both parties, but that's the balanced risk then, because anonymizing ALL public WHOIS data would surely impact the good guys more than the bad guys. Ad 2. As pointed out by other commenters as well, the reliability of the WHOIS information is far from optimal. That said, it still proves to be valuable information in investigations, be it circumstantial or jump point to other investigative leads, and as such better than no information at all. So anonymizing it 'because it's not reliable now anyway' is no valid argument for this policy: it's a completely different discussion which should be held elsewhere. Ad 3. In the Netherlands, SIDN (the .nl-TLD manager) reduced the WHOIS information in the same way as proposed by ARIN now. Dutch investigative organizations have had to form legal contracts with SIDN to still obtain full .nl-WHOIS data. For other EU countries, access to .nl-WHOIS data is (very) difficult, but doable. Because sharing of personal information outside the EU is very very hard due to Safe Harbor principles, access to .nl-WHOIS for investigative bodies outside the EU is nearly impossible. Not a desirable situation for investigators and a questionable protection from the bad guys; after all: given a (reliable) name, more information is bound to be available on the internet. In comparison, the .eu-WHOIS information (http://www.whois.eu) is available behind a captcha, which (if implemented correctly et al) prevents the scattershot approach but allows the sniper approach. Conclusion. The question of whether or not to anonimize WHOIS data is one that supersedes the ARIN policy alone. However, we think it's a trend that severely hampers public and private investigative bodies more that it does the bad guys. Therefore we advise AGAINST this proposal. FYI: OPTA has reacted, by name of our chairman, on the ICANN WHOIS anonymisation proposal back in 2007. You can find our arguments here: http://forum.icann.org/lists/whois-services-comments/msg00029.html Best regards, Pepijn Vissers Team Internetsafety OPTA, NL +++++++++++++++++++++++++++++++++++++++++++++ Disclaimer Dit e-mailbericht kan vertrouwelijke informatie bevatten of informatie die is beschermd door een beroepsgeheim. Indien dit bericht niet voor u is bestemd, wijzen wij u erop dat elke vorm van verspreiding, vermenigvuldiging of ander gebruik ervan niet is toegestaan. Indien dit bericht blijkbaar bij vergissing bij u terecht is gekomen, verzoeken wij u ons daarvan direct op de hoogte te stellen via tel.nr 070 315 3500 of e-mail mailto:mail at opta.nl en het bericht te vernietigen. Dit e-mailbericht is uitsluitend gecontroleerd op virussen. OPTA aanvaardt geen enkele aansprakelijkheid voor de feitelijke inhoud en juistheid van dit bericht en er kunnen geen rechten aan worden ontleend. This e-mail message may contain confidential information or information protected by professional privilege. If it is not intended for you, you should be aware that any distribution, copying or other form of use of this message is not permitted. If it has apparently reached you by mistake, we urge you to notify us by phone +31 70 315 3500 or e-mail mailto:mail at opta.nl and destroy the message immediately. This e-mail message has only been checked for viruses. The accuracy, relevance, timeliness or completeness of the information provided cannot be guaranteed. OPTA expressly disclaims any responsibility in relation to the information in this e-mail message. No rights can be derived from this message. From owen at delong.com Thu Mar 25 13:44:47 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 25 Mar 2010 10:44:47 -0700 Subject: [arin-ppml] ULA-C vs. "GUA-Tainted" In-Reply-To: <8037.1269533287@marajade.sandelman.ca> References: <3c3e3fca1003240859y6f213d7fu65be0cae2ecd115a@mail.gmail.com> <4BAAE41C.2080109@umn.edu> <8037.1269533287@marajade.sandelman.ca> Message-ID: All, I apologize for creating more confusion than I solved by incorporating a new term. My intent was to distinguish the policy considerations being discussed, not to create an entire new class of addressing. ULA-C is being discussed as an ultra-lightweight allocation process with no justified need, no policies, and very low fees. Such a construct would be disastrous to the internet as it would, overtime, get (mis)used in place of routable GUA because it's easier (and cheaper) to get. My intent with the introduction of the term GUA-tainted was not to create another class of address space, but, to talk about trying to move the allocation/assignment criteria towards a point where they would be acceptable to all communities... Those that want GUA should be able to get GUA and route them or not based on whatever agreements they work out with an ISP to do so. ARIN's role is to distribute the addresses in the interests of the community, not to police the routing table or make value judgments about the worthiness of various networks. ARIN has traditionally had to take some of these latter things on in IPv4 because of address scarcity and the tradeoffs it forced. In IPv6, it is time to move the routing table management back to the ISPs and remove the value judgments other than basic justified need (number of networks needed, number of sites, etc.). Those that want addresses which should not appear in the global routing table by convention, be they ULA-C or some other prefix, should also be able to get them. Those that want some of each should be able to get them. What is important is to make sure that the only driver pushing one to either class of address space above is the nature of their application and their desired implementation. It should not be a fee or policy issue. If it is, then, the less expensive or easier to get address space will get (mis)used as the other type. I hope this clears up the misconceptions about "ULA-C" vs. "GUA-Tainted". If we implement something like "GUA-Tainted" I expect it would be issued from the ULA-C prefix. Owen From tom.ammon at utah.edu Thu Mar 25 13:47:49 2010 From: tom.ammon at utah.edu (Tom Ammon) Date: Thu, 25 Mar 2010 11:47:49 -0600 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <20100325052141.713742B208E@mx5.roble.com> References: <20100325052141.713742B208E@mx5.roble.com> Message-ID: <4BABA1C5.3020005@utah.edu> On 03/24/2010 11:21 PM, Roger Marquis wrote: > Lee Dilkie wrote: > >> Statements like this make me wonder if they don't teach the value of >> field testing in networking curriculums. Without field testing you >> wouldn't know if the packet filtering that will be needed to replace the >> privacy and security NAT provides are worse than NAT itself. Field >> testing would also show that consumers don't want to register their >> internal IPs, don't want end-to-end transparency, and don't want to give >> a free pass to badly designed protocols (like SIP) that they require deep >> packet inspection to work well with NAT. >> >> "networking curriculum"? Where exactly is this "curriculum", other than in $(vendor) Press books and whitepapers? >> The need for deep inspection is what "breaks a lot of networking". It is >> a mistake to blame this on NAT. Continuing to make this mistake, and >> ignore the past few years field trails, or the overwhelming consumer >> demand (for NAT), will only continue to limit the adoption of IPv6 to >> those few sites who don't need NAT (mainly carriers). Because of the >> results of IPv6 field testing I'm willing to bet good money that NAT will >> be around long after we are all gone, and future network engineers will >> look back and wonder what those NAT-dissing engineers were smoking. >> I obviously value field testing. >> >> >> There is a lot of network media traffic (example, VoIP) that is >> unnecessarily backhauled across the internet because of NAT and in an >> NAT-less IPv6 world could use less network resources and be more reliable. >> > I don't see that. I see quite the opposite. My own VOIP sites for > example, which work seamlessly with NAT. It just works because the > firewalls do deep inspection where they have to (SIP) and we use well > designed protocols (IAX2) where we can. > > Roger Marquis > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- -------------------------------------------------------------------- Tom Ammon Network Engineer Office: 801.587.0976 Mobile: 801.674.9273 Center for High Performance Computing University of Utah http://www.chpc.utah.edu From alh-ietf at tndh.net Thu Mar 25 20:00:22 2010 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 25 Mar 2010 17:00:22 -0700 Subject: [arin-ppml] ULA-C Message-ID: <014501cacc77$5573fe00$005bfa00$@net> FYI --- I will be updating https://datatracker.ietf.org/doc/draft-hain-ipv6-ulac/ in the next few weeks. Comments welcome. Tony From marquis at roble.com Fri Mar 26 01:05:34 2010 From: marquis at roble.com (Roger Marquis) Date: Thu, 25 Mar 2010 22:05:34 -0700 (PDT) Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BAB9013.3090801@Dilkie.com> References: <20100325052141.713742B208E@mx5.roble.com> <4BAB9013.3090801@Dilkie.com> Message-ID: <20100326050534.0F7E22B208E@mx5.roble.com> On Thu, 25 Mar 2010, Lee Dilkie wrote: >> Field testing would also show that consumers don't want to register their >> internal IPs, don't want end-to-end transparency, and don't want to give a >> free pass to badly designed protocols (like SIP) that they require deep >> packet inspection to work well with NAT. > > I feel like I've been patted on the head. Thanks old timer! I'll interpret that as a confirmation that they don't tech the value of field testing, much less market analysis, in network engineering classes. > My own product supports both ipv4 and ipv6 VoIP and I really like being > able to get two ipv6 endpoints to stream media directly to each other while > ipv4 ones must make use of my SBC. It makes engineering (network load) a > whole lot easier (not to mention a lot cheaper). Are you assuming consumers will simply open up their firewalls and let (your) protocols through without inspection, were NAT out of the way? I just don't see end users giving SRTP or any other protocol a free pass, regardless of firewall gear, regardless of NAT. Also doubt that the alternative packet inspecting and/or other ACLs would be simpler than NAT. You might float your idea for making network engineering easier (by killing NAT) over on the firewall-wizards mailing list. Roger Marquis From owen at delong.com Fri Mar 26 05:49:30 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 02:49:30 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <20100326050534.0F7E22B208E@mx5.roble.com> References: <20100325052141.713742B208E@mx5.roble.com> <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> Message-ID: <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> > > Are you assuming consumers will simply open up their firewalls and let > (your) protocols through without inspection, were NAT out of the way? I > just don't see end users giving SRTP or any other protocol a free pass, > regardless of firewall gear, regardless of NAT. Also doubt that the > alternative packet inspecting and/or other ACLs would be simpler than > NAT. > I'm certainly making no such assumption, but, yes, the other packet inspecting things are vastly superior to NAT in at least the following ways: 1. Deterministic, predictable troubleshooting 2. They don't require heroic measures in the software to work around the damage introduced by your stateful inspection. Stateful inspection only breaks what it intends to break. NAT breaks all kinds of things whether the administrator wants to allow them or not. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Fri Mar 26 07:18:17 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 26 Mar 2010 11:18:17 -0000 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <8037.1269533287@marajade.sandelman.ca> Message-ID: <28E139F46D45AF49A31950F88C4974580599EA8F@E03MVZ2-UKDY.domain1.systemhost.net> > I have always liked 6to4 addressing. If you have some IPv4, > you have plentiful amount of IPv6. But there was no reverse > DNS... Well, it seems that http://6to4.nro.net now lets you > populate it... Bingo! There is the model for doing reverse DNS for ULA-C. And also for the directory of ULA-C registrations which would be at http://ula.nro.net. That page would explain what ULA is, provide a calculator for generating a ULA-RANDOM address, direct people to the 5 RIR web pages for registering ULA-C addresses, provide a ULA-C directory lookup button, and provide a link for enabling reverse DNS for your ULA-C block. People would then have a choice of whether or not to have reverse DNS or to have it delegated to the same phantom IANA server that handles RFC 1918 reverse DNS. > ULA can be reclaimed if the policy says so. And the RFC could require that the RIRs have a policy covering reclamation, and maintaining an ongoing relationship with ULA-C registrants. > I think the AC needs to tell come to some consensus about > "tainted"GUA, or ULA-C. I think that the IETF will cooperate > if it's ULA-C. I am certain that the IETF will cooperate if the 5 RIRs jointly propose a model for ULA-C. I am also certain that we can do the work in parallel, i.e. it will not be necessary to wait until a ULA-C RFC is finalised before getting some wording for a global policy into the 5 RIR policy proposal processes. --Michael Dillon From bill at herrin.us Fri Mar 26 08:15:26 2010 From: bill at herrin.us (William Herrin) Date: Fri, 26 Mar 2010 08:15:26 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <20100326050534.0F7E22B208E@mx5.roble.com> References: <20100325052141.713742B208E@mx5.roble.com> <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> Message-ID: <3c3e3fca1003260515t6bd556cel1a71ed539377354c@mail.gmail.com> On Fri, Mar 26, 2010 at 1:05 AM, Roger Marquis wrote: > On Thu, 25 Mar 2010, Lee Dilkie wrote: >> My own product supports both ipv4 and ipv6 VoIP and I really like being >> able to get two ipv6 endpoints to stream media directly to each other >> while >> ipv4 ones must make use of my SBC. It makes engineering (network load) a >> whole lot easier (not to mention a lot cheaper). > > Are you assuming consumers will simply open up their firewalls and let > (your) protocols through without inspection, were NAT out of the way? ?I > just don't see end users giving SRTP or any other protocol a free pass, > regardless of firewall gear, regardless of NAT. Roger, Home users will. They do now when the ISP delivers a global IP instead of a NAT router. But business users? Yeah, not a chance. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From farmer at umn.edu Fri Mar 26 08:57:08 2010 From: farmer at umn.edu (David Farmer) Date: Fri, 26 Mar 2010 07:57:08 -0500 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <28E139F46D45AF49A31950F88C4974580599EA8F@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C4974580599EA8F@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4BACAF24.7060508@umn.edu> michael.dillon at bt.com wrote: >> I have always liked 6to4 addressing. If you have some IPv4, >> you have plentiful amount of IPv6. But there was no reverse >> DNS... Well, it seems that http://6to4.nro.net now lets you >> populate it... > > Bingo! > > There is the model for doing reverse DNS for ULA-C. And also > for the directory of ULA-C registrations which would be at > http://ula.nro.net. That page would explain what ULA is, > provide a calculator for generating a ULA-RANDOM address, > direct people to the 5 RIR web pages for registering ULA-C > addresses, provide a ULA-C directory lookup button, and > provide a link for enabling reverse DNS for your ULA-C block. > People would then have a choice of whether or not to have > reverse DNS or to have it delegated to the same phantom IANA > server that handles RFC 1918 reverse DNS. No way, go read RFC 5158, that defines this. It requires you to connect to that web site from the 6to4 address range you want to register, this is what I call implied authorization. How would this kind of implied authorization for an address range that is NOT suppose to be globally routed? Also, if you read the RFC this implied authorization solution has a number of pitfalls that would make it undesirable for enterprise use. It is only acceptable for 6to4 because 6to4 itself is considered a transition mechanism. In other words the problem goes away when you implement native IPv6. But if you can find a way to make it work, I'm happy to reconsider. I just do see how it would work and provide an enterprise class solution. >> ULA can be reclaimed if the policy says so. > > And the RFC could require that the RIRs have a policy covering > reclamation, and maintaining an ongoing relationship with ULA-C > registrants. I believe this is a good idea. This kind of stewardship is why I believe this should be implemented by the RIRs and why it is not going to be as simple and inexpensive as some people think. >> I think the AC needs to tell come to some consensus about >> "tainted"GUA, or ULA-C. I think that the IETF will cooperate >> if it's ULA-C. > > I am certain that the IETF will cooperate if the 5 RIRs jointly > propose a model for ULA-C. I am also certain that we can do > the work in parallel, i.e. it will not be necessary to wait > until a ULA-C RFC is finalised before getting some wording for > a global policy into the 5 RIR policy proposal processes. I agree, my whole purpose for starting this thread is to try to develop that consensus. If you think this kind of addressing is important you should speak up. > --Michael Dillon > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From farmer at umn.edu Fri Mar 26 10:39:56 2010 From: farmer at umn.edu (David Farmer) Date: Fri, 26 Mar 2010 09:39:56 -0500 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BACAF24.7060508@umn.edu> References: <28E139F46D45AF49A31950F88C4974580599EA8F@E03MVZ2-UKDY.domain1.systemhost.net> <4BACAF24.7060508@umn.edu> Message-ID: <4BACC73C.2030009@umn.edu> David Farmer wrote: > michael.dillon at bt.com wrote: >>> I have always liked 6to4 addressing. If you have some IPv4, you have >>> plentiful amount of IPv6. But there was no reverse DNS... Well, it >>> seems that http://6to4.nro.net now lets you populate it... >> >> Bingo! >> >> There is the model for doing reverse DNS for ULA-C. And also >> for the directory of ULA-C registrations which would be at >> http://ula.nro.net. That page would explain what ULA is, >> provide a calculator for generating a ULA-RANDOM address, >> direct people to the 5 RIR web pages for registering ULA-C >> addresses, provide a ULA-C directory lookup button, and >> provide a link for enabling reverse DNS for your ULA-C block. >> People would then have a choice of whether or not to have >> reverse DNS or to have it delegated to the same phantom IANA >> server that handles RFC 1918 reverse DNS. > > No way, go read RFC 5158, that defines this. It requires you to connect > to that web site from the 6to4 address range you want to register, this > is what I call implied authorization. How would this kind of implied > authorization for an address range that is NOT suppose to be globally > routed? > > Also, if you read the RFC this implied authorization solution has a > number of pitfalls that would make it undesirable for enterprise use. It > is only acceptable for 6to4 because 6to4 itself is considered a > transition mechanism. In other words the problem goes away when you > implement native IPv6. > > But if you can find a way to make it work, I'm happy to reconsider. I > just do see how it would work and provide an enterprise class solution. WAIT!!! I got hung up on the implied authorization thing. But, now I realize that is not what you were thinking about. Your right BINGO! A ula.nro.net type mechanism is the way to coordinate the creation of the random prefixes. How about something like this. 1. Registrant generates a prefix on ula.nro.net, the tool can generate regular ULA or registered ULA. For registered ULA the tool puts the prefix into a "pending" state in a database, and creates a ticket that can be registered with an RIR. If the state isn't progressed in some timeout say a week then the prefix is returned to the pool. 2. The Registrant contacts the appropriate RIR, the RIR takes the ticket generated in step 1 and moves the state to "Pending-RIR". The RIR processes and validates the registration. If the RIR refuses the registration or it is dropped, the RIR returns the prefix to the pool. 3. Once the registration is completed, the state is changed to "Registered", and the database points at the RIR for Whois and reverse DNS so that maybe managed via the RIR's tools from this point on. 4. The RIR follows its policies and procedures for the life of the registration. 5. Once the RIR determines the registration is no longer valid (including any hold time) the RIR returns the prefix to the pool. Other than a few worries related to sparse database problems I think it could work. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From bill at herrin.us Fri Mar 26 10:52:20 2010 From: bill at herrin.us (William Herrin) Date: Fri, 26 Mar 2010 10:52:20 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BACC73C.2030009@umn.edu> References: <28E139F46D45AF49A31950F88C4974580599EA8F@E03MVZ2-UKDY.domain1.systemhost.net> <4BACAF24.7060508@umn.edu> <4BACC73C.2030009@umn.edu> Message-ID: <3c3e3fca1003260752s24c542dm3cae37050eb0efe4@mail.gmail.com> On Fri, Mar 26, 2010 at 10:39 AM, David Farmer wrote: > A ula.nro.net type mechanism is the way to coordinate the creation of the > random prefixes. ?How about something like this. David, Something is escaping me here. For *registered* ULA's what's the point of randomization? Wouldn't we better served with sparse? Or perhaps split the space and do half sparse and the other half linear when the requested net count is too large for the largest free space in the sparse area? -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From michael.dillon at bt.com Fri Mar 26 11:21:28 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 26 Mar 2010 15:21:28 -0000 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BACAF24.7060508@umn.edu> Message-ID: <28E139F46D45AF49A31950F88C49745805A135DC@E03MVZ2-UKDY.domain1.systemhost.net> > > Bingo! > > > > There is the model for doing reverse DNS for ULA-C. And > also for the > > directory of ULA-C registrations which would be at > http://ula.nro.net. > No way, go read RFC 5158, that defines this. It requires you > to connect to that web site from the 6to4 address range you > want to register, this is what I call implied authorization. Minor technical detail. Obviously this is not needed for ULA-C since the ULA-C registrant has a relationship with the RIR, and one can assume that when they received their ULA-C address block, they also received a code that could be used to enable reverse DNS at http://ula.nro.net. And if their code had expired, the NRO web page would kindly explain how to go back to the assigning RIR and get a fresh code. > But if you can find a way to make it work, I'm happy to > reconsider. I just do see how it would work and provide an > enterprise class solution. Thanks. I am assuming that we would only assign ULA-C to organizations which sign some form of RSA and which maintain an ongoing ARIN relationship which probably includes a fee covering whatever services are required. > I believe this is a good idea. This kind of stewardship is > why I believe this should be implemented by the RIRs and why > it is not going to be as simple and inexpensive as some people think. Agreed. But if we can get the five RIRs to jointly agree on policy and process then I think that we can get the IETF to agree on architecture. --Michael Dillon From michael.dillon at bt.com Fri Mar 26 11:49:05 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 26 Mar 2010 15:49:05 -0000 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BACC73C.2030009@umn.edu> Message-ID: <28E139F46D45AF49A31950F88C49745805A1363E@E03MVZ2-UKDY.domain1.systemhost.net> > 1. Registrant generates a prefix on ula.nro.net, the tool can > generate regular ULA or registered ULA. While there might be the same tool behind all of this, I would rather have the registrants interact directly with their local RIR and leave the nro.net URL for things like information, directory lookups, and global things like ULA-RANDOM. In other words, a tool on nro.net which would generate ULA-RANDOM according to the RFC documented algorithms. > 2. The Registrant contacts the appropriate RIR, If the nro.net website directs them to the correct RIR page for registering a ULA-C address, then it is sufficient. > 5. Once the RIR determines the registration is no longer > valid (including any hold time) the RIR returns the prefix to > the pool. I think that there should be a hold on any used blocks for about 5 years before releasing them for reuse. > Other than a few worries related to sparse database problems > I think it could work. I'll leave things like that to the RIR tools people. --Michael Dillon From owen at delong.com Fri Mar 26 13:13:51 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 10:13:51 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BACC73C.2030009@umn.edu> References: <28E139F46D45AF49A31950F88C4974580599EA8F@E03MVZ2-UKDY.domain1.systemhost.net> <4BACAF24.7060508@umn.edu> <4BACC73C.2030009@umn.edu> Message-ID: Wouldn't it be easier just to have IANA assign /14s or whatever of ULA- C to the RIRs? Owen On Mar 26, 2010, at 7:39 AM, David Farmer wrote: > David Farmer wrote: >> michael.dillon at bt.com wrote: >>>> I have always liked 6to4 addressing. If you have some IPv4, you >>>> have plentiful amount of IPv6. But there was no reverse DNS... >>>> Well, it seems that http://6to4.nro.net now lets you populate it... >>> >>> Bingo! >>> >>> There is the model for doing reverse DNS for ULA-C. And also >>> for the directory of ULA-C registrations which would be at >>> http://ula.nro.net. That page would explain what ULA is, >>> provide a calculator for generating a ULA-RANDOM address, >>> direct people to the 5 RIR web pages for registering ULA-C >>> addresses, provide a ULA-C directory lookup button, and >>> provide a link for enabling reverse DNS for your ULA-C block. >>> People would then have a choice of whether or not to have >>> reverse DNS or to have it delegated to the same phantom IANA >>> server that handles RFC 1918 reverse DNS. >> No way, go read RFC 5158, that defines this. It requires you to >> connect to that web site from the 6to4 address range you want to >> register, this is what I call implied authorization. How would >> this kind of implied authorization for an address range that is NOT >> suppose to be globally routed? >> Also, if you read the RFC this implied authorization solution has a >> number of pitfalls that would make it undesirable for enterprise >> use. It is only acceptable for 6to4 because 6to4 itself is >> considered a transition mechanism. In other words the problem goes >> away when you implement native IPv6. >> But if you can find a way to make it work, I'm happy to >> reconsider. I just do see how it would work and provide an >> enterprise class solution. > > WAIT!!! I got hung up on the implied authorization thing. But, now > I realize that is not what you were thinking about. > > Your right BINGO! > > A ula.nro.net type mechanism is the way to coordinate the creation > of the random prefixes. How about something like this. > > 1. Registrant generates a prefix on ula.nro.net, the tool can > generate regular ULA or registered ULA. For registered ULA the tool > puts the prefix into a "pending" state in a database, and creates a > ticket that can be registered with an RIR. If the state isn't > progressed in some timeout say a week then the prefix is returned to > the pool. > > 2. The Registrant contacts the appropriate RIR, the RIR takes the > ticket generated in step 1 and moves the state to "Pending-RIR". The > RIR processes and validates the registration. If the RIR refuses > the registration or it is dropped, the RIR returns the prefix to the > pool. > > 3. Once the registration is completed, the state is changed to > "Registered", and the database points at the RIR for Whois and > reverse DNS so that maybe managed via the RIR's tools from this > point on. > > 4. The RIR follows its policies and procedures for the life of the > registration. > > 5. Once the RIR determines the registration is no longer valid > (including any hold time) the RIR returns the prefix to the pool. > > Other than a few worries related to sparse database problems I think > it could work. > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From marquis at roble.com Fri Mar 26 13:29:24 2010 From: marquis at roble.com (Roger Marquis) Date: Fri, 26 Mar 2010 10:29:24 -0700 (PDT) Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> References: <20100325052141.713742B208E@mx5.roble.com> <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> Message-ID: <20100326172924.E3E882B208E@mx5.roble.com> On Fri, 26 Mar 2010, Owen DeLong wrote: >> Are you assuming consumers will simply open up their firewalls and let >> (your) protocols through without inspection, were NAT out of the way? I >> just don't see end users giving SRTP or any other protocol a free pass, >> regardless of firewall gear, regardless of NAT. Also doubt that the >> alternative packet inspecting and/or other ACLs would be simpler than >> NAT. >> > I'm certainly making no such assumption, but, yes, the other packet inspecting > things are vastly superior to NAT in at least the following ways: > > 1. Deterministic, predictable troubleshooting > 2. They don't require heroic measures in the software to work around > the damage introduced by your stateful inspection. Stateful > inspection only breaks what it intends to break. NAT breaks all > kinds of things whether the administrator wants to allow them > or not. Your assertions are vague and general Owen, and not in agreement with my experience. Exactly what step of RTP/SRTP stateful inspection is easier without NAT? Roger Marquis From owen at delong.com Fri Mar 26 13:54:22 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 10:54:22 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <20100326172924.E3E882B208E@mx5.roble.com> References: <20100325052141.713742B208E@mx5.roble.com> <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> Message-ID: <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> On Mar 26, 2010, at 10:29 AM, Roger Marquis wrote: > On Fri, 26 Mar 2010, Owen DeLong wrote: >>> Are you assuming consumers will simply open up their firewalls and >>> let >>> (your) protocols through without inspection, were NAT out of the >>> way? I >>> just don't see end users giving SRTP or any other protocol a free >>> pass, >>> regardless of firewall gear, regardless of NAT. Also doubt that the >>> alternative packet inspecting and/or other ACLs would be simpler >>> than >>> NAT. >>> >> I'm certainly making no such assumption, but, yes, the other packet >> inspecting >> things are vastly superior to NAT in at least the following ways: >> >> 1. Deterministic, predictable troubleshooting OK... To be more specific: There are three possible scenarios for IP communication: Both ends have public IP addresses This is easy. You know what address means what. One end is NATted, the other has a public IP address This is relatively easy to troubleshoot from the NATted end most of the time, IF you have access to the NAT state table. It can be a real pain if you are a host administrator and do not have access to the NAT state table because you cannot easily predict what your packets will look like to the remote side. It is almost always problematic to troubleshoot from the public IP side of the equation because you are usually dealing with a user who can't even spell NAT trying to figure out why their ability to use your service is broken, and, they can't tell you enough about their connection to allow you to even find the packets they are sending you for examination. Both ends are NATted Combine the worst aspects of both of the previous two paragraphs through a multiplicative operation. >> 2. They don't require heroic measures in the software to work around >> the damage introduced by your stateful inspection. Stateful >> inspection only breaks what it intends to break. NAT breaks all >> kinds of things whether the administrator wants to allow them >> or not. > STUN, SNAT, UPNP, and a myriad of other often poorly implemented incompatible and unreliable NAT traversal mechnisms, Application layer Gateways, etc. > Your assertions are vague and general Owen, and not in agreement > with my > experience. Exactly what step of RTP/SRTP stateful inspection is > easier > without NAT? > The stateful inspection is neither easier, nor, more difficult. However, at the far end when I'm trying to figure out why something didn't work, any of the following behaviors related to NAT make things more difficult to debug: 1. RTP packet sourced from 10.x not translated and dropped by outbound firewall because outbound firewall doesn't handle SIP/RTP well. 2. RTP packet sourced from 10.x leaks onto network and gets dropped later. (1 and 2 mean I never see the RTP packet at my side, so, WTF? I have no idea what happened to it and no easy way to know whether it's a NAT issue or something else dropping my customer's traffic) 3. RTP packet sourced from 10.x gets a different NAT pool address than the SIP session and/or STUN setup. Now, RTP packet doesn't match expected source address for flow at my end, but, god only knows why on my side. (And if you think this isn't a real-world situation, think again... I once spent 3 hours debugging a problem with RingCentral related to this where I was stuck on the NATted side of the equation. I then spent another 3 days trying to explain the problem to the management. Instead of resolving the NAT issue, they chose to cancel RingCentral.) 4. There are many many others, but, I think these three that come to me off the top of my head from my own experience are enough to make the point. Owen From marquis at roble.com Fri Mar 26 14:35:05 2010 From: marquis at roble.com (Roger Marquis) Date: Fri, 26 Mar 2010 11:35:05 -0700 (PDT) Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> References: <20100325052141.713742B208E@mx5.roble.com> <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> Message-ID: <20100326183505.7BDBB2B208E@mx5.roble.com> > STUN, SNAT, UPNP, and a myriad of other often poorly implemented > incompatible and unreliable NAT traversal mechnisms, Application > layer Gateways, etc. Sounds like you're asserting that any application wishing to embed the remote IP in the data portion of an IP packet (SIP/STUN/...) or requiring a "hole" in the firewall (UPNP) are valid reasons to get rid of NAT? I don't think you'll find much support for those assertions in security-related groups (like firewall-wizards). > However, at the far end when I'm trying to figure out why something didn't > work, any of the following behaviors related to NAT make things more > difficult to debug: This is an issue with logging, not with NAT or even stateful inspection. > There are many many others, but, I think these three that come > to me off the top of my head from my own experience are > enough to make the point. I don't know who might be persuaded to dump NAT from these examples but from a security perspective they're simply not convincing. That's just my opinion of course, but I encourage you to post them to a computer or network security mailing list and see if they hold water. Roger Marquis From owen at delong.com Fri Mar 26 14:56:00 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 11:56:00 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <20100326183505.7BDBB2B208E@mx5.roble.com> References: <20100325052141.713742B208E@mx5.roble.com> <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> Message-ID: <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> On Mar 26, 2010, at 11:35 AM, Roger Marquis wrote: >> STUN, SNAT, UPNP, and a myriad of other often poorly implemented >> incompatible and unreliable NAT traversal mechnisms, Application >> layer Gateways, etc. > > Sounds like you're asserting that any application wishing to embed the > remote IP in the data portion of an IP packet (SIP/STUN/...) or requiring > a "hole" in the firewall (UPNP) are valid reasons to get rid of NAT? I > don't think you'll find much support for those assertions in > security-related groups (like firewall-wizards). > No... I'm not saying we need a reason to get rid of NAT. I'm saying that NAT should be allowed to become obsolete with IPv4. Those that want the destruction of NAT brought forward to IPv6 are the ones that would need to justify such an action. I'm arguing for the status quo. NAT is implemented and deployed in IPv4 and that's fine. It's not there in IPv6, and, that's good too! >> However, at the far end when I'm trying to figure out why something didn't >> work, any of the following behaviors related to NAT make things more >> difficult to debug: > > This is an issue with logging, not with NAT or even stateful inspection. > Huh? How is logging at the UN-NATted end going to in any way change any of those issues I raised? Remember, I'm talking about the guy that is running the service trying to help his customer, not the customer behind the NAT. >> There are many many others, but, I think these three that come >> to me off the top of my head from my own experience are >> enough to make the point. > > I don't know who might be persuaded to dump NAT from these examples but > from a security perspective they're simply not convincing. That's just > my opinion of course, but I encourage you to post them to a computer or > network security mailing list and see if they hold water. > I'm not trying to get rid of NAT in an existing implementation. I'm trying to avoid the damage known as NAT from being inflicted on a new protocol. Owen From bill at herrin.us Fri Mar 26 15:46:21 2010 From: bill at herrin.us (William Herrin) Date: Fri, 26 Mar 2010 15:46:21 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> References: <20100325052141.713742B208E@mx5.roble.com> <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> Message-ID: <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> On Fri, Mar 26, 2010 at 2:56 PM, Owen DeLong wrote: > No... I'm not saying we need ?a reason to get rid of NAT. I'm saying that > NAT should be allowed to become obsolete with IPv4. That word "alllowed"... I do not think it means what you think it means. -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Fri Mar 26 16:07:58 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 13:07:58 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> References: <20100325052141.713742B208E@mx5.roble.com> <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> Message-ID: <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> On Mar 26, 2010, at 12:46 PM, William Herrin wrote: > On Fri, Mar 26, 2010 at 2:56 PM, Owen DeLong wrote: >> No... I'm not saying we need a reason to get rid of NAT. I'm saying that >> NAT should be allowed to become obsolete with IPv4. > > That word "alllowed"... I do not think it means what you think it means. > I believe that it means exactly what I intended per the definition below. Below excerpted from the dictionary widget in MacOS X 10.6 dashboard. allow |??lou| verb [ trans. ] 1 admit (an event or activity) as legal or acceptable : a plan to allow Sunday shopping | a reservoir with no hunting or overnight camping allowed. ... ? [ trans. ] fail to prevent (something) from happening : I could not believe that we would allow the opportunity to slip away. ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lee at dilkie.com Fri Mar 26 16:14:32 2010 From: Lee at dilkie.com (Lee Dilkie) Date: Fri, 26 Mar 2010 16:14:32 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> References: <20100325052141.713742B208E@mx5.roble.com> <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> Message-ID: <4BAD15A8.80909@dilkie.com> Owen DeLong wrote: > Those that want the destruction of NAT brought forward to IPv6 are the > ones that would need to justify such an action. I'm arguing for the status > quo. NAT is implemented and deployed in IPv4 and that's fine. It's not > there in IPv6, and, that's good too! > hear hear.. From bill at herrin.us Fri Mar 26 16:18:55 2010 From: bill at herrin.us (William Herrin) Date: Fri, 26 Mar 2010 16:18:55 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> Message-ID: <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> On Fri, Mar 26, 2010 at 4:07 PM, Owen DeLong wrote: > On Mar 26, 2010, at 12:46 PM, William Herrin wrote: > On Fri, Mar 26, 2010 at 2:56 PM, Owen DeLong wrote: >> No... I'm not saying we need ?a reason to get rid of NAT. I'm saying that >> NAT should be allowed to become obsolete with IPv4. > > That word "alllowed"... I do not think it means what you think it means. > > > I believe that it means exactly what I intended per the definition below. >?admit (an event or activity) as legal or acceptable > fail to prevent (something) from happening Why then I apologize, because I thought you meant to convey that NAT should be *required* to become obsolete with IPv4, perhaps by obstructing folks' choice to use it in IPv6. Surely Roger only meant to offer his opinion that given a choice, few network security professionals would choose to abandon the use NAT. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From marquis at roble.com Fri Mar 26 16:55:55 2010 From: marquis at roble.com (Roger Marquis) Date: Fri, 26 Mar 2010 13:55:55 -0700 (PDT) Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> Message-ID: <20100326205555.D66402B2126@mx5.roble.com> >> I believe that it means exactly what I intended per the definition below. >> ?admit (an event or activity) as legal or acceptable >> fail to prevent (something) from happening > > Why then I apologize, because I thought you meant to convey that NAT > should be *required* to become obsolete with IPv4, perhaps by > obstructing folks' choice to use it in IPv6. Surely Roger only meant > to offer his opinion that given a choice, few network security > professionals would choose to abandon the use NAT. It isn't just network security professionals who won't give up NAT, end-user consumers also won't. If anything is clear from the past few year's field trials it's that IPv6 has received a vote of no confidence from consumers. It has received that thumbs down primarily because it lacks address translation. IMO there's no painless way to transition to IPv6 without NAT. Compound that with the security issues created by the lack of NAT and, well, you have where we are today. Roger From cengel at sponsordirect.com Fri Mar 26 17:02:18 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Fri, 26 Mar 2010 17:02:18 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: Message-ID: Owen Delong wrote: > However, at the far end when I'm trying to figure out why something > didn't > work, any of the following behaviors related to NAT make things more > difficult to debug: > > 1. RTP packet sourced from 10.x not translated and dropped > by outbound > firewall because outbound firewall doesn't handle SIP/RTP well. > > 2. RTP packet sourced from 10.x leaks onto network and gets dropped > later. > > (1 and 2 mean I never see the RTP packet at my side, so, WTF? > I have no > idea what happened to it and no easy way to know whether it's a NAT > issue or something else dropping my customer's traffic) Not to sound like the village idiot here... and I probably will since I have ZERO experience with VOIP protocols.... but how would this be qualitatevly different from the Remote Admin having a filter rule on his Firewall that silently drops such traffic anyway? I mean, if you aren't getting any traffic through...it's not like you would (in the absence of NAT) have this crystal ball that tells you WHY that traffic isn't getting through. Other then some very basic tests say for general internet connecivity and maybe a tracert to your IP... I would think you'd pretty much HAVE to contact the Admin on the other side of things to work out the issue. Speaking as an Enterprise Admin... I don't WANT any traffic crossing my network boundary that I haven't specificaly setup mechanisms to allow. I also don't WANT any of my end users working with some outside Tech trying to route something through my Firewall that I haven't specificaly setup and approved.... in fact, around here we consider that kinda a "firing offense" (pretty common rule in Enterprises). The way a scenerio like that would go down if it happaned here would be: 1) You'd call up one of my end users to try to figure out why the connection wasn't getting through. 2) They (if they listened to thier training at all) would conference me or one of my staff in to help "resolve" the issue. 3) We would inform you (and them) that what you were trying to hookup wasn't a "Supported Application" on our network and therefore wasn't allowed... and wish you a nice day. 4) I would then point out to said end user, the section of the security policy which they signed that covers the procedure for requesting new applications/functionality. 5) Thier supervisor would have a nice private chat with them. The whole thing shouldn't take more then 10-15 minutes of time.... and certainly shouldn't involve much pain on your end. Christopher Engel From scottleibrand at gmail.com Fri Mar 26 17:20:14 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 26 Mar 2010 14:20:14 -0700 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <20100326205555.D66402B2126@mx5.roble.com> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> Message-ID: <4BAD250E.10805@gmail.com> On Fri 3/26/2010 1:55 PM, Roger Marquis wrote: > > It isn't just network security professionals who won't give up NAT, > end-user consumers also won't. If anything is clear from the past few > year's field trials it's that IPv6 has received a vote of no confidence > from consumers. It has received that thumbs down primarily because it > lacks address translation. Are you talking about NAT66, NAT64, or something else? I personally have not seen this backlash against NAT-less IPv6 by end users. There have been some complaints about the insecurity of enabling a new protocol by accident, but I haven't seen anyone maintaining that NAT66 is a security requirement for home users. I will agree that a stateful firewall needs to be built in to home IPv6 routers to disallow incoming IPv6 connections by default, except where allowed by the user (or by something like uPNP). That doesn't require NAT66, though, at least in the simple home environment. > IMO there's no painless way to transition to IPv6 without NAT. I assume you're talking about NAT-PT here? > Compound that with the security issues created by the lack of NAT > and, well, you > have where we are today. Up 'til now we've mostly been talking about NAT66 (IPv6 inside, IPv6 outside), rather than the various flavors of NAT-PT (NAT64 or NAT46 for example). We also haven't been very specific about whether we're talking 1:1 NAT66, or some sort of overloaded 1:many NAT (like we usually use in IPv4 NAT). Leaving aside NAT-PT and v4-v6 transition for the moment, can you clarify how you would like to deploy NAT in an IPv6-only environment? Thanks, Scott From craig.finseth at state.mn.us Fri Mar 26 17:11:03 2010 From: craig.finseth at state.mn.us (Craig Finseth) Date: Fri, 26 Mar 2010 16:11:03 -0500 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <20100326205555.D66402B2126@mx5.roble.com> (message from Roger Marquis on Fri, 26 Mar 2010 13:55:55 -0700) References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> Message-ID: <201003262111.o2QLB3sK010124@inana.itg.state.mn.us> >> I believe that it means exactly what I intended per the definition below= =2E >> =A0admit (an event or activity) as legal or acceptable >> fail to prevent (something) from happening > > Why then I apologize, because I thought you meant to convey that NAT > should be *required* to become obsolete with IPv4, perhaps by > obstructing folks' choice to use it in IPv6. Surely Roger only meant > to offer his opinion that given a choice, few network security > professionals would choose to abandon the use NAT. It isn't just network security professionals who won't give up NAT, end-user consumers also won't. If anything is clear from the past few year's field trials it's that IPv6 has received a vote of no confidence from consumers. It has received that thumbs down primarily because it lacks address translation. As a consumer, I'm not aware of voting at all... More realistically, I haven't got a choice: the Cisco 675(or 8) that I use doesn't support v6, so I'm stuck until it gets upgraded. Yes, I use NAT and have a way of organizing my internal network: this puts me above 99.99...% of all consumers. If I was using v6, I wouldn't need NAT at all. I strongly suspect that most consumers use NAT because that's how their providers configure it and couldn't care less (or even know) about it. Craig From mcr at sandelman.ca Fri Mar 26 17:31:53 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 26 Mar 2010 17:31:53 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BACAF24.7060508@umn.edu> References: <28E139F46D45AF49A31950F88C4974580599EA8F@E03MVZ2-UKDY.domain1.systemhost.net> <4BACAF24.7060508@umn.edu> Message-ID: <7771.1269639113@marajade.sandelman.ca> >>>>> "David" == David Farmer writes: >> Bingo! There is the model for doing reverse DNS for ULA-C. And >> also for the directory of ULA-C registrations which would be at >> http://ula.nro.net. That page would explain what ULA is, provide >> a calculator for generating a ULA-RANDOM address, direct people >> to the 5 RIR web pages for registering ULA-C addresses, provide a >> ULA-C directory lookup button, and provide a link for enabling >> reverse DNS for your ULA-C block. People would then have a >> choice of whether or not to have reverse DNS or to have it >> delegated to the same phantom IANA server that handles RFC 1918 >> reverse DNS. David> No way, go read RFC 5158, that defines this. It requires you David> to connect to that web site from the 6to4 address range you David> want to register, this is what I call implied authorization. David> How would this kind of implied authorization for an address David> range that is NOT suppose to be globally routed? This is why 6to4 is not very useable for NCN. In the absense of a cheaply available NCN space (i.e. 10x cheaper than GUA), then the answer that works today is use some 6to4. If you allocate NCN space via another mechanism (tainted, or ULA-C), then reverse gets delegated via the normal mechanism. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From farmer at umn.edu Fri Mar 26 17:33:01 2010 From: farmer at umn.edu (David Farmer) Date: Fri, 26 Mar 2010 16:33:01 -0500 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <3c3e3fca1003260752s24c542dm3cae37050eb0efe4@mail.gmail.com> References: <28E139F46D45AF49A31950F88C4974580599EA8F@E03MVZ2-UKDY.domain1.systemhost.net> <4BACAF24.7060508@umn.edu> <4BACC73C.2030009@umn.edu> <3c3e3fca1003260752s24c542dm3cae37050eb0efe4@mail.gmail.com> Message-ID: <4BAD280D.1010706@umn.edu> William Herrin wrote: > On Fri, Mar 26, 2010 at 10:39 AM, David Farmer wrote: >> A ula.nro.net type mechanism is the way to coordinate the creation of the >> random prefixes. How about something like this. > > David, > > Something is escaping me here. For *registered* ULA's what's the point > of randomization? Wouldn't we better served with sparse? Or perhaps > split the space and do half sparse and the other half linear when the > requested net count is too large for the largest free space in the > sparse area? I'm not sure it is entirely necessary. But, there is an elegance to both kinds of ULA using an identical prefix selection algorithm. The only difference is if the Local/Central is being set or not. Which I believe was the original intent of how ULA was designed. This would also underscore the differences between ULA-C and PI addressing. Some people have said that ULA-C needed to have a random prefix selection algorithm too, I don't really care either way. But, if we allocate large blocks to the RIRs, why not let the RIRs manage the whole assignment process and just use their normal processes. I don't see any benefit to allocating large blocks and then requiring the RIRs to use a random prefix selection algorithm within those blocks. If your going to have a different prefix selection algorithm, between ULA-C and ULA-L, why make a third one, just use the RIRs normal one. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From mcr at sandelman.ca Fri Mar 26 17:43:30 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 26 Mar 2010 17:43:30 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BACC73C.2030009@umn.edu> References: <28E139F46D45AF49A31950F88C4974580599EA8F@E03MVZ2-UKDY.domain1.systemhost.net> <4BACAF24.7060508@umn.edu> <4BACC73C.2030009@umn.edu> Message-ID: <8838.1269639810@marajade.sandelman.ca> >>>>> "David" == David Farmer writes: David> WAIT!!! I got hung up on the implied authorization thing. David> But, now I realize that is not what you were thinking about. David> Your right BINGO! David> A ula.nro.net type mechanism is the way to coordinate the David> creation of the random prefixes. How about something like David> this. David> 1. Registrant generates a prefix on ula.nro.net, the tool can David> generate regular ULA or registered ULA. For registered ULA David> the tool puts the prefix into a "pending" state in a David> database, and creates a ticket that can be registered with an David> RIR. If the state isn't progressed in some timeout say a David> week then the prefix is returned to the pool. David> 2. The Registrant contacts the appropriate RIR, the RIR takes David> the ticket generated in step 1 and moves the state to David> "Pending-RIR". The RIR processes and validates the David> registration. If the RIR refuses the registration or it is David> dropped, the RIR returns the prefix to the pool. David> 3. Once the registration is completed, the state is changed David> to "Registered", and the database points at the RIR for Whois David> and reverse DNS so that maybe managed via the RIR's tools David> from this point on. David> 4. The RIR follows its policies and procedures for the life David> of the registration. David> 5. Once the RIR determines the registration is no longer David> valid (including any hold time) the RIR returns the prefix to David> the pool. David> Other than a few worries related to sparse database problems David> I think it could work. I am happy with this process. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From bill at herrin.us Fri Mar 26 17:44:22 2010 From: bill at herrin.us (William Herrin) Date: Fri, 26 Mar 2010 17:44:22 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <20100326205555.D66402B2126@mx5.roble.com> References: <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> Message-ID: <3c3e3fca1003261444t6b53f284v2d0ea47e42aac9c6@mail.gmail.com> On Fri, Mar 26, 2010 at 4:55 PM, Roger Marquis wrote: >> Why then I apologize, because I thought you meant to convey that NAT >> should be *required* to become obsolete with IPv4, perhaps by >> obstructing folks' choice to use it in IPv6. Surely Roger only meant >> to offer his opinion that given a choice, few network security >> professionals would choose to abandon the use NAT. > > It isn't just network security professionals who won't give up NAT, > end-user consumers also won't. Oh, I don't know about that. Consumers generally use what the ISP provides. One persuasive argument against an ISP deploying customer NAT is that a non-NAT firewall/router will induce fewer costly support calls about how to configure bittorrent, warcraft, etc., while the bulk of their security clean-up headache will come from spam-linked trojans regardless. Just don't expect that argument to sell with the enterprise customers. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ggiesen at akn.ca Fri Mar 26 17:48:16 2010 From: ggiesen at akn.ca (Gary T. Giesen) Date: Fri, 26 Mar 2010 17:48:16 -0400 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <4BAD250E.10805@gmail.com> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> Message-ID: <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> The problem with NAT in v6 land (NAT66) is it introduces the temptation to overload addresses (like PAT), because that's what people are used to. In V6, I can't think of a good reason why you'd want to overload addresses. IMHO it's better to get people used to having no NAT at all (since they're getting used to a new protocol anyways), and as you suggested, a stateful firewall (no unsolicited connections from outside) and separate your hosts into proper security zones to ensure a typo in a firewall rule limits your exposure. For home users, under this scenario, their experience would be largely unchanged (your NAT'd subnet merely becomes a routed subnet) but we would be able to achieve large gains in visibility when troubleshooting problems without having to deal with the NAT black hole. Firewall rules become simpler to configure and understand because we're not translating addresses all over the place. At some point the people who are using NAT as a security mechanism will have to take responsibility for their networks and ensure that their policies are well-designed and implemented. Adding it to v6 (which was designed largely to supplant it) is an abomination and there's no reason for it. NAT is not a security mechanism. It was created to as a) an address transition mechanism (for which there are alternatives in v6) and b) as an address conservation mechanism (not required in v6). My $0.02. GG On Fri, 2010-03-26 at 17:20 -0400, Scott Leibrand wrote: > On Fri 3/26/2010 1:55 PM, Roger Marquis wrote: > > > > It isn't just network security professionals who won't give up NAT, > > end-user consumers also won't. If anything is clear from the past few > > year's field trials it's that IPv6 has received a vote of no confidence > > from consumers. It has received that thumbs down primarily because it > > lacks address translation. > > Are you talking about NAT66, NAT64, or something else? I personally > have not seen this backlash against NAT-less IPv6 by end users. There > have been some complaints about the insecurity of enabling a new > protocol by accident, but I haven't seen anyone maintaining that NAT66 > is a security requirement for home users. I will agree that a stateful > firewall needs to be built in to home IPv6 routers to disallow incoming > IPv6 connections by default, except where allowed by the user (or by > something like uPNP). That doesn't require NAT66, though, at least in > the simple home environment. > > > IMO there's no painless way to transition to IPv6 without NAT. > > I assume you're talking about NAT-PT here? > > > Compound that with the security issues created by the lack of NAT > > and, well, you > > have where we are today. > > Up 'til now we've mostly been talking about NAT66 (IPv6 inside, IPv6 > outside), rather than the various flavors of NAT-PT (NAT64 or NAT46 for > example). We also haven't been very specific about whether we're > talking 1:1 NAT66, or some sort of overloaded 1:many NAT (like we > usually use in IPv4 NAT). > > Leaving aside NAT-PT and v4-v6 transition for the moment, can you > clarify how you would like to deploy NAT in an IPv6-only environment? > > Thanks, > Scott > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From matthew at matthew.at Fri Mar 26 17:54:24 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 26 Mar 2010 14:54:24 -0700 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> Message-ID: <4BAD2D10.4060107@matthew.at> Gary T. Giesen wrote: > IMHO it's better to get people used to having no NAT at all (since > they're getting used to a new protocol anyways)... Please explain how you intend to eliminate manual renumbering for corporate internal networks every time they change ISPs. (And note that RA and even DHCP6 don't fix all the manual setup of things like "what is the address of the intranet web server".) There is a real cost to this, and the cost of a NAT device is pretty much paid off the first or second time you're forced to renumber. Matthew Kaufman From owen at delong.com Fri Mar 26 17:54:25 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 14:54:25 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: References: Message-ID: On Mar 26, 2010, at 2:02 PM, Chris Engel wrote: > Owen Delong wrote: > >> However, at the far end when I'm trying to figure out why something >> didn't >> work, any of the following behaviors related to NAT make things more >> difficult to debug: >> >> 1. RTP packet sourced from 10.x not translated and dropped >> by outbound >> firewall because outbound firewall doesn't handle SIP/RTP well. >> >> 2. RTP packet sourced from 10.x leaks onto network and gets dropped >> later. >> >> (1 and 2 mean I never see the RTP packet at my side, so, WTF? >> I have no >> idea what happened to it and no easy way to know whether it's a NAT >> issue or something else dropping my customer's traffic) > > > Not to sound like the village idiot here... and I probably will since I have ZERO experience with VOIP protocols.... but how would this be qualitatevly different from the Remote Admin having a filter rule on his Firewall that silently drops such traffic anyway? > Because the customer can tell me what packets I'm looking for in my log to be able to tell definitively that they never arrived at my system. Without NAT: Me: What is your IP address? Customer: 192.159.10.92 (example only) Me: (greps logs for 192.159.10.92) Me: Hmmm... I don't see any packets from that address in my logs. Can you check with your firewall administrator to see if they might be blocking it? With NAT: Me: What is your IP address? Customer: 10.0.0.5 Me: Um, do you, by any chance know what address or range of addresses your firewall uses on the outside to represent that address? Customer: Uh, what's a firewall? ... Let the games begin ... No, before you start telling me that I should have the customer go to "whatismyipaddress" or similar, be aware that is only useful if the firewall presents only 1 consistent address for a given user. Often firewalls have pools of NAT addresses and they do not. > I mean, if you aren't getting any traffic through...it's not like you would (in the absence of NAT) have this crystal ball that tells you WHY that traffic isn't getting through. Other then some very basic tests say for general internet connecivity and maybe a tracert to your IP... I would think you'd pretty much HAVE to contact the Admin on the other side of things to work out the issue. > Sure, but, the difference, as illustrated above is that without NAT, I can tell deterministically that the packet did not arrive based on information the customer can easily provide. With NAT, it becomes much more of a guessing game which often requires information the customer may not have and often does not know how to get. > Speaking as an Enterprise Admin... I don't WANT any traffic crossing my network boundary that I haven't specificaly setup mechanisms to allow. I also don't WANT any of my end users working with some outside Tech trying to route something through my Firewall that I haven't specificaly setup and approved.... in fact, around here we consider that kinda a "firing offense" (pretty common rule in Enterprises). > Sure... A deny-all stateful inspection firewall will do that. You're assuming that the incapable customer above is one of your users. I'm assuming that they're the average IT administrator in the small to medium enterprise. If you think I am wrong about the quality of average IT administrators, I suggest you spend some time working technical support at a service provider. > The way a scenerio like that would go down if it happaned here would be: > > 1) You'd call up one of my end users to try to figure out why the connection wasn't getting through. > No, your end user called me because his SIP soft phone isn't working while he's at work, but, it works when he's at the internet cafe and at home. > 2) They (if they listened to thier training at all) would conference me or one of my staff in to help "resolve" the issue. > It would be nice if they called you, but, when they call me instead, it's my job to try and help them anyway. > 3) We would inform you (and them) that what you were trying to hookup wasn't a "Supported Application" on our network and therefore wasn't allowed... and wish you a nice day. > That's great, when it works. However, when your user calls me, I don't even know you exist, and, the fact that they have a 10.0.0.5 address doesn't exactly help me find you, either. > 4) I would then point out to said end user, the section of the security policy which they signed that covers the procedure for requesting new applications/functionality. > That's between you and your user... Whatever. However, you're spending resources and time at my company to deal with the deficiencies in your training program because of the damage being inflicted by your network configuration. If I can send you a bill for those calls, then, we're all good. Otherwise, I maintain that, as stated before, NAT is toxic pollution which causes costs in places where they are not paid by the one dumping the toxins. > 5) Thier supervisor would have a nice private chat with them. > That's an entirely internal matter to your business. > The whole thing shouldn't take more then 10-15 minutes of time.... and certainly shouldn't involve much pain on your end. > You are assuming a lot more about human behavior by less qualified individuals than is required in my assertion that people should properly configure their firewalls. If I have to tolerate NAT and it's damage because you can't reliably avoid mistakes that fail open on your firewalls, then, you need to allow for a way to reimburse my costs that come from your even less qualified end users that also happen to be my customers. Owen From owen at delong.com Fri Mar 26 17:56:47 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 14:56:47 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <20100326205555.D66402B2126@mx5.roble.com> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> Message-ID: <3C5EE00C-7B9E-4FCE-8903-CF736A687511@delong.com> On Mar 26, 2010, at 1:55 PM, Roger Marquis wrote: >>> I believe that it means exactly what I intended per the definition below. >>> admit (an event or activity) as legal or acceptable >>> fail to prevent (something) from happening >> >> Why then I apologize, because I thought you meant to convey that NAT >> should be *required* to become obsolete with IPv4, perhaps by >> obstructing folks' choice to use it in IPv6. Surely Roger only meant >> to offer his opinion that given a choice, few network security >> professionals would choose to abandon the use NAT. > > It isn't just network security professionals who won't give up NAT, > end-user consumers also won't. If anything is clear from the past few > year's field trials it's that IPv6 has received a vote of no confidence > from consumers. It has received that thumbs down primarily because it > lacks address translation. > Um, What?!? Things actually slowing down residential IPv6 deployment: + Lack of CPE support + Lack of Head-End (PON concentrator, DSLAM, CMTS, etc.) support + Lack of support from the ISP One only need look at the free.fr deployment to see that consumers are actually embracing IPv6 when it is readily available to them without NAT. > IMO there's no painless way to transition to IPv6 without NAT. Compound > that with the security issues created by the lack of NAT and, well, you > have where we are today. > Having actually transitioned to dual stack without NAT (in either stack) and without any security issues resulting from that fact, I'm perfectly willing to say that I do not believe you because I have experience otherwise. Owen From scottleibrand at gmail.com Fri Mar 26 18:00:54 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 26 Mar 2010 15:00:54 -0700 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <4BAD2D10.4060107@matthew.at> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> Message-ID: <4BAD2E96.7080504@gmail.com> On Fri 3/26/2010 2:54 PM, Matthew Kaufman wrote: > Please explain how you intend to eliminate manual renumbering for > corporate internal networks every time they change ISPs. > > (And note that RA and even DHCP6 don't fix all the manual setup of > things like "what is the address of the intranet web server".) > > There is a real cost to this, and the cost of a NAT device is pretty > much paid off the first or second time you're forced to renumber. > > Matthew Kaufman Matthew, So it sounds like you're describing something like private IPv6 addresses on the inside, NAT66 at the edge, doing 1:1 mapping of the inside private IPv6 prefix to the currently-active outside public IPv6 prefix? Does that accurately describe this use case? Thanks, Scott From matthew at matthew.at Fri Mar 26 18:03:49 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 26 Mar 2010 15:03:49 -0700 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <4BAD2E96.7080504@gmail.com> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <4BAD2E96.7080504@gmail.com> Message-ID: <4BAD2F45.7050906@matthew.at> Scott Leibrand wrote: > On Fri 3/26/2010 2:54 PM, Matthew Kaufman wrote: >> Please explain how you intend to eliminate manual renumbering for >> corporate internal networks every time they change ISPs. >> >> (And note that RA and even DHCP6 don't fix all the manual setup of >> things like "what is the address of the intranet web server".) >> >> There is a real cost to this, and the cost of a NAT device is pretty >> much paid off the first or second time you're forced to renumber. >> >> Matthew Kaufman > > Matthew, > > So it sounds like you're describing something like private IPv6 > addresses on the inside, NAT66 at the edge, doing 1:1 mapping of the > inside private IPv6 prefix to the currently-active outside public IPv6 > prefix? > > Does that accurately describe this use case? > > Thanks, > Scott That should be sufficient, yes. And of course I'd want my private IPv6 to come from a range I was sure nobody I ever acquired or was acquired by was using. Address overloading is probably not necessary. A nice side effect is that I can have my NAT tweak the bottom 64 bits in case my hosts insist on exposing details of their MAC address there (which I consider to be a security problem). Matthew Kaufman From owen at delong.com Fri Mar 26 18:00:33 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 15:00:33 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BAD280D.1010706@umn.edu> References: <28E139F46D45AF49A31950F88C4974580599EA8F@E03MVZ2-UKDY.domain1.systemhost.net> <4BACAF24.7060508@umn.edu> <4BACC73C.2030009@umn.edu> <3c3e3fca1003260752s24c542dm3cae37050eb0efe4@mail.gmail.com> <4BAD280D.1010706@umn.edu> Message-ID: <6F204832-483E-494A-BF8D-7B656672C3DA@delong.com> On Mar 26, 2010, at 2:33 PM, David Farmer wrote: > William Herrin wrote: >> On Fri, Mar 26, 2010 at 10:39 AM, David Farmer wrote: >>> A ula.nro.net type mechanism is the way to coordinate the creation of the >>> random prefixes. How about something like this. >> David, >> Something is escaping me here. For *registered* ULA's what's the point >> of randomization? Wouldn't we better served with sparse? Or perhaps >> split the space and do half sparse and the other half linear when the >> requested net count is too large for the largest free space in the >> sparse area? > > I'm not sure it is entirely necessary. But, there is an elegance to both kinds of ULA using an identical prefix selection algorithm. The only difference is if the Local/Central is being set or not. Which I believe was the original intent of how ULA was designed. This would also underscore the differences between ULA-C and PI addressing. > > Some people have said that ULA-C needed to have a random prefix selection algorithm too, I don't really care either way. But, if we allocate large blocks to the RIRs, why not let the RIRs manage the whole assignment process and just use their normal processes. I don't see any benefit to allocating large blocks and then requiring the RIRs to use a random prefix selection algorithm within those blocks. If your going to have a different prefix selection algorithm, between ULA-C and ULA-L, why make a third one, just use the RIRs normal one. > > I'm in favor of assigning large blocks of ULA-C to RIRs and having them manage it identically to GUA where the choice of GUA or ULA-C becomes a checkbox on the IP application form and nothing else. That is what I have been advocating all along. I am opposed to ULA-C on almost any other terms. Owen From ggiesen at akn.ca Fri Mar 26 18:05:56 2010 From: ggiesen at akn.ca (Gary T. Giesen) Date: Fri, 26 Mar 2010 18:05:56 -0400 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <4BAD2D10.4060107@matthew.at> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> Message-ID: <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> If that's a concern, then get GUA space out of the gate and you'll never renumber again. I believe GUA should be made cheap and relatively easy to get (instead of something using something like ULA and NATing it). While some will argue this will lead to an explosion in the v6 routing table (and there is definitely merit to their argument), the aggregation gains from people who don't need the capability (especially residential customers) should more than offset it in the near term, buying time for for the technology to progress and offer us more TCAM slots to deal with it in the longer term. GG On Fri, 2010-03-26 at 17:54 -0400, Matthew Kaufman wrote: > Gary T. Giesen wrote: > > IMHO it's better to get people used to having no NAT at all (since > > they're getting used to a new protocol anyways)... > Please explain how you intend to eliminate manual renumbering for > corporate internal networks every time they change ISPs. > > (And note that RA and even DHCP6 don't fix all the manual setup of > things like "what is the address of the intranet web server".) > > There is a real cost to this, and the cost of a NAT device is pretty > much paid off the first or second time you're forced to renumber. > > Matthew Kaufman From bill at herrin.us Fri Mar 26 18:08:39 2010 From: bill at herrin.us (William Herrin) Date: Fri, 26 Mar 2010 18:08:39 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <6F204832-483E-494A-BF8D-7B656672C3DA@delong.com> References: <28E139F46D45AF49A31950F88C4974580599EA8F@E03MVZ2-UKDY.domain1.systemhost.net> <4BACAF24.7060508@umn.edu> <4BACC73C.2030009@umn.edu> <3c3e3fca1003260752s24c542dm3cae37050eb0efe4@mail.gmail.com> <4BAD280D.1010706@umn.edu> <6F204832-483E-494A-BF8D-7B656672C3DA@delong.com> Message-ID: <3c3e3fca1003261508u5cf547d8me6042e34a6f2a068@mail.gmail.com> On Fri, Mar 26, 2010 at 6:00 PM, Owen DeLong wrote: > I'm in favor of assigning large blocks of ULA-C to RIRs and >having them manage it identically to GUA where the choice >of GUA or ULA-C becomes a checkbox on the IP >application form and nothing else. Would you settle for assigning large blocks of ULA-C to RIRs and having the RIRs manage it according to whatever policies their constituents find consensus on? -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ggiesen at akn.ca Fri Mar 26 18:23:05 2010 From: ggiesen at akn.ca (Gary T. Giesen) Date: Fri, 26 Mar 2010 18:23:05 -0400 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> Message-ID: <1269642185.5400.460.camel@ggiesen-workstation.netsurf.net> Just a clarification on my comments, that's PI GUA space... Few organizations will need more than a single /48, which would at least contain the number of prefixes being advertised. And with most ISP's (LIR's) only requiring a single prefix for their own PA space, we should a nice reset in table size, allowing hardware to catch up with routing table growth. GG On Fri, 2010-03-26 at 18:05 -0400, Gary T. Giesen wrote: > If that's a concern, then get GUA space out of the gate and you'll never > renumber again. I believe GUA should be made cheap and relatively easy > to get (instead of something using something like ULA and NATing it). > > While some will argue this will lead to an explosion in the v6 routing > table (and there is definitely merit to their argument), the aggregation > gains from people who don't need the capability (especially residential > customers) should more than offset it in the near term, buying time for > for the technology to progress and offer us more TCAM slots to deal with > it in the longer term. > > GG > > On Fri, 2010-03-26 at 17:54 -0400, Matthew Kaufman wrote: > > Gary T. Giesen wrote: > > > IMHO it's better to get people used to having no NAT at all (since > > > they're getting used to a new protocol anyways)... > > Please explain how you intend to eliminate manual renumbering for > > corporate internal networks every time they change ISPs. > > > > (And note that RA and even DHCP6 don't fix all the manual setup of > > things like "what is the address of the intranet web server".) > > > > There is a real cost to this, and the cost of a NAT device is pretty > > much paid off the first or second time you're forced to renumber. > > > > Matthew Kaufman > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Fri Mar 26 18:22:50 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 15:22:50 -0700 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <4BAD2D10.4060107@matthew.at> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> Message-ID: <5A098D43-4F93-4F7A-87BB-157877C0F062@delong.com> On Mar 26, 2010, at 2:54 PM, Matthew Kaufman wrote: > Gary T. Giesen wrote: >> IMHO it's better to get people used to having no NAT at all (since >> they're getting used to a new protocol anyways)... > Please explain how you intend to eliminate manual renumbering for corporate internal networks every time they change ISPs. > Provider independent prefixes that they can take with them? Owen From owen at delong.com Fri Mar 26 18:32:03 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 15:32:03 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <3c3e3fca1003261508u5cf547d8me6042e34a6f2a068@mail.gmail.com> References: <28E139F46D45AF49A31950F88C4974580599EA8F@E03MVZ2-UKDY.domain1.systemhost.net> <4BACAF24.7060508@umn.edu> <4BACC73C.2030009@umn.edu> <3c3e3fca1003260752s24c542dm3cae37050eb0efe4@mail.gmail.com> <4BAD280D.1010706@umn.edu> <6F204832-483E-494A-BF8D-7B656672C3DA@delong.com> <3c3e3fca1003261508u5cf547d8me6042e34a6f2a068@mail.gmail.com> Message-ID: On Mar 26, 2010, at 3:08 PM, William Herrin wrote: > On Fri, Mar 26, 2010 at 6:00 PM, Owen DeLong wrote: >> I'm in favor of assigning large blocks of ULA-C to RIRs and >> having them manage it identically to GUA where the choice >> of GUA or ULA-C becomes a checkbox on the IP >> application form and nothing else. > > Would you settle for assigning large blocks of ULA-C to RIRs and > having the RIRs manage it according to whatever policies their > constituents find consensus on? > Yes, but, I will push for that consensus to be such that ULA-C mis-use as GUA does not become financially or otherwise attractive, which, I consider to be a major source of potential harm if it is allowed. Owen From matthew at matthew.at Fri Mar 26 19:00:44 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 26 Mar 2010 16:00:44 -0700 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> Message-ID: <4BAD3C9C.80807@matthew.at> Gary T. Giesen wrote: > If that's a concern, then get GUA space out of the gate and you'll never > renumber again. I believe GUA should be made cheap and relatively easy > to get (instead of something using something like ULA and NATing it). > Right, and so this argues for ARIN to make it easy *and cheap* for a newly-formed single-homed company with a half-dozen employees and a few servers to get globally-unique *and* routable IPv6 address space. Matthew Kaufman From ggiesen at akn.ca Fri Mar 26 19:18:17 2010 From: ggiesen at akn.ca (Gary T. Giesen) Date: Fri, 26 Mar 2010 19:18:17 -0400 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <4BAD3C9C.80807@matthew.at> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> <4BAD3C9C.80807@matthew.at> Message-ID: <1269645497.5400.533.camel@ggiesen-workstation.netsurf.net> There have to be controls. Obviously the burden to renumber a few servers and half a dozen workstations is far less than an organization with 5,000 servers and 50,000 employees, so the bar has to be set somewhere. I'm just saying it should be set lower than it currently is. But chances are a company of that size won't know the difference anyways and will accept whatever their provider hands them. I'm not saying that developing the appropriate policy will be easy, but given the alternative (NAT), I vote to try. Not only that, my suggestion requires the development of exactly *zero* new protocols/implementations. This gives time for vendors to catch up without worrying about trying to hit a moving target. We've got the protocol now, and the mechanisms we need to deploy it. Let's not further delay adoption because we're clinging onto a bastardized hack which was designed only to prolong the life of the old protocol and is completely unnecessary in the new one. Obviously you've never been on the other end of a call of a customer who has (mis)configured policy-NAT on their SMB gateway which shoots packets sourced from different IPs based on the the port and what day of the month it is. IPv6 was actually designed to be simpler than v4. Let's not change that. On Fri, 2010-03-26 at 19:00 -0400, Matthew Kaufman wrote: > Gary T. Giesen wrote: > > If that's a concern, then get GUA space out of the gate and you'll never > > renumber again. I believe GUA should be made cheap and relatively easy > > to get (instead of something using something like ULA and NATing it). > > > > Right, and so this argues for ARIN to make it easy *and cheap* for a > newly-formed single-homed company with a half-dozen employees and a few > servers to get globally-unique *and* routable IPv6 address space. > > Matthew Kaufman From farmer at umn.edu Fri Mar 26 19:30:19 2010 From: farmer at umn.edu (David Farmer) Date: Fri, 26 Mar 2010 18:30:19 -0500 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <4BAD3C9C.80807@matthew.at> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> <4BAD3C9C.80807@matthew.at> Message-ID: <4BAD438B.9090106@umn.edu> Matthew Kaufman wrote: > Gary T. Giesen wrote: >> If that's a concern, then get GUA space out of the gate and you'll never >> renumber again. I believe GUA should be made cheap and relatively easy >> to get (instead of something using something like ULA and NATing it). > > Right, and so this argues for ARIN to make it easy *and cheap* for a > newly-formed single-homed company with a half-dozen employees and a few > servers to get globally-unique *and* routable IPv6 address space. ARIN doesn't set routing policy, get over it, just because ARIN gives out an address doesn't mean it will get a routing slot. And if that 6 person company, is generating $6M in revenue it can afford to buy its routing slot. If it is generating $6K, probably not. Why should ARIN be that judge? -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From matthew at matthew.at Fri Mar 26 19:32:42 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 26 Mar 2010 16:32:42 -0700 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <1269645497.5400.533.camel@ggiesen-workstation.netsurf.net> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> <4BAD3C9C.80807@matthew.at> <1269645497.5400.533.camel@ggiesen-workstation.netsurf.net> Message-ID: <4BAD441A.6010808@matthew.at> Gary T. Giesen wrote: > There have to be controls. Obviously the burden to renumber a few > servers and half a dozen workstations is far less than an organization > with 5,000 servers and 50,000 employees, so the bar has to be set > somewhere. I'm just saying it should be set lower than it currently is. > Much lower. All companies with 5000 servers and 50000 employees started out as a few employees in a small office somewhere. And most startups with a few employees in a small office hope to grow into an organization with 5000 servers and 50000 employees... ...and if one of those half-dozen people has ever been through the renumbering pain, they will insist, and rightly so, on ensuring that either through globally-unique routable address space or NAT that their new employer never must suffer through the same pain. > But chances are a company of that size won't know the difference anyways > and will accept whatever their provider hands them. > The moment they have someone on staff who knows the pain of renumbering and knows that the bigger you get, the harder it is, they'll switch to NAT or GUA. One of the two. > I'm not saying that developing the appropriate policy will be easy, but > given the alternative (NAT), I vote to try. Not only that, my suggestion > requires the development of exactly *zero* new > protocols/implementations. This gives time for vendors to catch up > without worrying about trying to hit a moving target. We've got the > protocol now, and the mechanisms we need to deploy it. Let's not further > delay adoption because we're clinging onto a bastardized hack which was > designed only to prolong the life of the old protocol and is completely > unnecessary in the new one. > But that's the thing. It *isn't* "completely unnecessary in the new one" and *that very belief* is why we don't have such devices already on sale. I've pointed out two reasons already (masking MAC addresses from hosts that put them in the bottom 64 bits, and ensuring that users of PA space don't need to renumber), and I'll add one more: compliance with the checklist-style audits which have "internal topolgy is hidden from outside" as a checklist item for the Sarbanes-Oxley, HIPPA, and related law-driven auditing. > Obviously you've never been on the other end of a call of a customer who > has (mis)configured policy-NAT on their SMB gateway which shoots packets > sourced from different IPs based on the the port and what day of the > month it is. IPv6 was actually designed to be simpler than v4. Let's not > change that. > I've designed, built, and supported ISPs off and on since 1993. The IPv6 community continues to be filled with people who insist on not meeting the reasonable demands of customers, and who are then surprised when adoption rates are low. Matthew Kaufman From matthew at matthew.at Fri Mar 26 19:34:27 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 26 Mar 2010 16:34:27 -0700 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <4BAD438B.9090106@umn.edu> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> <4BAD3C9C.80807@matthew.at> <4BAD438B.9090106@umn.edu> Message-ID: <4BAD4483.3020309@matthew.at> David Farmer wrote: > Matthew Kaufman wrote: >> Gary T. Giesen wrote: >>> If that's a concern, then get GUA space out of the gate and you'll >>> never >>> renumber again. I believe GUA should be made cheap and relatively easy >>> to get (instead of something using something like ULA and NATing it). >> >> Right, and so this argues for ARIN to make it easy *and cheap* for a >> newly-formed single-homed company with a half-dozen employees and a >> few servers to get globally-unique *and* routable IPv6 address space. > > ARIN doesn't set routing policy, get over it, just because ARIN gives > out an address doesn't mean it will get a routing slot. And if that 6 > person company, is generating $6M in revenue it can afford to buy its > routing slot. If it is generating $6K, probably not. Why should ARIN > be that judge? > It shouldn't be, and we wouldn't be having this conversation if "easy *and cheap*" NAT66 existed. I've now pointed out 3 reasons why it should, and once that happens the demand for cheap PI GUA space will be a non-issue. Matthew Kaufman From farmer at umn.edu Fri Mar 26 19:46:27 2010 From: farmer at umn.edu (David Farmer) Date: Fri, 26 Mar 2010 18:46:27 -0500 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <4BAD2F45.7050906@matthew.at> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <4BAD2E96.7080504@gmail.com> <4BAD2F45.7050906@matthew.at> Message-ID: <4BAD4753.9070602@umn.edu> Matthew Kaufman wrote: > Scott Leibrand wrote: >> On Fri 3/26/2010 2:54 PM, Matthew Kaufman wrote: >>> Please explain how you intend to eliminate manual renumbering for >>> corporate internal networks every time they change ISPs. >>> >>> (And note that RA and even DHCP6 don't fix all the manual setup of >>> things like "what is the address of the intranet web server".) >>> >>> There is a real cost to this, and the cost of a NAT device is pretty >>> much paid off the first or second time you're forced to renumber. >>> >>> Matthew Kaufman >> >> Matthew, >> >> So it sounds like you're describing something like private IPv6 >> addresses on the inside, NAT66 at the edge, doing 1:1 mapping of the >> inside private IPv6 prefix to the currently-active outside public IPv6 >> prefix? >> >> Does that accurately describe this use case? >> >> Thanks, >> Scott > That should be sufficient, yes. And of course I'd want my private IPv6 > to come from a range I was sure nobody I ever acquired or was acquired > by was using. > > Address overloading is probably not necessary. > > A nice side effect is that I can have my NAT tweak the bottom 64 bits in > case my hosts insist on exposing details of their MAC address there > (which I consider to be a security problem). > > Matthew Kaufman While I would rather just have GUA-PI on all of my hosts and do stateful firewall if I feel the need, I'm not opposed to this at all. Also, if you stay with 1:1 NAT, you could do the NAT with a stateless process. Many people will still want a stateful firewall, but having the option is useful. And you could NAT and firewall in separate places, Like NAT at your Internet Border and stateful firewall closer in, maybe even at the subnet level. It would also be useful if NAT66 was designed with a way to inform the inside host of the NAT translation, this way it could be do in a way more friendly to the applications. So if a network operator want to use NAT66, it is not from us(ARIN) to them NO. And, I believe the network operator should have the choice of GUA-PI, ULA-C, or ULA-L. I believe ARIN Policy should leave it up to the network operator to chose. I could see any of the following, as reasonable way to use NAT66. And, I'm not sure why policy shouldn't allow any of these, if that is what a network operator wants to do. Outside-to-Inside: GUA-PA NAT66 GUA-PI GUA-PA NAT66 ULA-C GUA-PA NAT66 ULA-L GUA-PI NAT66 ULA-C GUA-PI NAT66 ULA-L However, do believe that GUA-PI NAT66 GUA-PI, as a single entity, by requesting two separate GUA-PI blocks would be a policy violation. So unless GUA-PI NAT66 GUA-PI was being done between two separate entities this is probably a policy violation. And, I'm not sure why you wouldn't just route and have stateful firewall if needed. Again ULA-C NAT66 ULA-C is probably policy violation and just silly similar to GUA-PI NAT66 GUA-PI. ULA-L NAT66 ULA-L wouldn't be a policy violation, but in most cases it would be silly. Unless, you were unlucky and merged with someone using the same ULA-L prefix as you. Anyone doing GUA-PA NAT66 GUA-PA should just be put in front of a firing squad, that is beyond silly. But, I'm sure it is going to happen. So, while I would rather live in a universe without NAT66, in reality we will need it. I think NAT66 is mostly outside of PPML, the important part for PPML is we should provide an addressing solution that enables those that want to operate their network in this way to do it. How we got to the Internet we have today, creating both the good and bad, is we let multiple solutions flourish. Solutions were allowed to live and die on on there own, with as little dictates from any central authority as possible. It generally has worked. We can argue all we want about which solution is better, but unless a something about a particular solution will endanger the whole, then it should be given the chance to flourish. So lets find a way to make ULA-C work, I think we are getting close. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From ggiesen at akn.ca Fri Mar 26 20:16:25 2010 From: ggiesen at akn.ca (Gary Giesen) Date: Fri, 26 Mar 2010 20:16:25 -0400 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <4BAD4753.9070602@umn.edu> Message-ID: On 10-03-26 7:46 PM, "David Farmer" wrote: > Matthew Kaufman wrote: >> Scott Leibrand wrote: >>> On Fri 3/26/2010 2:54 PM, Matthew Kaufman wrote: >>>> Please explain how you intend to eliminate manual renumbering for >>>> corporate internal networks every time they change ISPs. >>>> >>>> (And note that RA and even DHCP6 don't fix all the manual setup of >>>> things like "what is the address of the intranet web server".) >>>> >>>> There is a real cost to this, and the cost of a NAT device is pretty >>>> much paid off the first or second time you're forced to renumber. >>>> >>>> Matthew Kaufman >>> >>> Matthew, >>> >>> So it sounds like you're describing something like private IPv6 >>> addresses on the inside, NAT66 at the edge, doing 1:1 mapping of the >>> inside private IPv6 prefix to the currently-active outside public IPv6 >>> prefix? >>> >>> Does that accurately describe this use case? >>> >>> Thanks, >>> Scott >> That should be sufficient, yes. And of course I'd want my private IPv6 >> to come from a range I was sure nobody I ever acquired or was acquired >> by was using. >> >> Address overloading is probably not necessary. >> >> A nice side effect is that I can have my NAT tweak the bottom 64 bits in >> case my hosts insist on exposing details of their MAC address there >> (which I consider to be a security problem). >> >> Matthew Kaufman > > While I would rather just have GUA-PI on all of my hosts and do stateful > firewall if I feel the need, I'm not opposed to this at all. > > Also, if you stay with 1:1 NAT, you could do the NAT with a stateless > process. Many people will still want a stateful firewall, but having > the option is useful. And you could NAT and firewall in separate > places, Like NAT at your Internet Border and stateful firewall closer > in, maybe even at the subnet level. That's a slippery slope. Once you have NAT at all, do you think 1:many will be far behind? Besides, Matthew's already arguing for PAT/NAT overloading, as well. > > It would also be useful if NAT66 was designed with a way to inform the > inside host of the NAT translation, this way it could be do in a way > more friendly to the applications. > > So if a network operator want to use NAT66, it is not from us(ARIN) to > them NO. And, I believe the network operator should have the choice of > GUA-PI, ULA-C, or ULA-L. I believe ARIN Policy should leave it up to > the network operator to chose. > > I could see any of the following, as reasonable way to use NAT66. And, > I'm not sure why policy shouldn't allow any of these, if that is what a > network operator wants to do. > > Outside-to-Inside: > GUA-PA NAT66 GUA-PI > GUA-PA NAT66 ULA-C > GUA-PA NAT66 ULA-L > GUA-PI NAT66 ULA-C > GUA-PI NAT66 ULA-L > With accessible PI space, all of which becomes unnecessary > However, do believe that GUA-PI NAT66 GUA-PI, as a single entity, by > requesting two separate GUA-PI blocks would be a policy violation. So > unless GUA-PI NAT66 GUA-PI was being done between two separate entities > this is probably a policy violation. And, I'm not sure why you wouldn't > just route and have stateful firewall if needed. > > Again ULA-C NAT66 ULA-C is probably policy violation and just silly > similar to GUA-PI NAT66 GUA-PI. > > ULA-L NAT66 ULA-L wouldn't be a policy violation, but in most cases it > would be silly. Unless, you were unlucky and merged with someone using > the same ULA-L prefix as you. > > Anyone doing GUA-PA NAT66 GUA-PA should just be put in front of a firing > squad, that is beyond silly. But, I'm sure it is going to happen. > > So, while I would rather live in a universe without NAT66, in reality we > will need it. > > I think NAT66 is mostly outside of PPML, the important part for PPML is > we should provide an addressing solution that enables those that want to > operate their network in this way to do it. Yes, but PPML can in effect be the gatekeepers of the tools to do it. > > How we got to the Internet we have today, creating both the good and > bad, is we let multiple solutions flourish. Solutions were allowed to > live and die on on there own, with as little dictates from any central > authority as possible. It generally has worked. > I completely agree with this, and this is mostly because there is very little that *can* be dictated on the Internet. But it's also our job to agree on public policy for the *good* of the Internet. I think many NAT proponents vastly underestimated the economic cost of NAT, and as Owen has pointed out many times before, they are seldom borne by the person implementing it. Routing slots are expensive, but are several orders of magnitude below the costs of implementing, supporting, and working around NAT > We can argue all we want about which solution is better, but unless a > something about a particular solution will endanger the whole, then it > should be given the chance to flourish. > > So lets find a way to make ULA-C work, I think we are getting close. GG From owen at delong.com Fri Mar 26 20:15:20 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 17:15:20 -0700 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <4BAD3C9C.80807@matthew.at> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> <4BAD3C9C.80807@matthew.at> Message-ID: <9E2AB257-12FE-4DAE-A4FF-ABFC1DE1A159@delong.com> On Mar 26, 2010, at 4:00 PM, Matthew Kaufman wrote: > Gary T. Giesen wrote: >> If that's a concern, then get GUA space out of the gate and you'll never >> renumber again. I believe GUA should be made cheap and relatively easy >> to get (instead of something using something like ULA and NATing it). > > Right, and so this argues for ARIN to make it easy *and cheap* for a newly-formed single-homed company with a half-dozen employees and a few servers to get globally-unique *and* routable IPv6 address space. > Agreed, but, by some definitions of the terms, it already is cheap. $100/year really isn't that expensive for however much IPv6 address space you need. Yes, I would like to see the $1250 up-front fee lowered. I have advocated for that for some time now. Still, even for a half-dozen employees and a few servers, as a one-time startup cost, that's not one of the big ones. I'm all for ARIN having policy that makes it easy for you to get a /48 at that level, but, I doubt very many ISPs would want to accept your prefix into their routing table at that level until we have deprecated IPv4 to the point of meaningful table size reduction. That's not an ARIN policy issue, however, just a reality you may still need to face even if we get the ARIN policy issues resolved in this area. Owen From owen at delong.com Fri Mar 26 20:22:54 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 17:22:54 -0700 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <1269645497.5400.533.camel@ggiesen-workstation.netsurf.net> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> <4BAD3C9C.80807@matthew.at> <1269645497.5400.533.camel@ggiesen-workstation.netsurf.net> Message-ID: On Mar 26, 2010, at 4:18 PM, Gary T. Giesen wrote: > There have to be controls. Obviously the burden to renumber a few > servers and half a dozen workstations is far less than an organization > with 5,000 servers and 50,000 employees, so the bar has to be set > somewhere. I'm just saying it should be set lower than it currently is. > I'm saying it should be set by ISPs and not by ARIN. If you don't want to carry such a route on your routers, don't. It shouldn't make any difference at the ARIN level whether a route will or will not be used for internet connectivity or some subset thereof. > But chances are a company of that size won't know the difference anyways > and will accept whatever their provider hands them. > Especially if they can't find a provider that can get their prefix accepted by all the other provider. > I'm not saying that developing the appropriate policy will be easy, but > given the alternative (NAT), I vote to try. Not only that, my suggestion > requires the development of exactly *zero* new > protocols/implementations. This gives time for vendors to catch up > without worrying about trying to hit a moving target. We've got the > protocol now, and the mechanisms we need to deploy it. Let's not further > delay adoption because we're clinging onto a bastardized hack which was > designed only to prolong the life of the old protocol and is completely > unnecessary in the new one. > Here Here!! > Obviously you've never been on the other end of a call of a customer who > has (mis)configured policy-NAT on their SMB gateway which shoots packets > sourced from different IPs based on the the port and what day of the > month it is. IPv6 was actually designed to be simpler than v4. Let's not > change that. > ROFL -- Agreed. Owen > On Fri, 2010-03-26 at 19:00 -0400, Matthew Kaufman wrote: >> Gary T. Giesen wrote: >>> If that's a concern, then get GUA space out of the gate and you'll never >>> renumber again. I believe GUA should be made cheap and relatively easy >>> to get (instead of something using something like ULA and NATing it). >>> >> >> Right, and so this argues for ARIN to make it easy *and cheap* for a >> newly-formed single-homed company with a half-dozen employees and a few >> servers to get globally-unique *and* routable IPv6 address space. >> >> Matthew Kaufman > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Fri Mar 26 20:30:22 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 17:30:22 -0700 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <4BAD441A.6010808@matthew.at> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> <4BAD3C9C.80807@matthew.at> <1269645497.5400.533.camel@ggiesen-workstation.netsurf.net> <4BAD441A.6010808@matthew.at> Message-ID: <76C4D871-191A-4C76-AEB4-96E637C88076@delong.com> On Mar 26, 2010, at 4:32 PM, Matthew Kaufman wrote: > Gary T. Giesen wrote: >> There have to be controls. Obviously the burden to renumber a few >> servers and half a dozen workstations is far less than an organization >> with 5,000 servers and 50,000 employees, so the bar has to be set >> somewhere. I'm just saying it should be set lower than it currently is. >> > Much lower. > > All companies with 5000 servers and 50000 employees started out as a few employees in a small office somewhere. And most startups with a few employees in a small office hope to grow into an organization with 5000 servers and 50000 employees... > > ...and if one of those half-dozen people has ever been through the renumbering pain, they will insist, and rightly so, on ensuring that either through globally-unique routable address space or NAT that their new employer never must suffer through the same pain. > >> But chances are a company of that size won't know the difference anyways >> and will accept whatever their provider hands them. >> > The moment they have someone on staff who knows the pain of renumbering and knows that the bigger you get, the harder it is, they'll switch to NAT or GUA. One of the two. I agree with almost everything you have said above. >> I'm not saying that developing the appropriate policy will be easy, but >> given the alternative (NAT), I vote to try. Not only that, my suggestion >> requires the development of exactly *zero* new >> protocols/implementations. This gives time for vendors to catch up >> without worrying about trying to hit a moving target. We've got the >> protocol now, and the mechanisms we need to deploy it. Let's not further >> delay adoption because we're clinging onto a bastardized hack which was >> designed only to prolong the life of the old protocol and is completely >> unnecessary in the new one. >> > But that's the thing. It *isn't* "completely unnecessary in the new one" and *that very belief* is why we don't have such devices already on sale. I've pointed out two reasons already (masking MAC addresses from hosts that put them in the bottom 64 bits, and ensuring that users of PA space don't need to renumber), and I'll add one more: compliance with the checklist-style audits which have "internal topolgy is hidden from outside" as a checklist item for the Sarbanes-Oxley, HIPPA, and related law-driven auditing. Here you run off the rails. If we fix policy for GUA, then, it _IS_ completely unnecessary in the new one. There are many other tools to prevent hosts from using their Mac address. You can, for example, simply run without SLAAC... No RAs, No SLAAC addresses with embedded mac addresses. The checklist audits need to be revised just as policy needs to be revised. Hopefully we can get both done relatively soon. >> Obviously you've never been on the other end of a call of a customer who >> has (mis)configured policy-NAT on their SMB gateway which shoots packets >> sourced from different IPs based on the the port and what day of the >> month it is. IPv6 was actually designed to be simpler than v4. Let's not >> change that. >> > I've designed, built, and supported ISPs off and on since 1993. The IPv6 community continues to be filled with people who insist on not meeting the reasonable demands of customers, and who are then surprised when adoption rates are low. > So have I. I would consider myself much more entrenched in the ISP community than the IPv6 community. However, as an ISP, I also recognize that running out of IPv4 addresses is inevitable and that NAT has caused many more problems than it actually solves. I recognize that most of the "solutions" attributed to NAT outside of address conservation are either artful fiction, or, a place where NAT is a very tiny add-on piece to a much larger actual solution (e.g. the alleged security benefits of NAT combined with Stateful Inspection). Owen From owen at delong.com Fri Mar 26 20:39:22 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 17:39:22 -0700 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <4BAD4483.3020309@matthew.at> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> <4BAD3C9C.80807@matthew.at> <4BAD438B.9090106@umn.edu> <4BAD4483.3020309@matthew.at> Message-ID: <1328EE4D-AC0E-4340-82FB-65DDC89589DF@delong.com> On Mar 26, 2010, at 4:34 PM, Matthew Kaufman wrote: > David Farmer wrote: >> Matthew Kaufman wrote: >>> Gary T. Giesen wrote: >>>> If that's a concern, then get GUA space out of the gate and you'll never >>>> renumber again. I believe GUA should be made cheap and relatively easy >>>> to get (instead of something using something like ULA and NATing it). >>> >>> Right, and so this argues for ARIN to make it easy *and cheap* for a newly-formed single-homed company with a half-dozen employees and a few servers to get globally-unique *and* routable IPv6 address space. >> >> ARIN doesn't set routing policy, get over it, just because ARIN gives out an address doesn't mean it will get a routing slot. And if that 6 person company, is generating $6M in revenue it can afford to buy its routing slot. If it is generating $6K, probably not. Why should ARIN be that judge? >> > It shouldn't be, and we wouldn't be having this conversation if "easy *and cheap*" NAT66 existed. I've now pointed out 3 reasons why it should, and once that happens the demand for cheap PI GUA space will be a non-issue. How about we make easy and cheap PI GUA available and make NAT66 a non-issue instead. Owen From spiffnolee at yahoo.com Sat Mar 27 17:03:44 2010 From: spiffnolee at yahoo.com (Lee Howard) Date: Sat, 27 Mar 2010 14:03:44 -0700 (PDT) Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <4BAD4483.3020309@matthew.at> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> <4BAD3C9C.80807@matthew.at> <4BAD438B.9090106@umn.edu> <4BAD4483.3020309@matthew.at> Message-ID: <895344.90218.qm@web63301.mail.re1.yahoo.com> > > From: David Farmer > > ARIN doesn't > > set routing policy, get over it, just because ARIN gives out an address doesn't > > mean it will get a routing slot. And if that 6 person company, is > > generating $6M in revenue it can afford to buy its routing slot. If it is > > generating $6K, probably not. Why should ARIN be that judge? Not that ARIN should be a routing arbiter, but we probably shouldn't make policy that we believe will cause disconnectivity. > From: Matthew Kaufman > It shouldn't be, and we wouldn't be having this conversation if "easy *and > cheap*" NAT66 existed. I've now pointed out 3 reasons why it should, and once > that happens the demand for cheap PI GUA space will be a > non-issue. ARIN can't create NAT66. The BEHAVE working group at IETF could do. Lee From frnkblk at iname.com Sat Mar 27 17:40:39 2010 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 27 Mar 2010 16:40:39 -0500 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <20100326205555.D66402B2126@mx5.roble.com> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> Message-ID: As others have said, and having worked at and managed an ISP help desk, I can tell you that 95% of consumers don't know what NAT is, and don't care. And 90% probably don't know what an IP address is. If we gave them IPv20 and it allowed them to get online to check facebook and check the latest game score they would be happy. They won't have any issue giving up IPv4 NAT because most of them never knew what it was. Of course, we're likely to see IPv4 NAT in place for many years to come because IPv4 address depletion != no IPv4 content. Not once while thinking about IPv6 have I given any extended consideration to educating my end customers about IPv4 address depletion and this "new" thing called IPv6. The key customer impact I'm thinking about is how I can help make their PC IPv6 ready (thanks, Microsoft, for turning it on by default in Windows Vista and 7!) and how I communicate to them that we need to change out their DSL/Wi-Fi/wireline-only router or router-integrated cable modem and apologize for the inconvenience. It might very well happen in a few years time that our residential customers demand that we compensate them for having to purchase a new router so that they can access IPv6-only-acme.com from their PC! PAT was a stopgap measure with many short-comings. If we can swap out their CPE with IPv6-capable stateful firewall/routers, we do ourselves a world of favor. I will then be able to tell the customer which PC in their home is infected with malware, sending out spam, or offer a more granular internet filtering service. What security issues are created back the lack of NAT? If you're thinking of CPE moving to a pure router, I believe the broad consensus in this community is that we need stateful firewalls that default to closed. An IETF IPv6 WGs is working on fleshing that out now. I'm not sure how you can assess that IPv6 has received a "thumbs-down" from consumers -- I've not run across such a study or report. If anything, service providers are frustrated by the lack of consumer-oriented CPE that support IPv6. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Roger Marquis Sent: Friday, March 26, 2010 3:56 PM To: William Herrin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 Non-connected networks >> I believe that it means exactly what I intended per the definition below. >> ?admit (an event or activity) as legal or acceptable >> fail to prevent (something) from happening > > Why then I apologize, because I thought you meant to convey that NAT > should be *required* to become obsolete with IPv4, perhaps by > obstructing folks' choice to use it in IPv6. Surely Roger only meant > to offer his opinion that given a choice, few network security > professionals would choose to abandon the use NAT. It isn't just network security professionals who won't give up NAT, end-user consumers also won't. If anything is clear from the past few year's field trials it's that IPv6 has received a vote of no confidence from consumers. It has received that thumbs down primarily because it lacks address translation. IMO there's no painless way to transition to IPv6 without NAT. Compound that with the security issues created by the lack of NAT and, well, you have where we are today. Roger From bill at herrin.us Sat Mar 27 18:23:50 2010 From: bill at herrin.us (William Herrin) Date: Sat, 27 Mar 2010 18:23:50 -0400 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <895344.90218.qm@web63301.mail.re1.yahoo.com> References: <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> <4BAD3C9C.80807@matthew.at> <4BAD438B.9090106@umn.edu> <4BAD4483.3020309@matthew.at> <895344.90218.qm@web63301.mail.re1.yahoo.com> Message-ID: <3c3e3fca1003271523h7068a0cfm132a4b547457a06f@mail.gmail.com> On Sat, Mar 27, 2010 at 5:03 PM, Lee Howard wrote: >> From: Matthew Kaufman >> It shouldn't be, and we wouldn't be having this conversation if "easy *and >> cheap*" NAT66 existed. I've now pointed out 3 reasons why it should, and once >> that happens the demand for cheap PI GUA space will be a >> non-issue. > > ARIN can't create NAT66. ?The BEHAVE working group at IETF could do. True, but ARIN can make some of the number resources that facilitate NAT66 easier or harder to come by. Hence the debate. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From michael.dillon at bt.com Mon Mar 29 03:30:42 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 29 Mar 2010 08:30:42 +0100 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> Message-ID: <28E139F46D45AF49A31950F88C49745805A13910@E03MVZ2-UKDY.domain1.systemhost.net> > If that's a concern, then get GUA space out of the gate and > you'll never renumber again. I believe GUA should be made > cheap and relatively easy to get (instead of something using > something like ULA and NATing it). Global Unicast Addresses have been available for years now. ARIN, and the other RIRs have been allocating from 2000::3 (Global Unicast Address) and the process has been made easier every year. > While some will argue this will lead to an explosion in the > v6 routing table (and there is definitely merit to their > argument) That's why ULA-C was thought up. Because blocks are randomly allocated, they cannot be aggregated at all, but because they aren't intended for Internet use, it is easy to simply filter the whole range like any other bogon range. --Michael Dillon From farmer at umn.edu Mon Mar 29 09:35:33 2010 From: farmer at umn.edu (David Farmer) Date: Mon, 29 Mar 2010 08:35:33 -0500 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <895344.90218.qm@web63301.mail.re1.yahoo.com> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> <4BAD3C9C.80807@matthew.at> <4BAD438B.9090106@umn.edu> <4BAD4483.3020309@matthew.at> <895344.90218.qm@web63301.mail.re1.yahoo.com> Message-ID: <4BB0ACA5.3050500@umn.edu> Lee Howard wrote: > >>> From: David Farmer >>> ARIN doesn't >>> set routing policy, get over it, just because ARIN gives out an address doesn't >>> mean it will get a routing slot. And if that 6 person company, is >>> generating $6M in revenue it can afford to buy its routing slot. If it is >>> generating $6K, probably not. Why should ARIN be that judge? > > Not that ARIN should be a routing arbiter, but we probably shouldn't make > policy that we believe will cause disconnectivity. The desire for disconnected addressing is precisely what started this conversation. Or at least the desire for guaranteed unique addressing free form the politics of routing table slots. There are many uses for addresses that it is perfectly fine that no one will ever accept the associated route. But, you still may want them to be globally unique and to have reverse DNS. So at least in the case on ULA-C type addresses, I have to completely disagree with your statement. There is a segment of the community that needs ARIN to provide addresses without regard to routability or connectivity. Given the need to disregard for routability or connectivity for ULA-C, there is an argument that they need to be disregarded for GUA-PI too. Otherwise ULA-C will likely be abused, and used in place of GUA-PI. Up to this point, that has been used as an excuse to not do ULA-C. I would like to agree with your statement for GUA-PI, but I think getting ULA-C and GUA-PI into users hands is more important, and necessary for the adoption of IPv6, than our wish to maintain connectivity for GUA-PI by default. Besides there are already providers not accepting GUA-PI and therefore creating disconnectivity at this time. So, should we roll back the current GUA-PI policy because of that? Should we demand that those providers accept GUA-PI? Or, should we let the marketplace figure that out? -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From cengel at sponsordirect.com Mon Mar 29 10:39:18 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Mon, 29 Mar 2010 10:39:18 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: Message-ID: Owen DeLong wrote: > You are assuming a lot more about human behavior by less > qualified individuals than is required in my assertion that > people should properly configure their firewalls. If I have > to tolerate NAT and it's damage because you can't reliably > avoid mistakes that fail open on your firewalls, then, you > need to allow for a way to reimburse my costs that come from > your even less qualified end users that also happen to be my > customers. Owen, Who am I to tell you how to bill your customers? If you want to bill some sort of "NAT surcharge" into your fees or (a probably more reasonable way to recoup costs) charge support by the minute/hour then go for it if your business model supports it. I certainly don't tell you how to bill. However, I don't see how that situation is any different then supporting a customer who isn't technicaly profficient ("um... what's my IP address? A command prompt...what is that?") or speaks slowly, or maybe has a language barrier...or maybe has something else going on thier network that interferes with your equipment.... all of which would cause you more time/effort in support then you would ordinarly need to (I've done plenty of support calls in my day). Should none of those people be allowed use of the internet because they would cost more support time then others? Furthermore, I would think the answer to your situation would be rather straightforward. If you are the designer of the equipment/software that you are working with... why wouldn't you design in a special diagnostic mode on your phone that sent out a unique number/code for the particular phone issued to that customer inside each packet sent....and then build a tool that could work with a packet sniffer to examine the packets you were recieving to see if any of them corresponded to that phone? That should tell you definitively whether you were getting any of those packets regardless of what was happening with the packet headers (and presumably even independant of whatever protocol they might be running under). Turning the arguement around on you... why should NAT be disallowed on the entire internet simply because you can't be bothered to build in more robust diagnostic tools on the equipment that you want to sell? Christopher Engel From marty at akamai.com Mon Mar 29 10:40:28 2010 From: marty at akamai.com (Hannigan, Martin) Date: Mon, 29 Mar 2010 10:40:28 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <8838.1269639810@marajade.sandelman.ca> Message-ID: > From: Michael Richardson > Date: Fri, 26 Mar 2010 17:43:30 -0400 > To: David Farmer > Cc: > Subject: Re: [arin-ppml] IPv6 Non-connected networks > > >>>>>> "David" == David Farmer writes: > David> WAIT!!! I got hung up on the implied authorization thing. > David> But, now I realize that is not what you were thinking about. > > David> Your right BINGO! > > David> A ula.nro.net type mechanism is the way to coordinate the > David> creation of the random prefixes. How about something like > David> this. > > David> 1. Registrant generates a prefix on ula.nro.net, the tool can > David> generate regular ULA or registered ULA. For registered ULA > David> the tool puts the prefix into a "pending" state in a > David> database, and creates a ticket that can be registered with an > David> RIR. If the state isn't progressed in some timeout say a > David> week then the prefix is returned to the pool. > > David> 2. The Registrant contacts the appropriate RIR, the RIR takes > David> the ticket generated in step 1 and moves the state to > David> "Pending-RIR". The RIR processes and validates the > David> registration. If the RIR refuses the registration or it is > David> dropped, the RIR returns the prefix to the pool. > > David> 3. Once the registration is completed, the state is changed > David> to "Registered", and the database points at the RIR for Whois > David> and reverse DNS so that maybe managed via the RIR's tools > David> from this point on. > > David> 4. The RIR follows its policies and procedures for the life > David> of the registration. > > David> 5. Once the RIR determines the registration is no longer > David> valid (including any hold time) the RIR returns the prefix to > David> the pool. > > David> Other than a few worries related to sparse database problems > David> I think it could work. > > I am happy with this process. Anyone know what the NRO is? Best, Martin From michael.dillon at bt.com Mon Mar 29 11:05:58 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 29 Mar 2010 16:05:58 +0100 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C49745805A13F14@E03MVZ2-UKDY.domain1.systemhost.net> > Anyone know what the NRO is? The answer is right here: http://www.nro.net/ --Michael Dillon From kkargel at polartel.com Mon Mar 29 11:11:02 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 29 Mar 2010 10:11:02 -0500 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <201003262111.o2QLB3sK010124@inana.itg.state.mn.us> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <201003262111.o2QLB3sK010124@inana.itg.state.mn.us> Message-ID: <8695009A81378E48879980039EEDAD28876D4392@MAIL1.polartel.local> > I strongly suspect that most consumers use NAT because that's how > their providers configure it and couldn't care less (or even know) > about it. > > Craig > I will agree with this statement. I will even go on to say that most of the consumers I know of will be thrilled when NAT goes away and their Xbox and PS2 actually work without a bunch of silly router tricks. I don't see what all the IPv6 NAT hoopla is about.. if you want to do NAT or PAT and your hardware supports it fine, go ahead, no skin off anyone else's nose. All you have to do is blackhole a piece of your IPv6 space from the outside at your edge and NAT to it from the inside. There is no problem and there is no need for 1918ish space. The reason for 1918 in the first place was to conserve space. Now that consumers don't need to conserve space to that degree there is no need to continue that demon. A great benefit to using routable space in your "NAT" network is that if you ever need to involve tech support on a piece of natted hardware all it takes is a simple hole in the firewall to them and shazaam they can route directly to your internal device. Then when they are done you just remove the firewall hole and you are back to your nice obscurely secure environment. Kevin From kkargel at polartel.com Mon Mar 29 11:27:49 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 29 Mar 2010 10:27:49 -0500 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <1328EE4D-AC0E-4340-82FB-65DDC89589DF@delong.com> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> <4BAD3C9C.80807@matthew.at> <4BAD438B.9090106@umn.edu> <4BAD4483.3020309@matthew.at> <1328EE4D-AC0E-4340-82FB-65DDC89589DF@delong.com> Message-ID: <8695009A81378E48879980039EEDAD28876D4395@MAIL1.polartel.local> > > How about we make easy and cheap PI GUA available and make NAT66 a non- > issue instead. > > Owen > I second that motion! Kevin From kkargel at polartel.com Mon Mar 29 11:35:34 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 29 Mar 2010 10:35:34 -0500 Subject: [arin-ppml] FW: IPv6 Non-connected networks Message-ID: <8695009A81378E48879980039EEDAD28876D4398@MAIL1.polartel.local> It's not injecting a /119.. you are already advertising a /32.. you just weren't accepting traffic for that /119 before.. Anyone have a problem with that? Kevin > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > Sent: Monday, March 29, 2010 10:18 AM > To: Kevin Kargel > Cc: 'craig.finseth at state.mn.us'; 'marquis at roble.com'; 'arin-ppml at arin.net' > Subject: Re: [arin-ppml] IPv6 Non-connected networks > > > > > A great benefit to using routable space in your "NAT" network is that if > you ever need to involve tech support on a piece of natted hardware all it > takes is a simple hole in the firewall to them and shazaam they can route > directly to your internal device. Then when they are done you just remove > the firewall hole and you are back to your nice obscurely secure > environment. > > > > Kevin > > ok, so i "poke a little hole" ... and announce the /119 to the rest > of the > Internet so that tech support can troubleshoot/update the DUT... > > anyone going to fuss about the random injections of /119's or /124's > into > the routing space? > > --bill From matthew at matthew.at Mon Mar 29 11:38:13 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 29 Mar 2010 08:38:13 -0700 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <8695009A81378E48879980039EEDAD28876D4395@MAIL1.polartel.local> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> <4BAD3C9C.80807@matthew.at> <4BAD438B.9090106@umn.edu> <4BAD4483.3020309@matthew.at> <1328EE4D-AC0E-4340-82FB-65DDC89589DF@delong.com> <8695009A81378E48879980039EEDAD28876D4395@MAIL1.polartel.local> Message-ID: <4BB0C965.6020402@matthew.at> Kevin Kargel wrote: >> How about we make easy and cheap PI GUA available and make NAT66 a non- >> issue instead. >> >> Owen >> >> > I second that motion! > Kevin > This is the preferable choice, certainly. The problem is that it needs to be *routable* PI GUA, and that's not a promise ARIN can be in the business of making... but if it isn't routable space, it'll only be useful as the inside network for the NAT66. The only way for this to work is for ARIN to give the same relatively large size blocks to everyone, so that prefix-length filters can't be used. Again, given how much IPv6 space there is, this might actually be the right choice... but that just makes the "easy and cheap PI GUA" argument even harder to win. Matthew Kaufman From kkargel at polartel.com Mon Mar 29 11:54:52 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 29 Mar 2010 10:54:52 -0500 Subject: [arin-ppml] FW: IPv6 Non-connected networks In-Reply-To: <4BB0C9BE.2040108@matthew.at> References: <8695009A81378E48879980039EEDAD28876D4398@MAIL1.polartel.local> <4BB0C9BE.2040108@matthew.at> Message-ID: <8695009A81378E48879980039EEDAD28876D439A@MAIL1.polartel.local> That's an entirely different problem. Sounds to me like you need a different ISP. Nobody, especially me, is suggesting anyone announce a /119. I am not going to try to advertise a /28 of IPv4 space either. It is just like the IPv4 space you have now. You cannot tell me that every IPv4 address in your advertised space is routed and reachable right now. I know that I have specific addresses blocked at my edge or otherwise blackholed and I have not broken up my BGP announcements to account for them. I suspect that if I ran a port scan across your space some addresses would be unresponsive. It would be bad practice to break an IPv4 /19 (for example) into a multitude of smaller blocks because of one IP address in the middle that you didn't want to route. It is the same for IPv6. And just like today, if I had a /22 that my ISP doesn't want to advertise then I need to look for another ISP or get a bigger block. I still don't see the problem. Kevin > -----Original Message----- > From: Matthew Kaufman [mailto:matthew at matthew.at] > Sent: Monday, March 29, 2010 10:40 AM > To: Kevin Kargel > Cc: 'ppml at arin.net' > Subject: Re: [arin-ppml] FW: IPv6 Non-connected networks > > Kevin Kargel wrote: > > It's not injecting a /119.. you are already advertising a /32.. you > just weren't accepting traffic for that /119 before.. > > > > Anyone have a problem with that? > > > > Kevin > > > The problem is that you weren't already advertising a /32. You were > hoping to advertise your /48, which is all the PI space you could get > and afford, but your ISP wouldn't let you. Just like they won't let you > announce the /119 either. > > Matthew Kaufman From cengel at sponsordirect.com Mon Mar 29 12:00:35 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Mon, 29 Mar 2010 12:00:35 -0400 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: Message-ID: This discussion never ceases to amaze me... though it is very similar to some I've experienced in the IETF NAT66 mailing list. On the one hand...you have alot of folks moaning about why IPv6 adoption is so slow...and the problems that are going to be caused by that to the internet as a whole... and wondering what can be done to spur quicker adoption. Then when some people come along and say.... You know I'd be more likely to consider adopting IPv6 but it doesn't support X (fill in whatever you want for X) and I really need/want to use X. You turn around and dismiss them saying.... oh you're wrong, X is evil. We should never support X...in fact we should do everything we can to prevent X from being supported in IPv6. Then you wonder why the very same people aren't falling all over themselves to adopt IPv6? As an analogy...imagine you're selling phones. You put your brand new yellow phone out on the market and discover that sales are flat. Some portion of your customer base turns around and says... "You know...I'd consider your phone, but I really need it in black." You respond "Oh black is a horrible color.... you should never use black. You don't need black... WE know what you need... you need yellow. You can have any color that you want.... as long as it's YELLOW." Then you turn around and scratch your heads wondering why you aren't selling more phones. I don't know about the average home user. I'm sure most of them don't care about the technical details of how thier internet service is delivered to them/configured....as long as they can get to the sites they want. However for the Enterprise customers... NAT is considered very important. I can think of at least a half dozen ways in which it is useful to me.... have posted them before to this list. I can only think of a single incident where NAT caused any difficulty to me while working here....and that was a very minor and unimportant issue. I hate to tell you all this but...IF IPv6 does see general adoption...NAT/PAT (including many:1 NAT) WILL eventualy be running under it. The reason is simple....there are too many people just like me that find it useful and are willing to pay for it. Eventualy there WILL be vendors who recognize that demand and want to CASH IN on it. They will find a way to make it work in IPv6 even if it involves some very ugly hacks to the protocol.... and you WILL be living on an internet that involves NAT. The only thing that you will achieve by fighting to make NAT harder to use in IPv6 is slowing the adoption of IPv6 itself. Christopher Engel From matthew at matthew.at Mon Mar 29 11:39:42 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 29 Mar 2010 08:39:42 -0700 Subject: [arin-ppml] FW: IPv6 Non-connected networks In-Reply-To: <8695009A81378E48879980039EEDAD28876D4398@MAIL1.polartel.local> References: <8695009A81378E48879980039EEDAD28876D4398@MAIL1.polartel.local> Message-ID: <4BB0C9BE.2040108@matthew.at> Kevin Kargel wrote: > It's not injecting a /119.. you are already advertising a /32.. you just weren't accepting traffic for that /119 before.. > > Anyone have a problem with that? > > Kevin > The problem is that you weren't already advertising a /32. You were hoping to advertise your /48, which is all the PI space you could get and afford, but your ISP wouldn't let you. Just like they won't let you announce the /119 either. Matthew Kaufman From scottleibrand at gmail.com Mon Mar 29 12:07:26 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 29 Mar 2010 09:07:26 -0700 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: References: Message-ID: Chris, Can you describe the 1:many PAT use case for IPv6? I get the need for 1:1 NAT, but not for 1:many PAT. Thanks, Scott On Mar 29, 2010, at 9:00 AM, Chris Engel wrote: > > This discussion never ceases to amaze me... though it is very > similar to some I've experienced in the IETF NAT66 mailing list. On > the one hand...you have alot of folks moaning about why IPv6 > adoption is so slow...and the problems that are going to be caused > by that to the internet as a whole... and wondering what can be done > to spur quicker adoption. > > Then when some people come along and say.... You know I'd be more > likely to consider adopting IPv6 but it doesn't support X (fill in > whatever you want for X) and I really need/want to use X. You turn > around and dismiss them saying.... oh you're wrong, X is evil. We > should never support X...in fact we should do everything we can to > prevent X from being supported in IPv6. > Then you wonder why the very same people aren't falling all over > themselves to adopt IPv6? > > As an analogy...imagine you're selling phones. You put your brand > new yellow phone out on the market and discover that sales are flat. > Some portion of your customer base turns around and says... "You > know...I'd consider your phone, but I really need it in black." You > respond "Oh black is a horrible color.... you should never use > black. You don't need black... WE know what you need... you need > yellow. You can have any color that you want.... as long as it's > YELLOW." > Then you turn around and scratch your heads wondering why you aren't > selling more phones. > > > I don't know about the average home user. I'm sure most of them > don't care about the technical details of how thier internet service > is delivered to them/configured....as long as they can get to the > sites they want. However for the Enterprise customers... NAT is > considered very important. I can think of at least a half dozen ways > in which it is useful to me.... have posted them before to this > list. I can only think of a single incident where NAT caused any > difficulty to me while working here....and that was a very minor and > unimportant issue. > > I hate to tell you all this but...IF IPv6 does see general > adoption...NAT/PAT (including many:1 NAT) WILL eventualy be running > under it. The reason is simple....there are too many people just > like me that find it useful and are willing to pay for it. Eventualy > there WILL be vendors who recognize that demand and want to CASH IN > on it. They will find a way to make it work in IPv6 even if it > involves some very ugly hacks to the protocol.... and you WILL be > living on an internet that involves NAT. The only thing that you > will achieve by fighting to make NAT harder to use in IPv6 is > slowing the adoption of IPv6 itself. > > > > > > Christopher Engel > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From ocl at gih.com Mon Mar 29 12:21:36 2010 From: ocl at gih.com (Olivier MJ Crepin-Leblond) Date: Mon, 29 Mar 2010 17:21:36 +0100 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: References: Message-ID: <4BB0D390.2040502@gih.com> On 29/03/2010 17:00, Chris Engel wrote : > I hate to tell you all this but...IF IPv6 does see general adoption...NAT/PAT (including many:1 NAT) WILL eventualy be running under it. The reason is simple....there are too many people just like me that find it useful and are willing to pay for it. Eventualy there WILL be vendors who recognize that demand and want to CASH IN on it. They will find a way to make it work in IPv6 even if it involves some very ugly hacks to the protocol.... and you WILL be living on an internet that involves NAT. The only thing that you will achieve by fighting to make NAT harder to use in IPv6 is slowing the adoption of IPv6 itself. > Urban Myth #3230: Not allowing XYZ will slow the adoption of IPv6 itself. Reason: IPv4 addresses are running out. When the pain threshold for IPv4 addresses will be reached, IPv6 adoption will increase in rate. (and of course, yu can reply with Urban Myth #3231...) I'd be really grateful if this matter could be put to bed. I mean - it's obvious that there are two sides which don't agree. This discussion can go on ad-infinitum and I somehow don't see a solution to this. I'm usually not someone to say this, and I humbly hope that I shan't offend anyone, but in this instance, it's becoming repetitive... Thanks, Olivier -- Olivier MJ Cr?pin-Leblond, PhD http://www.gih.com/ocl.html From matthew at matthew.at Mon Mar 29 12:51:14 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 29 Mar 2010 09:51:14 -0700 Subject: [arin-ppml] FW: IPv6 Non-connected networks In-Reply-To: <8695009A81378E48879980039EEDAD28876D439A@MAIL1.polartel.local> References: <8695009A81378E48879980039EEDAD28876D4398@MAIL1.polartel.local> <4BB0C9BE.2040108@matthew.at> <8695009A81378E48879980039EEDAD28876D439A@MAIL1.polartel.local> Message-ID: <41D49717-ED23-4B46-91A3-0FE0E0BB8963@matthew.at> I was conflating the two threads. If you read my point about your /48 (or /56 or whatever the "cheap and easy" size of GUA will be) of PI GUA as not being accepted by your (or any) ISP, then it might make more sense. I agree with your point that you wouldn't split a PI block up just to leave a hole of local space in the middle. Matthew Kaufman (Sent from my iPhone, thank the poor UI for the top-posting) On Mar 29, 2010, at 8:54 AM, Kevin Kargel wrote: > That's an entirely different problem. Sounds to me like you need a > different ISP. > > Nobody, especially me, is suggesting anyone announce a /119. I am > not going to try to advertise a /28 of IPv4 space either. > > It is just like the IPv4 space you have now. You cannot tell me > that every IPv4 address in your advertised space is routed and > reachable right now. I know that I have specific addresses blocked > at my edge or otherwise blackholed and I have not broken up my BGP > announcements to account for them. I suspect that if I ran a port > scan across your space some addresses would be unresponsive. > > It would be bad practice to break an IPv4 /19 (for example) into a > multitude of smaller blocks because of one IP address in the middle > that you didn't want to route. It is the same for IPv6. > > And just like today, if I had a /22 that my ISP doesn't want to > advertise then I need to look for another ISP or get a bigger block. > > I still don't see the problem. > > Kevin > > > > >> -----Original Message----- >> From: Matthew Kaufman [mailto:matthew at matthew.at] >> Sent: Monday, March 29, 2010 10:40 AM >> To: Kevin Kargel >> Cc: 'ppml at arin.net' >> Subject: Re: [arin-ppml] FW: IPv6 Non-connected networks >> >> Kevin Kargel wrote: >>> It's not injecting a /119.. you are already advertising a /32.. >>> you >> just weren't accepting traffic for that /119 before.. >>> >>> Anyone have a problem with that? >>> >>> Kevin >>> >> The problem is that you weren't already advertising a /32. You were >> hoping to advertise your /48, which is all the PI space you could get >> and afford, but your ISP wouldn't let you. Just like they won't let >> you >> announce the /119 either. >> >> Matthew Kaufman From mcr at sandelman.ca Mon Mar 29 12:53:18 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 29 Mar 2010 12:53:18 -0400 Subject: [arin-ppml] FW: IPv6 Non-connected networks In-Reply-To: <4BB0C9BE.2040108@matthew.at> References: <8695009A81378E48879980039EEDAD28876D4398@MAIL1.polartel.local> <4BB0C9BE.2040108@matthew.at> Message-ID: <12104.1269881598@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Matthew" == Matthew Kaufman writes: Matthew> The problem is that you weren't already advertising a Matthew> /32. You were hoping to advertise your /48, which is all Matthew> the PI space you could get and afford, but your ISP Matthew> wouldn't let you. Just like they won't let you announce the Matthew> /119 either. All of this is IPv4 think. IPv6 networks have multiple prefixes(%) You were using the NCN for internal use. You had a /48 from each ISP, split up into /64s. Most of your internal-only operations had no visibility to the Internet. (You might want to use good ol' fashion SOCKS and algorithm-gateways and HTTP proxies to get your system patches. If you like I have Raptor Eagle, Milkyway Blackhole, and TIS FWTK binaries from the early 1990s) You let a /64 from one ISP through to some machine that external support needs to access (no, it's not a /119. It's a /64). You might even run this through a transparent firewall/packet filter too. (%) While Owen has documented why he feels multiple prefixes won't work, but I've never had the problems he describes. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBS7Da/YCLcPvd0N1lAQIt7gf+JXLR0osv/sDJVQ4H9zJhx9LQbEJw2Acz XUjUFzJj2LVzP1Z6cnqXzkbe+3A8JS4xbO7IKmohnDHn/KgZeXnAoMY2JbZYyi3T jOF0CK3KLI7f8ln/Vp/7SFobSO84dnbcSFV74B6htKOEmtw9J4rpHnDA3vqA7jMH sTfhGAavSY9a1Oa+pgCn0X8bHAv4zquIag/xXJxYSOUXrMdSfk/vhGVTuX6WvitT 74onh+SGYLZ/Zh9HpRGrVj/ixZrbPMMMRnmgzRZWvwKxqVhJsPQsbymKdfmzd3F/ GnXe7pb2y4DJOMwTWlu7LEnDNoyoOb3+wJbgNdoEwUjM6r9iWtC+7g== =Iezl -----END PGP SIGNATURE----- From cengel at sponsordirect.com Mon Mar 29 13:53:34 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Mon, 29 Mar 2010 13:53:34 -0400 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <4BB0D390.2040502@gih.com> Message-ID: Olivier MJ Cr?pin-Leblond wrote: > I'd be really grateful if this matter could be put to bed. I > mean - it's obvious that there are two sides which don't > agree. This discussion can go on ad-infinitum and I somehow > don't see a solution to this. I'm usually not someone to say > this, and I humbly hope that I shan't offend anyone, but in > this instance, it's becoming repetitive... Oliver, You are correct in the above. More to the point, it's rather academic to the purposes of this list. The needs of some-one who wants private IPv6 space for the purposes of using it in conjunction with NAT are not (I believe) functionaly different from those who want private IPv6 for other purposes. As long as people are in general agreement that IPv6 private space should be available for people who want it (for whatever purposes) then whether those organizations choose to deploy NAT or not....seems entirely tangential. With ULA-random that's entirely a non-issue (as it seems use-able in roughly the equivalent fashion that RFC1918 space currently is). The only issue that I could see potentialy cropping up would be if there was some particular conflict in the justification rules for ULA-C. Not sure exactly what the details of those would be.... but essentialy getting ULA-C assignment for ones equipment shouldn't generaly hinder/count against getting an assignment of Public IP address space for a subset of that same equipment. That's about the only issue I could see that would be relevant to the current discussion. Scott Leibrand wrote: > Chris, > > Can you describe the 1:many PAT use case for IPv6? I get the > need for > 1:1 NAT, but not for 1:many PAT. Scott, I'll reply off-list in order to spare folks the gory details of this discussion. As it seems like this discussion is causing uneccesary clutter for many folks here. Anyone that's actualy interested in this issue...feel free to drop me a note and I'll CC you on my answer to Scott. Christopher Engel From kkargel at polartel.com Mon Mar 29 13:58:09 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 29 Mar 2010 12:58:09 -0500 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: References: <4BB0D390.2040502@gih.com> Message-ID: <8695009A81378E48879980039EEDAD28876D43A8@MAIL1.polartel.local> >.... but essentialy getting > ULA-C assignment for ones equipment shouldn't generaly hinder/count > against getting an assignment of Public IP address space for a subset of > that same equipment. That's about the only issue I could see that would be > relevant to the current discussion. I will agree with you so long as the ULA-C never takes a global routing slot. The instant it does then it is GUA and should incur the same costs and justifications that GUA does. From matthew at matthew.at Mon Mar 29 14:12:28 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 29 Mar 2010 11:12:28 -0700 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <8695009A81378E48879980039EEDAD28876D43A8@MAIL1.polartel.local> References: <4BB0D390.2040502@gih.com> <8695009A81378E48879980039EEDAD28876D43A8@MAIL1.polartel.local> Message-ID: <4BB0ED8C.1020607@matthew.at> Kevin Kargel wrote: >> .... but essentialy getting >> ULA-C assignment for ones equipment shouldn't generaly hinder/count >> against getting an assignment of Public IP address space for a subset of >> that same equipment. That's about the only issue I could see that would be >> relevant to the current discussion. >> > > I will agree with you so long as the ULA-C never takes a global routing slot. The instant it does then it is GUA and should incur the same costs and justifications that GUA does. > This is easy to do. Assign it from space for which there is an IETF standard telling router vendors to never, ever, accept that route via external routing protocols. Matthew Kaufman From cengel at sponsordirect.com Mon Mar 29 14:17:05 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Mon, 29 Mar 2010 14:17:05 -0400 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <8695009A81378E48879980039EEDAD28876D43A8@MAIL1.polartel.local> Message-ID: Kevin Kargel wrote: > >.... but essentialy getting > > ULA-C assignment for ones equipment shouldn't generaly > hinder/count > >against getting an assignment of Public IP address space for > a subset > >of that same equipment. That's about the only issue I could > see that > >would be relevant to the current discussion. > > I will agree with you so long as the ULA-C never takes a > global routing slot. The instant it does then it is GUA and > should incur the same costs and justifications that GUA does. Kevin, I agree with this. That is kind of the whole point between ULA space, is it not? If ULA of what-ever type starts to become globaly routed...then it looses a good chunk of it's value to the persons using it...I would think. The appropriate solution for some-one who wants "not-connected now, but maybe some-time in the future" space....and isn't willing to renumber...I would think would be to request GUA space (with the same costs and justifications as any other GUA request) ....and work it out with thier upstreams NOT to route that space until the organization is ready. Christopher Engel From marquis at roble.com Mon Mar 29 14:36:46 2010 From: marquis at roble.com (Roger Marquis) Date: Mon, 29 Mar 2010 11:36:46 -0700 (PDT) Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: References: Message-ID: <20100329183646.E36AC2B2128@mx5.roble.com> Scott Leibrand wrote: > Leaving aside NAT-PT and v4-v6 transition for the moment, can you > clarify how you would like to deploy NAT in an IPv6-only environment? Substantially similar to the deployment of NAT in IPv4 environments i.e., a mixture of 1:1, 1:many, NAT and PAT with stateful translation for badly designed protocols like SIP. Why? For the same reasons we used non-routable addresses before NAT, privacy, freedom from external dependencies, and certainly not least security. IPv6 changes nothing relevant other than the size of the address pool, but NAT did not evolve simply to address address space shortages (though that was one of reasons cited at the time). Of course that's many years in the future. We need NAT64 now and for the duration of the transition. Roger Marquis From marquis at roble.com Mon Mar 29 14:49:06 2010 From: marquis at roble.com (Roger Marquis) Date: Mon, 29 Mar 2010 11:49:06 -0700 (PDT) Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <3C5EE00C-7B9E-4FCE-8903-CF736A687511@delong.com> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <3C5EE00C-7B9E-4FCE-8903-CF736A687511@delong.com> Message-ID: <20100329184906.BAAC42B2128@mx5.roble.com> Owen not-a-security-engineer DeLong wrote: > Things actually slowing down residential IPv6 deployment: > + Lack of CPE support > + Lack of Head-End (PON concentrator, DSLAM, CMTS, etc.) support > + Lack of support from the ISP The same arguments can be made for NAT. NAT stateful translation can be added to CPE just as easily as IPv6 support can be added to CPE. Upgrading equipment in COs and in colos is no more difficult either. Citing the lack of CPE support for Torrent, SIP and other protocols as a reason to leave NAT out of IPv6 is specious. The CPE will still need stateful translation to provide the same security, and NAT is the simplist way to do it. If customer support engineers are frustrated by calls for better VOIP and Torrent support they should provide CPE that supports these protocols securely and transparently instead of complaining about NAT. Roger Marquis From marquis at roble.com Mon Mar 29 15:11:21 2010 From: marquis at roble.com (Roger Marquis) Date: Mon, 29 Mar 2010 12:11:21 -0700 (PDT) Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <3c3e3fca1003261444t6b53f284v2d0ea47e42aac9c6@mail.gmail.com> References: <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <3c3e3fca1003261444t6b53f284v2d0ea47e42aac9c6@mail.gmail.com> Message-ID: <20100329191121.3BF1C2B2128@mx5.roble.com> On Fri, 26 Mar 2010, William Herrin wrote: >> It isn't just network security professionals who won't give up NAT, >> end-user consumers also won't. > > Oh, I don't know about that. Consumers generally use what the ISP > provides. Good point, but only to a degree. Given that corporate sites will demand NAT it will get implemented. Once implemented consumers will follow. Equipment manufacturers see this and are are reluctant to build gear that they know will quickly become obsolete. "Build a better mousetrap ..." and all. There are also increasing number of savvy consumers. Note the similarities in this argument to ILEC's rational for disabling cell phone features. They've made hardware manufacturers jump through hoops for years, disabling features and barring customers from much wanted functionality. As soon as one hardware maker offers a feature (like the Palm Pre's MyTether, an EVDO/Wifi router) that game's over. Offer a non-feature competitive smartphone and ILECs will find their market has become much smaller than anticipated. Same holds for NAT. Offer feature-limited CPE that requires 1:1 and complex ACLs and ISPs will end up shrinking their own market share (at least where competition exists). I'd also expect consumer advocacy organizations (like the EFF) to make the case for privacy, especially when the same feature (NAT) also protects consumers from vendor-locking. While the IETF may no longer be able to execute due to special interests, legislators can and will. I kind of doubt they'll be persuaded by arguments that NAT makes (illegal) filesharing or obsolete protocols (SIP) "too hard" (on cheap CPE). Legislators will surely hear from security engineers and their case will be compelling. The case for disabling features (NAT) and barring customers from much wanted functionality (fixed and private internal addresses) will not likely hold up in this public debate. IMO, Roger Marquis From owen at delong.com Mon Mar 29 13:34:45 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 29 Mar 2010 10:34:45 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: References: Message-ID: On Mar 29, 2010, at 7:39 AM, Chris Engel wrote: > Owen DeLong wrote: > >> You are assuming a lot more about human behavior by less >> qualified individuals than is required in my assertion that >> people should properly configure their firewalls. If I have >> to tolerate NAT and it's damage because you can't reliably >> avoid mistakes that fail open on your firewalls, then, you >> need to allow for a way to reimburse my costs that come from >> your even less qualified end users that also happen to be my >> customers. > > > Owen, > > Who am I to tell you how to bill your customers? If you want to bill some sort of "NAT surcharge" into your fees or (a probably more reasonable way to recoup costs) charge support by the minute/hour then go for it if your business model supports it. I certainly don't tell you how to bill. > Again, you miss my point. If you implement NAT, and, it causes problems for my customers that costs me time (==money) to troubleshoot, I want a way to recover those costs from you, the person who inflicted the damage, not my customer who is an innocent bystander/victim of your NAT choices. > However, I don't see how that situation is any different then supporting a customer who isn't technicaly profficient ("um... what's my IP address? A command prompt...what is that?") or speaks slowly, or maybe has a language barrier...or maybe has something else going on thier network that interferes with your equipment.... all of which would cause you more time/effort in support then you would ordinarly need to (I've done plenty of support calls in my day). Should none of those people be allowed use of the internet because they would cost more support time then others? > The idea of distinguishing between that which cannot be helped (the scenarios you describe in the above paragraph) and willful acts of destruction (NAT) is not a new concept. Generally, the law tends to hold that liability is created only in the latter case. > > Furthermore, I would think the answer to your situation would be rather straightforward. If you are the designer of the equipment/software that you are working with... why wouldn't you design in a special diagnostic mode on your phone that sent out a unique number/code for the particular phone issued to that customer inside each packet sent....and then build a tool that could work with a packet sniffer to examine the packets you were recieving to see if any of them corresponded to that phone? That should tell you definitively whether you were getting any of those packets regardless of what was happening with the packet headers (and presumably even independant of whatever protocol they might be running under). > 1. You are assuming I control the design/manufacture of the CPE. I'm talking about something more like a SIP-based service (BYO-hardware). 2. You are assuming I want to design/manufacture/sell hardware. I don't, I want to sell services based on existing standards. > Turning the arguement around on you... why should NAT be disallowed on the entire internet simply because you can't be bothered to build in more robust diagnostic tools on the equipment that you want to sell? > I'm not trying to sell equipment, I'm trying to sell service based on existing standard protocols. Why should people trying to do that have to redesign their equipment and services because you want to use NAT? Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Mar 29 13:52:26 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 29 Mar 2010 10:52:26 -0700 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: References: Message-ID: <9F40AA80-0E02-4C7F-9480-D0232EB55AF0@delong.com> On Mar 29, 2010, at 9:00 AM, Chris Engel wrote: > > This discussion never ceases to amaze me... though it is very similar to some I've experienced in the IETF NAT66 mailing list. On the one hand...you have alot of folks moaning about why IPv6 adoption is so slow...and the problems that are going to be caused by that to the internet as a whole... and wondering what can be done to spur quicker adoption. > > Then when some people come along and say.... You know I'd be more likely to consider adopting IPv6 but it doesn't support X (fill in whatever you want for X) and I really need/want to use X. You turn around and dismiss them saying.... oh you're wrong, X is evil. We should never support X...in fact we should do everything we can to prevent X from being supported in IPv6. > Then you wonder why the very same people aren't falling all over themselves to adopt IPv6? > > As an analogy...imagine you're selling phones. You put your brand new yellow phone out on the market and discover that sales are flat. Some portion of your customer base turns around and says... "You know...I'd consider your phone, but I really need it in black." You respond "Oh black is a horrible color.... you should never use black. You don't need black... WE know what you need... you need yellow. You can have any color that you want.... as long as it's YELLOW." The difference is that the color of your phone only affects those who have to look at it (you). NAT affects the broader internet and inflicts costs on people not responsible for the decision to use NAT. It's more like selling solar-based backup power units and having the customers come along and say "I'd like to buy this, but, I really need it to burn coal instead of depending on sunshine." > Then you turn around and scratch your heads wondering why you aren't selling more phones. > Actually, the places that most need to deploy IPv6 at this point being eye-ball ISPs and the public-facing portions of content and services providers, I don't think that NAT has been an actual barrier to adoption in either of those spaces. The vast majority of people calling for NAT66 are the enterprise interior, which is, IMHO, the least critical and least likely group to get on the IPv6 bandwagon quickly regardless of what is done to appease them. > > I don't know about the average home user. I'm sure most of them don't care about the technical details of how thier internet service is delivered to them/configured....as long as they can get to the sites they want. However for the Enterprise customers... NAT is considered very important. I can think of at least a half dozen ways in which it is useful to me.... have posted them before to this list. I can only think of a single incident where NAT caused any difficulty to me while working here....and that was a very minor and unimportant issue. > Yep... That's the key problem with NAT that causes me to refer to it as a toxic pollutant. It doesn't cause any problems to the NAT implementer, it causes problems (costs) to people that are providing services to users behind the NAT implementer. The NAT implementer has access to both sides of the NAT to investigate problems and knows that NAT is there to inflict damage. He knows what kind of damage his particular NAT is inflicting and so his troubleshooting environment is deterministic and readily understood by him. On the other hand, for someone selling services to customers behind said NAT who has no access to both sides for diagnostic purposes and has no direct knowledge of the particular implementation or model of damage being done, it increases variables, costs, time, etc. > I hate to tell you all this but...IF IPv6 does see general adoption...NAT/PAT (including many:1 NAT) WILL eventualy be running under it. The reason is simple....there are too many people just like me that find it useful and are willing to pay for it. Eventualy there WILL be vendors who recognize that demand and want to CASH IN on it. They will find a way to make it work in IPv6 even if it involves some very ugly hacks to the protocol.... and you WILL be living on an internet that involves NAT. The only thing that you will achieve by fighting to make NAT harder to use in IPv6 is slowing the adoption of IPv6 itself. > If NAT lives only at a few enterprise borders, that's fine. Having generalized support for NAT in the protocol specs, OTOH, would encourage a much wider deployment of it and worse, cruft in software to support NAT traversal all over again. If we can just avoid ISVs producing stuffing NAT traversal code into their software, it's a win for the industry in general, and, the damage by NAT become a consequence to your network instead of the rest of the world. I can live with that. Owen From owen at delong.com Mon Mar 29 13:41:23 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 29 Mar 2010 10:41:23 -0700 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <4BB0C965.6020402@matthew.at> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com> <1269640096.5400.411.camel@ggiesen-workstation.netsurf.net> <4BAD2D10.4060107@matthew.at> <1269641156.5400.439.camel@ggiesen-workstation.netsurf.net> <4BAD3C9C.80807@matthew.at> <4BAD438B.9090106@umn.edu> <4BAD4483.3020309@matthew.at> <1328EE4D-AC0E-4340-82FB-65DDC89589DF@delong.com> <8695009A81378E48879980039EEDAD28876D4395@MAIL1.polartel.local> <4BB0C965.6020402@matthew.at> Message-ID: <1B6EF7A7-9464-40C5-9CA0-6C580D5AD1C5@delong.com> On Mar 29, 2010, at 8:38 AM, Matthew Kaufman wrote: > Kevin Kargel wrote: >>> How about we make easy and cheap PI GUA available and make NAT66 a non- >>> issue instead. >>> >>> Owen >>> >>> >> I second that motion! >> Kevin >> > This is the preferable choice, certainly. The problem is that it needs to be *routable* PI GUA, and that's not a promise ARIN can be in the business of making... but if it isn't routable space, it'll only be useful as the inside network for the NAT66. The only way for this to work is for ARIN to give the same relatively large size blocks to everyone, so that prefix-length filters can't be used. Again, given how much IPv6 space there is, this might actually be the right choice... but that just makes the "easy and cheap PI GUA" argument even harder to win. > > > Matthew Kaufman I was not suggesting anything smaller than a /48 at the ARIN level. That should resolve the above concern. Routability then falls to a negotiating matter between the registrant and their ISP(s). Owen From matthew at matthew.at Mon Mar 29 19:29:38 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 29 Mar 2010 16:29:38 -0700 Subject: [arin-ppml] FW: IPv6 Non-connected networks In-Reply-To: <12104.1269881598@marajade.sandelman.ca> References: <8695009A81378E48879980039EEDAD28876D4398@MAIL1.polartel.local> <4BB0C9BE.2040108@matthew.at> <12104.1269881598@marajade.sandelman.ca> Message-ID: <4BB137E2.8070203@matthew.at> Michael Richardson wrote: > > All of this is IPv4 think. > > IPv6 networks have multiple prefixes(%) > You were using the NCN for internal use. > > > Going with multiplex prefixes as the multihoming solution just means you need to renumber lots of network hardware any time you change *any* of your upstreams (assuming an even moderately complex topology). There's also as-yet-unsolved software-side issues that may or may not be solved in time. > (%) While Owen has documented why he feels multiple prefixes won't work, > but I've never had the problems he describes. > I'd love to compare this list to mine... can you (or Owen) provide a reference? For IPv6 I'm more a software guy (RTMFP in Flash Player does IPv6) than an operator (sold my last (non-IPv6-capable) ISP a few months ago, have one IPv6 upstream via tunnel at home). Matthew Kaufman From Lee at dilkie.com Mon Mar 29 19:31:13 2010 From: Lee at dilkie.com (Lee Dilkie) Date: Mon, 29 Mar 2010 19:31:13 -0400 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: <9F40AA80-0E02-4C7F-9480-D0232EB55AF0@delong.com> References: <9F40AA80-0E02-4C7F-9480-D0232EB55AF0@delong.com> Message-ID: <4BB13841.4060908@dilkie.com> Owen DeLong wrote: > Actually, the places that most need to deploy IPv6 at this point being eye-ball ISPs and the public-facing portions of content and services providers, I don't think that NAT has been an actual barrier to adoption in either of those spaces. The vast majority of people calling for NAT66 are the enterprise interior, which is, IMHO, the least critical and least likely group to get on the IPv6 bandwagon quickly regardless of what is done to appease them. > This is a critical observation. The very same folks who will, for various reasons besides NAT even, be slow to adopt IPv6 are also relatively small users of IPv4 and aren't really our target for early adopters. We're trying to get the big ticket users, consumers, to move over and for that there is no need to discuss NAT. > If NAT lives only at a few enterprise borders, that's fine. Having generalized support for NAT in the protocol specs, OTOH, would encourage a much wider deployment of it and worse, cruft in software to support NAT traversal all over again. If we can just avoid ISVs producing stuffing NAT traversal code into their software, it's a win for the industry in general, and, the damage by NAT become a consequence to your network instead of the rest of the world. I can live with that. > > I don't think anyone expects enterprises to throw open their borders and allow unrestricted access to internal hosts. Border control gateways will exist and can exist without address translation. It can also exist with address translation for selected protocols, if that makes one feel better. However, it's generally impossible to create a "generalized support for NAT in the protocol specs". These things will always end up being specific application-layer gateways that exist as man-in-the-middle solutions. Enterprises can pay for that. For the consumer and small business endpoints, avoiding NAT will go a long way to helping avoid the costs it inflicts on others. -lee From steve at ibctech.ca Mon Mar 29 20:47:25 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 29 Mar 2010 20:47:25 -0400 Subject: [arin-ppml] GUA vs ULA vs ? Message-ID: <4BB14A1D.6030100@ibctech.ca> I am overwhelmed with the number of posts regarding the whole 'Non-connected networks', so I'll admit freely that I haven't been able to keep up. With that said, I would like to share my opinion(s), even if they conflict, overlap, or otherwise override what others may have said. Prelim: - I am in favour of eliminating NAT from IPv6 - I do have experience in dealing with both the ISP environment, and the small-medium enterprise (across multiple boundaries), so I do see the 'value' of NAT (I use the term 'value' loosely) - Since I have dealt with both sides, I am willing and able to drop all bias toward NAT for the purpose of this discussion - I want what is best for everyone Understanding: - I'm a bit behind the curve on some of the abbreviations, but I believe that this is correct: --- ULA == Unique Local Address --- GUA == Global Unique Address If that is the case, here is how I feel... We'll assume that I want to try to exploit a weakness in the policy to garner space that I'll "say" won't be routed, but thinking that I'll route it eventually anyways. If the community decides that ARIN, not IANA, should provide 'private' space, it should: - be from a large block designated as such. --- why? - So that the maintainers of BOGON lists (eg: Team Cymru) can hold one slot in their filters for all entrants, ensuring that enough staggered and unpredictable routing breakage will occur to ensure that serious network engineers/architects will realize that the `cheap way out' won't work - as has been said, ARIN is not a routing policy maker. However, if someone has a block allocated by ARIN that is 'supposed' to be private (ie. not globally routable) but it happens to show up in the DFZ, then it costs me. Perhaps it costs me for the extra tax hit I pay on my filter list, or if I choose to not be diligent, a slot in my routing table Although I want the barrier-to-entry for IPv6 to be very low, I don't like the idea of ARIN supplying ULA, unless it sits equal in cost to GUA, and unless ARIN can supply it in a way that facilitates a very simple method for third parties to (help) ensure that the ULA will never appear in the DFZ. Otherwise, the way I see it, is that the cost of my /32 has the same administrative costs to ARIN as someone else's ULA. If ARIN doesn't achieve a lower administrative overhead to managing the different IP space, then the price should be equal. Perhaps IANA should be approached for a 1918 v6. Perhaps I'm out of my league ;) Steve From marquis at roble.com Mon Mar 29 22:03:56 2010 From: marquis at roble.com (Roger Marquis) Date: Mon, 29 Mar 2010 19:03:56 -0700 (PDT) Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <54ACBE6F-332B-4A8F-A6C8-3983F044ECEE@delong.com> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <3C5EE00C-7B9E-4FCE-8903-CF736A687511@delong.com> <20100329184906.BAAC42B2128@mx5.roble.com> <54ACBE6F-332B-4A8F-A6C8-3983F044ECEE@delong.com> Message-ID: <20100330020357.061BD2B2124@mx5.roble.com> >> Upgrading equipment in COs and in colos is no more difficult either. >> > True, but, the average residential customer couldn't care less about NAT. > In fact, most of the residential customers I know long for the ability to choose > their level of accessibility rather than being stuck in a NAT straightjacket. NAT is easily disabled in every type of CPE I've seen over the past 15 years. Show me the stateful ACLs that replace NAT reliably and then you'll at least have made a case WRT security. We haven't seen those filters yet, much less an equally reliable replacement for NAT's topology hiding, protection from (ILEC/ISP) vendor lock-in, or renumberless multi-homing. >> Citing the lack of CPE support for Torrent, SIP and other protocols as a >> reason to leave NAT out of IPv6 is specious. The CPE will still need >> stateful translation to provide the same security, and NAT is the >> simplist way to do it. >> > No, it needs stateful inspection, not translation. Right, translation is not needed, but translation is easily added to stateful inspection. Even the cheapest CPE can get this right without complexity. Stateful inspection is the hard part that is often mistaken for NAT "brokenness". Roger Marquis From farmer at umn.edu Mon Mar 29 22:18:12 2010 From: farmer at umn.edu (David Farmer) Date: Mon, 29 Mar 2010 21:18:12 -0500 Subject: [arin-ppml] GUA vs ULA vs ? In-Reply-To: <4BB14A1D.6030100@ibctech.ca> References: <4BB14A1D.6030100@ibctech.ca> Message-ID: <4BB15F64.4030108@umn.edu> Steve Bertrand wrote: > I am overwhelmed with the number of posts regarding the whole > 'Non-connected networks', so I'll admit freely that I haven't been able > to keep up. I don't see anything here that would lead me to believe that you missed anything critical in the conversation so far. > With that said, I would like to share my opinion(s), even if they > conflict, overlap, or otherwise override what others may have said. Thank you for providing your opinions. > Prelim: > > - I am in favour of eliminating NAT from IPv6 > - I do have experience in dealing with both the ISP environment, and the > small-medium enterprise (across multiple boundaries), so I do see the > 'value' of NAT (I use the term 'value' loosely) > - Since I have dealt with both sides, I am willing and able to drop all > bias toward NAT for the purpose of this discussion > - I want what is best for everyone > > Understanding: > > - I'm a bit behind the curve on some of the abbreviations, but I believe > that this is correct: > --- ULA == Unique Local Address > --- GUA == Global Unique Address > > If that is the case, here is how I feel... That is how I have been using them and I believe others are using them to mean that too. > We'll assume that I want to try to exploit a weakness in the policy to > garner space that I'll "say" won't be routed, but thinking that I'll > route it eventually anyways. > > If the community decides that ARIN, not IANA, should provide 'private' > space, it should: > > - be from a large block designated as such. Personally, I'd like to have the IETF define FC00::/8 for this purpose, and delegate it to IANA to allocate to the RIRs for assignment to organizations using process similar to those used for GUA today and using policies designated by the RIRs. Among other things, this provides a single prefix for all the RIR's to use, and only one filter entry to block it globally and ULA-L (FC00::/7), also keeps ARIN from having to define routing policy, it comes from the IETF. I think this is compatible with what you are saying. > --- why? > > - So that the maintainers of BOGON lists (eg: Team Cymru) can hold one > slot in their filters for all entrants, ensuring that enough staggered > and unpredictable routing breakage will occur to ensure that serious > network engineers/architects will realize that the `cheap way out' won't > work Agreed. And, FC00::/7 is already in their BOGON list. > - as has been said, ARIN is not a routing policy maker. However, if > someone has a block allocated by ARIN that is 'supposed' to be private > (ie. not globally routable) but it happens to show up in the DFZ, then > it costs me. Perhaps it costs me for the extra tax hit I pay on my > filter list, or if I choose to not be diligent, a slot in my routing table > > Although I want the barrier-to-entry for IPv6 to be very low, I don't > like the idea of ARIN supplying ULA, unless it sits equal in cost to > GUA, and unless ARIN can supply it in a way that facilitates a very > simple method for third parties to (help) ensure that the ULA will never > appear in the DFZ. I believe GUA-PI and ULA-C should be equal cost and provided under either identical or essentially identical policies. At least I think that is what ARIN's policies should be, it would be good if the other RIRs followed suite, but that is their call. > Otherwise, the way I see it, is that the cost of my /32 has the same > administrative costs to ARIN as someone else's ULA. If ARIN doesn't > achieve a lower administrative overhead to managing the different IP > space, then the price should be equal. Your /32 presumably is a GUA-PA provider allocation not an GUA-PI end-user assignment. I believe that the comparison should be between GUA-PI and ULA-C, not between GUA-PA and ULA-C. Presumably, a providers will be making assignments to its customers, which does involve so additional interaction and cost for ARIN. Which I believe is at least part of the justification for the different billing models between providers and end-users, but that is a whole different discussion and not really a policy matter. > Perhaps IANA should be approached for a 1918 v6. Perhaps I'm out of my > league ;) Essentially, ULA RFC 4193 is the IPv6 replacement for RFC 1918, it provides for random local assignment within the prefix FD00::/8, it provides significant statistical uniqueness, but not a guarantee of uniqueness. ULA-C (Central) is an expansion of this intended to guaranteed uniqueness through a centrally registry with assignments made within the prefix FC00::/8, and reverse DNS delegation should be available if wanted. > Steve -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From steve at ibctech.ca Mon Mar 29 22:58:01 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 29 Mar 2010 22:58:01 -0400 Subject: [arin-ppml] GUA vs ULA vs ? In-Reply-To: <4BB15F64.4030108@umn.edu> References: <4BB14A1D.6030100@ibctech.ca> <4BB15F64.4030108@umn.edu> Message-ID: <4BB168B9.2050205@ibctech.ca> On 2010.03.29 22:18, David Farmer wrote: > Steve Bertrand wrote: >> I am overwhelmed with the number of posts regarding the whole >> 'Non-connected networks', so I'll admit freely that I haven't been able >> to keep up. > > I don't see anything here that would lead me to believe that you missed > anything critical in the conversation so far. Good. >> - I am in favour of eliminating NAT from IPv6 >> - I do have experience in dealing with both the ISP environment, and the >> small-medium enterprise (across multiple boundaries), so I do see the >> 'value' of NAT (I use the term 'value' loosely) >> - Since I have dealt with both sides, I am willing and able to drop all >> bias toward NAT for the purpose of this discussion >> - I want what is best for everyone >> >> Understanding: >> >> - I'm a bit behind the curve on some of the abbreviations, but I believe >> that this is correct: >> --- ULA == Unique Local Address >> --- GUA == Global Unique Address >> >> If that is the case, here is how I feel... > > That is how I have been using them and I believe others are using them > to mean that too. Again, good. Disclaimer: Although I try my best to implement the technologies and the BCPs of the large providers, my current experience is enveloped within the scope of having < 10k resi and a few hundred business-class clients (BGP multi-homed). My experience with enterprise is < 5k nodes across < 50 sites. >> We'll assume that I want to try to exploit a weakness in the policy to >> garner space that I'll "say" won't be routed, but thinking that I'll >> route it eventually anyways. >> >> If the community decides that ARIN, not IANA, should provide 'private' >> space, it should: >> >> - be from a large block designated as such. > > Personally, I'd like to have the IETF define FC00::/8 for this purpose, > and delegate it to IANA to allocate to the RIRs for assignment to > organizations using process similar to those used for GUA today and > using policies designated by the RIRs. Among other things, this > provides a single prefix for all the RIR's to use, and only one filter > entry to block it globally and ULA-L (FC00::/7), also keeps ARIN from > having to define routing policy, it comes from the IETF. I think this is > compatible with what you are saying. Then why is this not happening? fc00::/8 works for me, especially if it is supported/RFC'd at the IETF level. imho, it is not in our (the community) best interest to manage 'private' space. >> --- why? >> >> - So that the maintainers of BOGON lists (eg: Team Cymru) can hold one >> slot in their filters for all entrants, ensuring that enough staggered >> and unpredictable routing breakage will occur to ensure that serious >> network engineers/architects will realize that the `cheap way out' won't >> work > > Agreed. And, FC00::/7 is already in their BOGON list. Damn skippy: #sh ipv6 route fc00::1 IPv6 Routing Table - 17929 entries B 8000::/1 [200/0] via 2001:DB8:0:DEAD:BEEF::1 >> - as has been said, ARIN is not a routing policy maker. However, if >> someone has a block allocated by ARIN that is 'supposed' to be private >> (ie. not globally routable) but it happens to show up in the DFZ, then >> it costs me. Perhaps it costs me for the extra tax hit I pay on my >> filter list, or if I choose to not be diligent, a slot in my routing >> table >> >> Although I want the barrier-to-entry for IPv6 to be very low, I don't >> like the idea of ARIN supplying ULA, unless it sits equal in cost to >> GUA, and unless ARIN can supply it in a way that facilitates a very >> simple method for third parties to (help) ensure that the ULA will never >> appear in the DFZ. > > I believe GUA-PI and ULA-C should be equal cost and provided under > either identical or essentially identical policies. At least I think > that is what ARIN's policies should be, it would be good if the other > RIRs followed suite, but that is their call. > >> Otherwise, the way I see it, is that the cost of my /32 has the same >> administrative costs to ARIN as someone else's ULA. If ARIN doesn't >> achieve a lower administrative overhead to managing the different IP >> space, then the price should be equal. > > Your /32 presumably is a GUA-PA provider allocation not an GUA-PI > end-user assignment. You presumption is correct. > I believe that the comparison should be between > GUA-PI and ULA-C, not between GUA-PA and ULA-C. Fair enough. > Presumably, a providers > will be making assignments to its customers, which does involve so > additional interaction and cost for ARIN. Which I believe is at least > part of the justification for the different billing models between > providers and end-users, but that is a whole different discussion and > not really a policy matter. Agreed. I understand that financial matters are not relevant in policy discussion, although it seems that throughout certain policy discussions that it has carried weight. The 'fee', although irrelevant to legitimate IP holders, can be the one thing that protects the Internet from the free-loaders. Let the routing-slot holders decide. >> Perhaps IANA should be approached for a 1918 v6. Perhaps I'm out of my >> league ;) > > Essentially, ULA RFC 4193 is the IPv6 replacement for RFC 1918, it > provides for random local assignment within the prefix FD00::/8, it > provides significant statistical uniqueness, but not a guarantee of > uniqueness. Ahhh. I see. > ULA-C (Central) is an expansion of this intended to > guaranteed uniqueness through a centrally registry with assignments made > within the prefix FC00::/8, and reverse DNS delegation should be > available if wanted. Thanks David for your clarification. Although I'm as confused as ever regarding who wants what and why, you've helped me visualize a baseline of what is actually available, which will allow me to get a better understanding within the current discussions. Cheers, Steve From michael.dillon at bt.com Tue Mar 30 04:32:04 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 30 Mar 2010 09:32:04 +0100 Subject: [arin-ppml] GUA vs ULA vs ? In-Reply-To: <4BB14A1D.6030100@ibctech.ca> Message-ID: <28E139F46D45AF49A31950F88C49745805A141B2@E03MVZ2-UKDY.domain1.systemhost.net> > - I'm a bit behind the curve on some of the abbreviations, > but I believe that this is correct: > --- ULA == Unique Local Address > --- GUA == Global Unique Address In this glossary and in several Internet drafts, GUA means Global Unicast Address. The IETF has allocated the range 2000::/3 for use as Global Unicast Addresses. Please let's avoid creating new acronyms that are not absolutely necessary. > If the community decides that ARIN, not IANA, should provide 'private' > space, it should: > > - be from a large block designated as such. RFC 4193 has already designated FC00::/7 for this purpose. > - So that the maintainers of BOGON lists (eg: Team Cymru) can > hold one slot in their filters for all entrants, ensuring > that enough staggered and unpredictable routing breakage will > occur to ensure that serious network engineers/architects > will realize that the `cheap way out' won't work Cymru currently references someone else's IPv6 bogon list here: And it doesn't mention FC00::/7 > Otherwise, the way I see it, is that the cost of my /32 has > the same administrative costs to ARIN as someone else's ULA. That's not true. a) ARIN does not deal with ULA's currently so there is no cost at all, nor is the cost known b) ULA's would have to be handled by a global registry so there is potential for costs to be shared with other RIRs thus making them less than GUA allocations. c) costs and fees are not part of ARIN's policy. They are determined by ARIN members and the Board of Trustees. d) the cost of operating a low volume automated registry is likely to be so low that it is dwarfed by comparison with other ARIN activities. e) I suspect that the main costs of ULA-C will be in maintaining a relationship with the registrants and checking with them once a year to see that they still exist. --Michael Dillon From michael.dillon at bt.com Tue Mar 30 04:55:56 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 30 Mar 2010 09:55:56 +0100 Subject: [arin-ppml] GUA vs ULA vs ? In-Reply-To: <4BB15F64.4030108@umn.edu> Message-ID: <28E139F46D45AF49A31950F88C49745805A14225@E03MVZ2-UKDY.domain1.systemhost.net> > > I am overwhelmed with the number of posts regarding the whole > > 'Non-connected networks', so I'll admit freely that I haven't been > > able to keep up. What on earth are non-connected networks? The very essence of a network is connectivity. This phrase should be erased from our discussions because it is confusing and an oxymoron. > > - I'm a bit behind the curve on some of the abbreviations, but I > > believe that this is correct: > > --- ULA == Unique Local Address > > --- GUA == Global Unique Address > > > > If that is the case, here is how I feel... > > That is how I have been using them and I believe others are > using them to mean that too. A simple Google search would show that the IETF folks use GUA to mean Global Unicast Addresses. The ULA-C addresses that we are discussing would be globally unique addresses but are clearly not GUA because they are not from FC00::/7 > Personally, I'd like to have the IETF define FC00::/8 for > this purpose, and delegate it to IANA to allocate to the RIRs RFC 4193 is very muddy when it comes to laying out how the FC00::/7 addresss are defined. First of all, the FC00 part is hexadecimal, so each letter refers to 4 bits of the address. Given the /7 part, this means that only the F and 3 bits from the C, are fixed. The L bit, which determines whether it is ULA-C or ULA-RANDOM (called ULA-L by IETF folk) is part of that C digit. This means that addresses beginning with FD, are ULA-L (ULA-RANDOM). Addresses beginning with FC are currently in limbo because they are defined by the RFC, but not yet assigned to IANA. So, FD00::/8 are the ULA-L randomly assigned unique unicast addresses intended for local use. And FC00::/8 are indeed the ULA-C addresses that need another RFC in order to instruct IANA to allocate them to RIRs. > for assignment to organizations using process similar to > those used for GUA today and using policies designated by the > RIRs. This risks people doing things like blocking ULA-C addresses from other RIR regions but routing them openly in one region. The current thinking has been to allocate them randomly so that they cannot be aggregated either by network or by region. > > - So that the maintainers of BOGON lists (eg: Team Cymru) > can hold one > Agreed. And, FC00::/7 is already in their BOGON list. Sadly, no. Nor are the old 6bone addresses in their bogon list. Not even SIXXS includes these as bogons. > Your /32 presumably is a GUA-PA provider allocation not an > GUA-PI end-user assignment. Do we really need to change PA and PI to have a GUA prefix? --Michael Dillon From mcr at sandelman.ca Tue Mar 30 10:29:20 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 30 Mar 2010 10:29:20 -0400 Subject: [arin-ppml] GUA vs ULA vs ? In-Reply-To: <28E139F46D45AF49A31950F88C49745805A14225@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745805A14225@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <8733.1269959360@marajade.sandelman.ca> >>>>> "michael" == michael dillon writes: michael> What on earth are non-connected networks? The very essence michael> of a network is connectivity. This phrase should be erased michael> from our discussions because it is confusing and an michael> oxymoron. okay, what do you suggest we call them? Unique-address-space-which-is-not-in-the-worldwide-DFZ-but-might-be-in-some-private-DFZ. is too long to say :-) -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From scottleibrand at gmail.com Tue Mar 30 10:50:15 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 30 Mar 2010 07:50:15 -0700 Subject: [arin-ppml] ULA-C In-Reply-To: <014501cacc77$5573fe00$005bfa00$@net> References: <014501cacc77$5573fe00$005bfa00$@net> Message-ID: <4BB20FA7.1020100@gmail.com> Tony, The draft looks good to me. There is one item that I think might not have consensus here on PPML at least: > The allocation and registration authority ... > must include the ability to make an allocation on a permanent basis, > without any need for renewal. I'd like to hear feedback from other folks on the tradeoff between permanent allocations vs. requiring renewal to maintain whois database consistency... I also noticed you have two IANA Considerations sections (5 and 7). With regards to the IETF process for this draft: is this draft a WG work item yet? Which WG(s) and list(s) will it be discussed on? Thanks, Scott On Thu 3/25/2010 5:00 PM, Tony Hain wrote: > FYI --- > > I will be updating https://datatracker.ietf.org/doc/draft-hain-ipv6-ulac/ > in the next few weeks. Comments welcome. > > Tony > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From cgrundemann at gmail.com Tue Mar 30 10:54:00 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 30 Mar 2010 08:54:00 -0600 Subject: [arin-ppml] GUA vs ULA vs ? In-Reply-To: <8733.1269959360@marajade.sandelman.ca> References: <28E139F46D45AF49A31950F88C49745805A14225@E03MVZ2-UKDY.domain1.systemhost.net> <8733.1269959360@marajade.sandelman.ca> Message-ID: <443de7ad1003300754w68c2f657r6d57b88d516eb432@mail.gmail.com> On Tue, Mar 30, 2010 at 08:29, Michael Richardson wrote: > > >>>>> "michael" == michael dillon writes: > michael> What on earth are non-connected networks? The very essence > michael> of a network is connectivity. This phrase should be erased > michael> from our discussions because it is confusing and an > michael> oxymoron. > > okay, what do you suggest we call them? > > > Unique-address-space-which-is-not-in-the-worldwide-DFZ-but-might-be-in-some-private-DFZ. > > is too long to say :-) > How about GULA -- Globally Unique Local Addressing? ;) ~Chris > > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video > then sign the petition. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Tue Mar 30 11:21:45 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 30 Mar 2010 16:21:45 +0100 Subject: [arin-ppml] GUA vs ULA vs ? In-Reply-To: <8733.1269959360@marajade.sandelman.ca> Message-ID: <28E139F46D45AF49A31950F88C49745805A8B257@E03MVZ2-UKDY.domain1.systemhost.net> > michael> What on earth are non-connected networks? > Unique-address-space-which-is-not-in-the-worldwide-DFZ-but-mig > ht-be-in-some-private-DFZ. My employer runs a global network that has its own DFZ, separate from the Internet DFZ. We use global unicast addresses in IPv4 and I see no reason why we would not continue to do so with IPv6. In particular, the ability of anyone to get a /48 IPv6 PI assignment from ARIN makes it highly likely that we would stick with normal GUA addresses. Our DFZ does not have the same constraints as the public Internet because our DFZ only contains our own routes and those of our paying customers. There are no third parties there. Any other operator of a separate DFZ can do the same and I don't really see that there is a problem to be solved for these networks with a separate DFZ. Certainly no need to concoct a term and an acronym. Some of us have used the term COIN (COmmunity of Interest Network) to refer to this general type of network, but in my opinion even that doesn't need to be in RIR policy. All that we really need from ARIN policy is to continue the recognition recorded in RFC 2050 that IP address allocations are for organizations who use IP networking protocols, not just for the subset which are part of the public Internet. ULA is an entirely different question because it answers the need of millions of organizations worldwide, to have something analogous to RFC 1918 addressing in IPv6. The ULA-L addresses will satisfy some of them, and should be satisfactory for consumer networks, but experience has shown that RFC 1918 addresses would be better if it was possible to prevent address space collisions. Many organizations have used up the entire RFC 1918 address space and now have to have multiple instances of the same network addresses separated by complex NAT processes. Or they have simply merged with another company who happened to be using the same RFC 1918 addressing. Having been burnt, these hundreds of companies and thousands of others who observed the damage, want something like ULA that is guaranteed to be globally unique. Fortunately the IPv6 address space is big, and the creators of ULA-L foresaw the need for this and left the details for later. Later has now arrived, and the IETF is beginning work to wrap-up the ULA-C issue. ARIN will not stop this work. The RIRs will not stop this work. This is a matter between the IETF and its customers, the community of people who use the IP protocol suite. Our job, in an RIR, is to craft a policy that will mesh nicely with what the IETF produces. As part of that we can expect the IETF to make some accomodations for RIR needs, but we cannot expect ULA-C to go away or for the IETF to sanction the RIRs carving out some "special" blocks of GUA addresses. If the RIRs can't agree on this, and the debate gets too acrimonious, then the IETF can, and likely will, create ULA-C anyway, and have IANA run the registry directly. That would be damaging to the RIR community. I hope that we don't let that happen, and I hope that there are enough voices of reason who understand that we are not discussing Internet IP addresses or Internet routes. These are PRIVATE IP addresses and PRIVATE routes which are kept off the Internet by the exact same mechanism that keeps RFC 1918 addresses off the Internet. If necessary, the IETF might even ask IANA to run honeypots for the entire ULA address range, and announce these addresses. Then we would have something better than with RFC 1918; a single /7 prefix which ISPs can filter by default so that no traffic gets routed. And if packets ever do get to a honeypot, and are sourced from FC00::/8, then IANA can contact the registrant, and work with them and their ISP to fix the leak. That is way better than the tons of RFC 1918 packets that currently pummel things like the root nameservers. --Michael Dillon From marla.azinger at frontiercorp.com Tue Mar 30 12:51:38 2010 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Tue, 30 Mar 2010 12:51:38 -0400 Subject: [arin-ppml] ULA-C In-Reply-To: <4BB20FA7.1020100@gmail.com> References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com> Message-ID: <2E2FECEBAE57CC4BAACDE67638305F104852FAD9D9@ROCH-EXCH1.corp.pvt> Correct me if Im wrong Tony but what I recall is this being presented in IPv6 Ops at the IETF 72 in 2008 and it was not accepted into the working group at that time and since then its sat inactive. Marla -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand Sent: Tuesday, March 30, 2010 7:50 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] ULA-C Tony, The draft looks good to me. There is one item that I think might not have consensus here on PPML at least: > The allocation and registration authority ... > must include the ability to make an allocation on a permanent basis, > without any need for renewal. I'd like to hear feedback from other folks on the tradeoff between permanent allocations vs. requiring renewal to maintain whois database consistency... I also noticed you have two IANA Considerations sections (5 and 7). With regards to the IETF process for this draft: is this draft a WG work item yet? Which WG(s) and list(s) will it be discussed on? Thanks, Scott On Thu 3/25/2010 5:00 PM, Tony Hain wrote: > FYI --- > > I will be updating > https://datatracker.ietf.org/doc/draft-hain-ipv6-ulac/ > in the next few weeks. Comments welcome. > > Tony > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From spiffnolee at yahoo.com Tue Mar 30 13:10:20 2010 From: spiffnolee at yahoo.com (Lee Howard) Date: Tue, 30 Mar 2010 10:10:20 -0700 (PDT) Subject: [arin-ppml] GUA vs ULA vs ? In-Reply-To: <28E139F46D45AF49A31950F88C49745805A8B257@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745805A8B257@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <25618.11445.qm@web63301.mail.re1.yahoo.com> ----- Original Message ---- > From: "michael.dillon at bt.com" > Our job, in an RIR, is to craft a policy that will mesh nicely > with what the IETF produces. As part of that we can expect > the IETF to make some accomodations for RIR needs, but we > cannot expect ULA-C to go away or for the IETF to sanction > the RIRs carving out some "special" blocks of GUA addresses. > If the RIRs can't agree on this, and the debate gets too > acrimonious, then the IETF can, and likely will, create ULA-C > anyway, and have IANA run the registry directly. That would > be damaging to the RIR community. I hope that > we don't let that happen, I consider myself a participant in ARIN and IETF, and I think our job is, applying the principles of stewardship, to allocate Internet Protocol resources; develop consensus-based policies; and facilitate the advancement of the Internet through information and educational outreach. It is possible for operators to decide to operate their networks contrary to IETF documents, and to tell ARIN they want something other than what the IETF published. Two examples are the change in HD-Ratio threshold, and documentation of /56 assignments. There's also a constant cry that the IETF needs more participation from operators. If operators here want something different than what the RFCs say, they should join a couple of working group mailing lists and participate. It is not the duty of ARIN participants to make policy that is consistent with IETF product. IMHO; I have not discussed the above with anyone. Lee From narten at us.ibm.com Tue Mar 30 15:07:54 2010 From: narten at us.ibm.com (Thomas Narten) Date: Tue, 30 Mar 2010 15:07:54 -0400 Subject: [arin-ppml] GUA vs ULA vs ? In-Reply-To: <25618.11445.qm@web63301.mail.re1.yahoo.com> References: <28E139F46D45AF49A31950F88C49745805A8B257@E03MVZ2-UKDY.domain1.systemhost.net> <25618.11445.qm@web63301.mail.re1.yahoo.com> Message-ID: <201003301907.o2UJ7sIC026710@cichlid.raleigh.ibm.com> > > From: "michael.dillon at bt.com" > > Our job, in an RIR, is to craft a policy that will mesh nicely > > with what the IETF produces. As part of that we can expect > > the IETF to make some accomodations for RIR needs, but we > > cannot expect ULA-C to go away or for the IETF to sanction > > the RIRs carving out some "special" blocks of GUA addresses. > > If the RIRs can't agree on this, and the debate gets too > > acrimonious, then the IETF can, and likely will, create ULA-C > > anyway, and have IANA run the registry directly. This is nonsense. The IETF, like the RIRs, have had multiple, long and ultimately inconclusive discussions about ULA-C, with no consensus on how to move forward. The ULA-C document died in the IETF some 2 years ago when there wasn't support to move it forward. Tony may be updating that document, but that doesn't mean it will receive a different reception than it has in the past. :-) My sense is that neither the RIR community nor the IETF have had concensus on whether to move ULA-C forward. If something has changed, I'd like to understand what has changed and whether that warrants reopening the discussion based on new or different thinking. What I fear, however, is a repeat of the same long, passionate and inconclusive discussion that has been had several times before. Thomas From farmer at umn.edu Tue Mar 30 16:50:27 2010 From: farmer at umn.edu (David Farmer) Date: Tue, 30 Mar 2010 15:50:27 -0500 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BAD280D.1010706@umn.edu> References: <28E139F46D45AF49A31950F88C4974580599EA8F@E03MVZ2-UKDY.domain1.systemhost.net> <4BACAF24.7060508@umn.edu> <4BACC73C.2030009@umn.edu> <3c3e3fca1003260752s24c542dm3cae37050eb0efe4@mail.gmail.com> <4BAD280D.1010706@umn.edu> Message-ID: <4BB26413.2060201@umn.edu> David Farmer wrote: > William Herrin wrote: >> On Fri, Mar 26, 2010 at 10:39 AM, David Farmer wrote: >>> A ula.nro.net type mechanism is the way to coordinate the creation of >>> the >>> random prefixes. How about something like this. >> >> David, >> >> Something is escaping me here. For *registered* ULA's what's the point >> of randomization? Wouldn't we better served with sparse? Or perhaps >> split the space and do half sparse and the other half linear when the >> requested net count is too large for the largest free space in the >> sparse area? > > I'm not sure it is entirely necessary. But, there is an elegance to > both kinds of ULA using an identical prefix selection algorithm. The > only difference is if the Local/Central is being set or not. Which I > believe was the original intent of how ULA was designed. This would also > underscore the differences between ULA-C and PI addressing. > > Some people have said that ULA-C needed to have a random prefix > selection algorithm too, I don't really care either way. But, if we > allocate large blocks to the RIRs, why not let the RIRs manage the whole > assignment process and just use their normal processes. I don't see any > benefit to allocating large blocks and then requiring the RIRs to use a > random prefix selection algorithm within those blocks. If your going to > have a different prefix selection algorithm, between ULA-C and ULA-L, > why make a third one, just use the RIRs normal one. michael.dillon at bt.com wrote: >David Farmer wrote: >> for assignment to organizations using process similar to >> those used for GUA today and using policies designated by the >> RIRs. > > This risks people doing things like blocking ULA-C addresses > from other RIR regions but routing them openly in one region. > The current thinking has been to allocate them randomly so > that they cannot be aggregated either by network or by region. As I said I'm agnostic on this point, there are a number of people on the list who want large blocks assigned to each RIR, we need to pick one or the other. Who wants to compromise? But their is no point trying to move this forward if we can't find consensus on this point. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From farmer at umn.edu Tue Mar 30 16:53:38 2010 From: farmer at umn.edu (David Farmer) Date: Tue, 30 Mar 2010 15:53:38 -0500 Subject: [arin-ppml] GUA vs ULA vs ? In-Reply-To: <28E139F46D45AF49A31950F88C49745805A14225@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745805A14225@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4BB264D2.5050002@umn.edu> michael.dillon at bt.com wrote: >>> I am overwhelmed with the number of posts regarding the whole >>> 'Non-connected networks', so I'll admit freely that I haven't been >>> able to keep up. > > What on earth are non-connected networks? The very essence of > a network is connectivity. This phrase should be erased from > our discussions because it is confusing and an oxymoron. You are probably right, but I started the conversation with that term because that is what it was called in ARIN's IPv4 policy. Not necessarily a good reason, but a reason. >>> - I'm a bit behind the curve on some of the abbreviations, but I >>> believe that this is correct: >>> --- ULA == Unique Local Address >>> --- GUA == Global Unique Address >>> >>> If that is the case, here is how I feel... >> That is how I have been using them and I believe others are >> using them to mean that too. > > A simple Google search would show that the IETF folks > use GUA to mean Global Unicast Addresses. > The ULA-C addresses that we are discussing would be > globally unique addresses but are clearly not GUA > because they are not from FC00::/7 Sorry, I'd swear that said "Global Unicast Address" when I read it, but you are correct. >> Personally, I'd like to have the IETF define FC00::/8 for >> this purpose, and delegate it to IANA to allocate to the RIRs > > RFC 4193 is very muddy when it comes to laying out how the > FC00::/7 addresss are defined. First of all, the FC00 part > is hexadecimal, so each letter refers to 4 bits of the > address. Given the /7 part, this means that only the F and > 3 bits from the C, are fixed. The L bit, which determines > whether it is ULA-C or ULA-RANDOM (called ULA-L by IETF folk) > is part of that C digit. This means that addresses beginning > with FD, are ULA-L (ULA-RANDOM). Addresses beginning with > FC are currently in limbo because they are defined by the > RFC, but not yet assigned to IANA. > > So, FD00::/8 are the ULA-L randomly assigned unique unicast > addresses intended for local use. > > And FC00::/8 are indeed the ULA-C addresses that need another > RFC in order to instruct IANA to allocate them to RIRs. > >> for assignment to organizations using process similar to >> those used for GUA today and using policies designated by the >> RIRs. > > This risks people doing things like blocking ULA-C addresses > from other RIR regions but routing them openly in one region. > The current thinking has been to allocate them randomly so > that they cannot be aggregated either by network or by region. See, my other post; >>> - So that the maintainers of BOGON lists (eg: Team Cymru) >> can hold one >> Agreed. And, FC00::/7 is already in their BOGON list. > > Sadly, no. Nor are the old 6bone addresses in their bogon list. > Not even SIXXS includes > these as bogons. I'll admit I didn't look that closely, but when I Googled it (Cymru ipv6) I got the following; http://www.cymru.com/Bogons/ipv6.txt FC00::/7 is listed under 3-1-1-1-2 for ingress packet filter and 3-1-2-1-2 ingress prefix filter. You are right that they don't have the old 6Bone in the filter though. >> Your /32 presumably is a GUA-PA provider allocation not an >> GUA-PI end-user assignment. > > Do we really need to change PA and PI to have a GUA prefix? No, write me up a definitive style sheet for PPML post and I'll follow it. :) > --Michael Dillon > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From farmer at umn.edu Tue Mar 30 16:54:44 2010 From: farmer at umn.edu (David Farmer) Date: Tue, 30 Mar 2010 15:54:44 -0500 Subject: [arin-ppml] GUA vs ULA vs ? In-Reply-To: <4BB168B9.2050205@ibctech.ca> References: <4BB14A1D.6030100@ibctech.ca> <4BB15F64.4030108@umn.edu> <4BB168B9.2050205@ibctech.ca> Message-ID: <4BB26514.7010309@umn.edu> Steve Bertrand wrote: > On 2010.03.29 22:18, David Farmer wrote: >> Steve Bertrand wrote: ... >>> Perhaps IANA should be approached for a 1918 v6. Perhaps I'm out of my >>> league ;) >> Essentially, ULA RFC 4193 is the IPv6 replacement for RFC 1918, it >> provides for random local assignment within the prefix FD00::/8, it >> provides significant statistical uniqueness, but not a guarantee of >> uniqueness. > > Ahhh. I see. > >> ULA-C (Central) is an expansion of this intended to >> guaranteed uniqueness through a centrally registry with assignments made >> within the prefix FC00::/8, and reverse DNS delegation should be >> available if wanted. I should have added that ULA-C is not currently defined in any RFC, the whole prefix FC00::/7 is defined for ULA in RFC 4193, but FC00:/8 is technically reserved, only FD00::/8 has been defined so far. There have been a number drafts looking to define centrally assigned ULA (ULA-C), the most current one is at the following URL; http://tools.ietf.org/html/draft-hain-ipv6-ulac-01 -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From cgrundemann at gmail.com Tue Mar 30 17:25:49 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 30 Mar 2010 15:25:49 -0600 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <4BB26413.2060201@umn.edu> References: <28E139F46D45AF49A31950F88C4974580599EA8F@E03MVZ2-UKDY.domain1.systemhost.net> <4BACAF24.7060508@umn.edu> <4BACC73C.2030009@umn.edu> <3c3e3fca1003260752s24c542dm3cae37050eb0efe4@mail.gmail.com> <4BAD280D.1010706@umn.edu> <4BB26413.2060201@umn.edu> Message-ID: <443de7ad1003301425l2b9840a0h80e993c0d0e45d05@mail.gmail.com> On Tue, Mar 30, 2010 at 14:50, David Farmer wrote: > David Farmer wrote: > >> William Herrin wrote: >> >>> On Fri, Mar 26, 2010 at 10:39 AM, David Farmer wrote: >>> >>>> A ula.nro.net type mechanism is the way to coordinate the creation of >>>> the >>>> random prefixes. How about something like this. >>>> >>> >>> David, >>> >>> Something is escaping me here. For *registered* ULA's what's the point >>> of randomization? Wouldn't we better served with sparse? Or perhaps >>> split the space and do half sparse and the other half linear when the >>> requested net count is too large for the largest free space in the >>> sparse area? >>> >> >> I'm not sure it is entirely necessary. But, there is an elegance to both >> kinds of ULA using an identical prefix selection algorithm. The only >> difference is if the Local/Central is being set or not. Which I believe was >> the original intent of how ULA was designed. This would also underscore the >> differences between ULA-C and PI addressing. >> >> Some people have said that ULA-C needed to have a random prefix selection >> algorithm too, I don't really care either way. But, if we allocate large >> blocks to the RIRs, why not let the RIRs manage the whole assignment process >> and just use their normal processes. I don't see any benefit to allocating >> large blocks and then requiring the RIRs to use a random prefix selection >> algorithm within those blocks. If your going to have a different prefix >> selection algorithm, between ULA-C and ULA-L, why make a third one, just use >> the RIRs normal one. >> > > michael.dillon at bt.com wrote: > >David Farmer wrote: > >> for assignment to organizations using process similar to > >> those used for GUA today and using policies designated by the > >> RIRs. > > > > This risks people doing things like blocking ULA-C addresses > > from other RIR regions but routing them openly in one region. > > The current thinking has been to allocate them randomly so > > that they cannot be aggregated either by network or by region. > > As I said I'm agnostic on this point, there are a number of people on the > list who want large blocks assigned to each RIR, we need to pick one or the > other. Who wants to compromise? But their is no point trying to move this > forward if we can't find consensus on this point. Allocating them randomly (no regional blocks) will further discourage their use as cheap-GUA-equivalents at any point in the future as it causes the most pain to do so. Therefor, this is the best course of action if we want ULA-C. This is of course slightly more complicated than handing out regional blocks since it requires a truly central registry (as opposed to the five distinct registries for GUA, ASNs and IPv4) but I think that can be overcome without too much difficulty. There are three possibilities: 1) IANA takes on the duty directly 2) IANA delegates the duty to an existing RIR (or group of RIRs) 3) IANA/ICANN create a new ULA-C registry In any case, the assignee interface should remain at the current RIR level, keeping the new duties to the bare minimum required to guarantee uniqueness (a prefix generator and a directory). ~Chris > > > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at ibctech.ca Tue Mar 30 19:50:11 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 30 Mar 2010 19:50:11 -0400 Subject: [arin-ppml] GUA vs ULA vs ? In-Reply-To: <4BB264D2.5050002@umn.edu> References: <28E139F46D45AF49A31950F88C49745805A14225@E03MVZ2-UKDY.domain1.systemhost.net> <4BB264D2.5050002@umn.edu> Message-ID: <4BB28E33.2030009@ibctech.ca> On 2010.03.30 16:53, David Farmer wrote: > michael.dillon at bt.com wrote: >>> Personally, I'd like to have the IETF define FC00::/8 for this >>> purpose, and delegate it to IANA to allocate to the RIRs >> >> RFC 4193 is very muddy when it comes to laying out how the >> FC00::/7 addresss are defined. First of all, the FC00 part >> is hexadecimal, so each letter refers to 4 bits of the address. Given >> the /7 part, this means that only the F and >> 3 bits from the C, are fixed. The L bit, which determines >> whether it is ULA-C or ULA-RANDOM (called ULA-L by IETF folk) >> is part of that C digit. This means that addresses beginning >> with FD, are ULA-L (ULA-RANDOM). Addresses beginning with >> FC are currently in limbo because they are defined by the >> RFC, but not yet assigned to IANA. >> >> So, FD00::/8 are the ULA-L randomly assigned unique unicast >> addresses intended for local use. >> >> And FC00::/8 are indeed the ULA-C addresses that need another >> RFC in order to instruct IANA to allocate them to RIRs. My understanding from what I've been reading today is that ULA-C has a split audience that goes well beyond the scope of our ARIN RIR discussion. It seems as though there is no consensus on this matter on any level. I hope that my perception is correct regarding this issue. >> Sadly, no. Nor are the old 6bone addresses in their bogon list. >> Not even SIXXS includes >> these as bogons. > > I'll admit I didn't look that closely, but when I Googled it (Cymru > ipv6) I got the following; > > http://www.cymru.com/Bogons/ipv6.txt > > FC00::/7 is listed under 3-1-1-1-2 for ingress packet filter and > 3-1-2-1-2 ingress prefix filter. You are right that they don't have the > old 6Bone in the filter though. Does this not cover it? (search for 3000::/4): http://www.cymru.com/Documents/fullbogon-ipv6.txt Also, I am extremely confident that it won't be long before these addresses appear in Team Cymru BGP IPv6 BOGON feeds. From what I can tell, 3000::/4 covers the 6Bone space (x:x:1::ffff is my null route), hence, I learn this: rtbh-trig2#sh ipv6 route 3ffe::1 IPv6 Routing Table - 20696 entries B 3000::/4 [20/0] via 2607:F118:1::FFFF >>> Your /32 presumably is a GUA-PA provider allocation not an GUA-PI >>> end-user assignment. >> >> Do we really need to change PA and PI to have a GUA prefix? > > No, write me up a definitive style sheet for PPML post and I'll follow > it. :) Is there at least a consensus on _why_ there is no consensus? Does it boil down to the potential abuse of connecting a non-connected block? Steve From steve at ibctech.ca Tue Mar 30 20:21:31 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 30 Mar 2010 20:21:31 -0400 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <443de7ad1003301425l2b9840a0h80e993c0d0e45d05@mail.gmail.com> References: <28E139F46D45AF49A31950F88C4974580599EA8F@E03MVZ2-UKDY.domain1.systemhost.net> <4BACAF24.7060508@umn.edu> <4BACC73C.2030009@umn.edu> <3c3e3fca1003260752s24c542dm3cae37050eb0efe4@mail.gmail.com> <4BAD280D.1010706@umn.edu> <4BB26413.2060201@umn.edu> <443de7ad1003301425l2b9840a0h80e993c0d0e45d05@mail.gmail.com> Message-ID: <4BB2958B.1060607@ibctech.ca> On 2010.03.30 17:25, Chris Grundemann wrote: > > > On Tue, Mar 30, 2010 at 14:50, David Farmer > wrote: > > David Farmer wrote: > > William Herrin wrote: > > On Fri, Mar 26, 2010 at 10:39 AM, David Farmer > > wrote: > > A ula.nro.net type mechanism is the > way to coordinate the creation of the > random prefixes. How about something like this. > > > David, > > Something is escaping me here. For *registered* ULA's what's > the point > of randomization? Wouldn't we better served with sparse? Or > perhaps > split the space and do half sparse and the other half linear > when the > requested net count is too large for the largest free space > in the > sparse area? > > > I'm not sure it is entirely necessary. But, there is an > elegance to both kinds of ULA using an identical prefix > selection algorithm. The only difference is if the Local/Central > is being set or not. Which I believe was the original intent of > how ULA was designed. This would also underscore the differences > between ULA-C and PI addressing. > > Some people have said that ULA-C needed to have a random prefix > selection algorithm too, I don't really care either way. But, > if we allocate large blocks to the RIRs, why not let the RIRs > manage the whole assignment process and just use their normal > processes. I don't see any benefit to allocating large blocks > and then requiring the RIRs to use a random prefix selection > algorithm within those blocks. If your going to have a > different prefix selection algorithm, between ULA-C and ULA-L, > why make a third one, just use the RIRs normal one. > > > michael.dillon at bt.com wrote: > >David Farmer wrote: > >> for assignment to organizations using process similar to > >> those used for GUA today and using policies designated by the > >> RIRs. > > > > This risks people doing things like blocking ULA-C addresses > > from other RIR regions but routing them openly in one region. > > The current thinking has been to allocate them randomly so > > that they cannot be aggregated either by network or by region. > > As I said I'm agnostic on this point, there are a number of people > on the list who want large blocks assigned to each RIR, we need to > pick one or the other. Who wants to compromise? But their is no > point trying to move this forward if we can't find consensus on this > point. > > > Allocating them randomly (no regional blocks) will further discourage > their use as cheap-GUA-equivalents at any point in the future as it > causes the most pain to do so. Therefor, this is the best course of > action if we want ULA-C. > > This is of course slightly more complicated than handing out regional > blocks since it requires a truly central registry (as opposed to the > five distinct registries for GUA, ASNs and IPv4) but I think that can be > overcome without too much difficulty. There are three possibilities: > 1) IANA takes on the duty directly > 2) IANA delegates the duty to an existing RIR (or group of RIRs) > 3) IANA/ICANN create a new ULA-C registry > > In any case, the assignee interface should remain at the current RIR > level, keeping the new duties to the bare minimum required to guarantee > uniqueness (a prefix generator and a directory). When ULA-C does succeed, my preference would be to have each RIR manage this space for itself, so policy decisions can be made in the same fashion by the same people who create the policy for the rest of the regional space. Although I don't follow too closely or participate, I belong to the RIPE addr pol group. I like some of the things that they are doing, but there are some things that make me happy to be in the ARIN region. I can't even fathom the policy/discussion nightmare if there was only one central, global authority. I think that IANA should designate a very large single block for ULA-C, divide it up, and allocate this space to each RIR, keeping at least 33% reserved in the event new RIRs pop up. Administratively, an RIR should be able to utilize their existing infrastructure to manage this space in a separate but similar matter, and operationally, it would allow engineers/ops to make filtering decisions for ULA-C based on global, regional, or Joe's network. I don't have a problem whatsoever if Mike's net wants to slot in Joe's ULA-C, or if I want to allow a route to connect a couple of mutual clients that are a few blocks away from each other. I do have a problem if the entire ULA-C space is not aggregate-able into one (or a small number) of prefixes. Also, if filtering/classification is easy, then I also don't have any problem with ARIN charging lessor fees then PA/PI, so long as the lessor cost is directly relevant to the time savings they (ARIN) achieve if less overhead administrative and/or management work is required. Each to their own. From my (relatively limited) experience in S&M enterprise I can see the desire for ULA-C, particularly from the standpoint of networks that _require_ *true* division and separation. >From the SP side of things, I'd rather just see CPE get fixed in order to eliminate NAT ;) Steve From farmer at umn.edu Tue Mar 30 20:36:06 2010 From: farmer at umn.edu (David Farmer) Date: Tue, 30 Mar 2010 19:36:06 -0500 Subject: [arin-ppml] GUA vs ULA vs ? In-Reply-To: <201003301907.o2UJ7sIC026710@cichlid.raleigh.ibm.com> References: <28E139F46D45AF49A31950F88C49745805A8B257@E03MVZ2-UKDY.domain1.systemhost.net> <25618.11445.qm@web63301.mail.re1.yahoo.com> <201003301907.o2UJ7sIC026710@cichlid.raleigh.ibm.com> Message-ID: <4BB298F6.6000305@umn.edu> Thomas Narten wrote: > I'd like to understand what has changed and whether that warrants > reopening the discussion based on new or different thinking. What I > fear, however, is a repeat of the same long, passionate and > inconclusive discussion that has been had several times before. > > Thomas What has changed? Well, people are starting to take seriously implementing IPv6, including some end-users. See ARIN's own statistics; https://www.arin.net/knowledge/statistics/historical.html https://www.arin.net/knowledge/statistics/index.html Furthermore, we have a PI policy such that ULA-C shouldn't end up being an end around to get PI. At least, if the RIR's have control of the policy for assignment of ULA-C, with an expectation that they would be similar if not identical to PI the policies. Which I'm starting to hear some consensus for, at least on PPML, we might not be there yet, but I think we are getting close. Are these enough to make the difference this time? I don't know. There are a number of legitimate uses for ULA-C, for which providing guaranteed uniqueness and reverse DNS provides an operational advantage over ULA-R (A.K.A. ULA-L). VPNs - whatever the technology, IPSec, MPLS, L2TP, ETC... Private Networks - things you don't ever want talking to the Internet Compliance - point-haired boss repellent! Right or wrong a lot of enterprise architecture is based on the concept of private addressing, security, load-balancing, etc... If we want people to move to IPv6, taking away their security blankets (their warm fuzzy blankies) is not a good way to get them to embrace the change. This is not about technology it is about human psychology. If as a network person I want to implement IPv6 I need to get buy-in from a lot of other people. And yes, people want to do NAT66 too, so what, this is really irrelevant. They can do NAT66 with ULA-L now. How is allowing them to do NAT66 with guaranteed uniqueness and reverse DNS going to make it any worse? In fact it might make it better, PI NAT66ed to ULA-C looks a lot like Identifier/Locator split, at least to me, not there yet and hopefully it would only be a step toward that evolution. :) I'll provide some specific uses I have for ULA-C here at the University of Minnesota; We have a number of MPLS VPNs on our campus network for things such as security cameras, door access control and monitoring, building SCADA systems, point of sale systems (including vending machines) with PCI requirements. Beyond these internal systems, we have a number of special access IPSEC VPNs with a number of business partners over the Internet and some using dedicated access circuits. Our medical school has dedicated GigE circuits to a number of hospitals, can you say HIPPA. Also, we have a police department, that integrates with 911 and all sorts of city, county, state, and federal criminal and emergency response systems, that have the own system designers with security dictates. I'll tell you when the Secret Service shows up and says they want this done that way, what I have to say doesn't hold much weight. So, technically we could use PI or even PA for these, but I would need to argue with auditors, security consultants, compliance officers, and not just our own internal ones but with the one from our business partners too. So, if I can tell them we have guaranteed unique private (not routed) addressing there are many political advantages to this. How many meetings arguing over this issue does it take to make what ever an RIR wants to charge for ULA-C to start looking cheep? Not, that I'm suggesting that it should be expensive, but there is value, especially to enterprise network operators, maybe not so much ISPs, but enterprises are your customers. We could use regular ULA-L, but I would rather have guaranteed uniqueness and reverse DNS that ULA-C could give us. This gives us something way better than RFC1918 in IPv4 and I believe will make enterprise network operations easier and generally less expensive. > Cheers, > > Steve If you have arguments against ULA-C please let them be known, I'm open to be convinced that it is a bone-headed idea. I see some utility in ULA-C, and I have no intention of implementing NAT66, or at least I never WANT to, time will only tell, I said the same thing about IPv4 NAT not that long ago, we just started to do some IPv4 NAT last fall. I'm capable of using, GUA and making my own non-routed prefix, filtering a prefix at my border and null routing it in my upstream ISP infrastructure to insure it doesn't leak, etc... (we run our own DFZ ISP, which our campus and a number of other entities are a customer of) Any ISPs out there that are advocating enterprises use GUA for non-routed private addressing are you willing do special filtering and null routing on a customer by customer basis, or would filtering FC00::/7 be easier? -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From owen at delong.com Tue Mar 30 12:06:43 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 30 Mar 2010 09:06:43 -0700 Subject: [arin-ppml] ULA-C In-Reply-To: <4BB20FA7.1020100@gmail.com> References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com> Message-ID: <54827055-3AFB-4510-9592-4B2DD47F3086@delong.com> On Mar 30, 2010, at 7:50 AM, Scott Leibrand wrote: > Tony, > > The draft looks good to me. There is one item that I think might not have consensus here on PPML at least: > >> The allocation and registration authority ... >> must include the ability to make an allocation on a permanent basis, >> without any need for renewal. > > I'd like to hear feedback from other folks on the tradeoff between permanent allocations vs. requiring renewal to maintain whois database consistency... > Permanent bad. Renewal good. Owen From owen at delong.com Mon Mar 29 18:39:00 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 29 Mar 2010 15:39:00 -0700 Subject: [arin-ppml] IPv6 Non-connected networks In-Reply-To: <20100329184906.BAAC42B2128@mx5.roble.com> References: <4BAB9013.3090801@Dilkie.com> <20100326050534.0F7E22B208E@mx5.roble.com> <0244E2C6-51A0-47D8-801C-7B503DE9802A@delong.com> <20100326172924.E3E882B208E@mx5.roble.com> <301F23DD-8385-4D95-8039-0E6C1548A29D@delong.com> <20100326183505.7BDBB2B208E@mx5.roble.com> <9D84746F-3C10-4669-9E57-490DC654133C@delong.com> <3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com> <1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com> <3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com> <20100326205555.D66402B2126@mx5.roble.com> <3C5EE00C-7B9E-4FCE-8903-CF736A687511@delong.com> <20100329184906.BAAC42B2128@mx5.roble.com> Message-ID: <54ACBE6F-332B-4A8F-A6C8-3983F044ECEE@delong.com> On Mar 29, 2010, at 11:49 AM, Roger Marquis wrote: > Owen not-a-security-engineer DeLong wrote: >> Things actually slowing down residential IPv6 deployment: >> + Lack of CPE support >> + Lack of Head-End (PON concentrator, DSLAM, CMTS, etc.) support >> + Lack of support from the ISP > > The same arguments can be made for NAT. NAT stateful translation can be > added to CPE just as easily as IPv6 support can be added to CPE. > Upgrading equipment in COs and in colos is no more difficult either. > True, but, the average residential customer couldn't care less about NAT. In fact, most of the residential customers I know long for the ability to choose their level of accessibility rather than being stuck in a NAT straightjacket. > Citing the lack of CPE support for Torrent, SIP and other protocols as a > reason to leave NAT out of IPv6 is specious. The CPE will still need > stateful translation to provide the same security, and NAT is the > simplist way to do it. > No, it needs stateful inspection, not translation. Owen From steve at ibctech.ca Tue Mar 30 23:20:38 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 30 Mar 2010 23:20:38 -0400 Subject: [arin-ppml] ULA-C In-Reply-To: <54827055-3AFB-4510-9592-4B2DD47F3086@delong.com> References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com> <54827055-3AFB-4510-9592-4B2DD47F3086@delong.com> Message-ID: <4BB2BF86.8000000@ibctech.ca> On 2010.03.30 12:06, Owen DeLong wrote: > > On Mar 30, 2010, at 7:50 AM, Scott Leibrand wrote: > >> Tony, >> >> The draft looks good to me. There is one item that I think might not have consensus here on PPML at least: >> >>> The allocation and registration authority ... >>> must include the ability to make an allocation on a permanent basis, >>> without any need for renewal. >> >> I'd like to hear feedback from other folks on the tradeoff between permanent allocations vs. requiring renewal to maintain whois database consistency... >> > Permanent bad. Renewal good. I support. Not much thought has to go into Owen's comment to know that it is in the best interest of everyone, especially for the long term. Steve From michael.dillon at bt.com Wed Mar 31 06:24:20 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 31 Mar 2010 11:24:20 +0100 Subject: [arin-ppml] GUA vs ULA vs ? In-Reply-To: <4BB264D2.5050002@umn.edu> Message-ID: <28E139F46D45AF49A31950F88C49745805A8B67B@E03MVZ2-UKDY.domain1.systemhost.net> >> What on earth are non-connected networks? The very essence of a >> network is connectivity. This phrase should be erased from our >> discussions because it is confusing and an oxymoron. > You are probably right, but I started the conversation with that term because that > is what it was called in ARIN's IPv4 policy. Not necessarily a good reason, but a > reason. I just looked around and discovered this in RFC 2050: All other requestors should contact its ISP for address space or utilize the addresses reserved for non-connected networks described in RFC1918... It comes after 3 a) which is the justification that I have often quoted in reference to COINs like SITA, RADIANZ and the auto industry. Section 4.3.5 seems to echo the RFC 2050 wording but I fear that some people are interpreting this to also include networks which do not announce prefixes into the DFZ of the public Internet. I think that DFZ issues are entirely separate from the question of non-connectedness. And in IPv6, I think that because of the vast supply of addresses, there should really be no issue in treating COIN users just like public Internet users and allocating them PA and PI space. > > The ULA-C addresses that we are discussing would be globally unique > > addresses but are clearly not GUA because they are not from FC00::/7 That should say "not from 2000://3" > Sorry, I'd swear that said "Global Unicast Address" when I > read it, but you are correct. GUA = 2000://3 The addresses that RIR's allocate as PA and PI ULA = FC00://7 RFC 4193 ULA-L = FD00::/8 AKA ULA-RANDOM ULA-C = FC00::/8 currently in limbo with IETF > No, write me up a definitive style sheet for PPML post and > I'll follow it. :) You could trim the quotes a bit more, but in general your posts are easy to follow. --Michael Dillon From michael.dillon at bt.com Wed Mar 31 06:35:38 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 31 Mar 2010 11:35:38 +0100 Subject: [arin-ppml] GUA vs ULA vs ? In-Reply-To: <4BB26514.7010309@umn.edu> Message-ID: <28E139F46D45AF49A31950F88C49745805A8B6A4@E03MVZ2-UKDY.domain1.systemhost.net> > I should have added that ULA-C is not currently defined in > any RFC, the whole prefix FC00::/7 is defined for ULA in RFC > 4193, but FC00:/8 is technically reserved, only FD00::/8 has > been defined so far. There have been a number drafts looking > to define centrally assigned ULA (ULA-C), the most current > one is at the following URL; > > http://tools.ietf.org/html/draft-hain-ipv6-ulac-01 Other drafts on the topic are: I think that we should try to get a draft that incorporates much of the discussion on ARIN-PPML and either have someone co-author with Tony Hain, or submit it separately. Seems to me that the 6MAN WG is the place to carry on the discussion. --Michael Dillon From cengel at sponsordirect.com Wed Mar 31 10:55:47 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Wed, 31 Mar 2010 10:55:47 -0400 Subject: [arin-ppml] The role of NAT in IPv6 In-Reply-To: Message-ID: Owen Delong wrote: > Actually, the places that most need to deploy IPv6 at this > point being eye-ball ISPs and the public-facing portions of > content and services providers, I don't think that NAT has > been an actual barrier to adoption in either of those spaces. > The vast majority of people calling for NAT66 are the > enterprise interior, which is, IMHO, the least critical and > least likely group to get on the IPv6 bandwagon quickly > regardless of what is done to appease them. Well, in addition to being an Enterprise...my company is also an ASP.... which I believe would qualify as a "content and services provider" under your definition. So lets see, if I want to deploy IPv6 currently.... - Huge transition costs - No support for tools I rely on every day to make MY environment work the way I want it. - Out of compliance with current regulatory standards. Gee Whiz... where do I get to sign up for that? Christopher Engel From kkargel at polartel.com Wed Mar 31 12:46:31 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 31 Mar 2010 11:46:31 -0500 Subject: [arin-ppml] GUA vs ULA vs ? In-Reply-To: <4BB298F6.6000305@umn.edu> References: <28E139F46D45AF49A31950F88C49745805A8B257@E03MVZ2-UKDY.domain1.systemhost.net> <25618.11445.qm@web63301.mail.re1.yahoo.com> <201003301907.o2UJ7sIC026710@cichlid.raleigh.ibm.com> <4BB298F6.6000305@umn.edu> Message-ID: <8695009A81378E48879980039EEDAD28876D43D0@MAIL1.polartel.local> > Any ISPs out there that are advocating enterprises use GUA for > non-routed private addressing are you willing do special filtering and > null routing on a customer by customer basis, or would filtering > FC00::/7 be easier? > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services This is actually my plan at this point, when the situation arises, as well as what I have done in my personal IPv6 network. I do not find it to be onerous, and it works. I believe it will be easier than tracking multiple networks would be. I have had a major rethink concerning IPv6 ULA.. my very argument that everyone will have plenty of space to use GUA for private networks also supports there being plenty of space to allow ULA without cramping the world. I am slowly sliding over to the camp that says "If we can afford the space and people want to use ULA and it doesn't hurt anyone else then why not..". Whether I personally feel it is efficient or utile is moot. My current predominate feeling is that ULA of whatever flavor would be fine so long as the requirements and costs are on par with GUA to remove the rationale for abuse. The appropriate costs for GUA are an entirely different discussion. Kevin From kkargel at polartel.com Wed Mar 31 12:49:12 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 31 Mar 2010 11:49:12 -0500 Subject: [arin-ppml] ULA-C In-Reply-To: <4BB2BF86.8000000@ibctech.ca> References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com> <54827055-3AFB-4510-9592-4B2DD47F3086@delong.com> <4BB2BF86.8000000@ibctech.ca> Message-ID: <8695009A81378E48879980039EEDAD28876D43D1@MAIL1.polartel.local> > >> > >> I'd like to hear feedback from other folks on the tradeoff between > permanent allocations vs. requiring renewal to maintain whois database > consistency... > >> > > Permanent bad. Renewal good. > > I support. > > Not much thought has to go into Owen's comment to know that it is in the > best interest of everyone, especially for the long term. > > Steve > _______________________________________________ I concur that renewal is necessary, though renewal requirements do not necessarily need to include money, data refresh could be sufficient. Kevin From owen at delong.com Wed Mar 31 14:13:48 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 31 Mar 2010 11:13:48 -0700 Subject: [arin-ppml] ULA-C In-Reply-To: <8695009A81378E48879980039EEDAD28876D43D1@MAIL1.polartel.local> References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com> <54827055-3AFB-4510-9592-4B2DD47F3086@delong.com> <4BB2BF86.8000000@ibctech.ca> <8695009A81378E48879980039EEDAD28876D43D1@MAIL1.polartel.local> Message-ID: <68D14357-C52A-4790-A14E-5026D37A495F@delong.com> On Mar 31, 2010, at 9:49 AM, Kevin Kargel wrote: > >>>> >>>> I'd like to hear feedback from other folks on the tradeoff between >> permanent allocations vs. requiring renewal to maintain whois database >> consistency... >>>> >>> Permanent bad. Renewal good. >> >> I support. >> >> Not much thought has to go into Owen's comment to know that it is in the >> best interest of everyone, especially for the long term. >> >> Steve >> _______________________________________________ > > I concur that renewal is necessary, though renewal requirements do not necessarily need to include money, data refresh could be sufficient. > > Kevin I disagree. Without fees, data-refresh is often responded to out of rote without thought or consideration. Owen From JOHN at egh.com Wed Mar 31 20:04:31 2010 From: JOHN at egh.com (John Santos) Date: Wed, 31 Mar 2010 20:04:31 -0400 Subject: [arin-ppml] ULA-C In-Reply-To: <68D14357-C52A-4790-A14E-5026D37A495F@delong.com> Message-ID: <1100331195006.45147B-100000@Ives.egh.com> On Wed, 31 Mar 2010, Owen DeLong wrote: > > On Mar 31, 2010, at 9:49 AM, Kevin Kargel wrote: > > > > >>>> > >>>> I'd like to hear feedback from other folks on the tradeoff between > >> permanent allocations vs. requiring renewal to maintain whois database > >> consistency... > >>>> > >>> Permanent bad. Renewal good. > >> > >> I support. > >> > >> Not much thought has to go into Owen's comment to know that it is in the > >> best interest of everyone, especially for the long term. > >> > >> Steve > >> _______________________________________________ > > > > I concur that renewal is necessary, though renewal requirements do not > > necessarily need to include money, data refresh could be sufficient. > > > > Kevin > > I disagree. Without fees, data-refresh is often responded to out of > rote without thought or consideration. But isn't the fact that it is responded to at all significant? I.E., email to a dead address won't be responded to. And even a valid, correct response could become obsolete the next day when the POCs arrive at their offices and discover their jobs have been outsourced and the PHBs are clueless. :-( It's not perfect, but it's better than nothing, so I don't think in and of it self, this is a major argument for fees or against ULA-C. Aren't fees supposed to just cover expenses, which I think would be pretty minimal for ULA-C, in the same ballpark as domain registration fees, (which are often charged for a 5 or 10 year period to reduce overhead)? And my last question, are we even allowed to talk about this on this list? :-) > > Owen > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From fred at cisco.com Wed Mar 31 20:16:29 2010 From: fred at cisco.com (Fred Baker) Date: Wed, 31 Mar 2010 17:16:29 -0700 Subject: [arin-ppml] ULA-C In-Reply-To: <54827055-3AFB-4510-9592-4B2DD47F3086@delong.com> References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com> <54827055-3AFB-4510-9592-4B2DD47F3086@delong.com> Message-ID: Dumb question. The complaint with ULAs as presently formulated is that there is a non-zero probability of them colliding. If you give a prefix to your favorite admin and have them number their network with it, and then re-assign the prefix to someone else, what's the probability that you have a collision? I think you need to accept that once put into use, a ULA will be in use by that administration permanently. You obviously see otherwise. Fill me in? On Mar 30, 2010, at 9:06 AM, Owen DeLong wrote: > > On Mar 30, 2010, at 7:50 AM, Scott Leibrand wrote: > >> Tony, >> >> The draft looks good to me. There is one item that I think might not have consensus here on PPML at least: >> >>> The allocation and registration authority ... >>> must include the ability to make an allocation on a permanent basis, >>> without any need for renewal. >> >> I'd like to hear feedback from other folks on the tradeoff between permanent allocations vs. requiring renewal to maintain whois database consistency... >> > Permanent bad. Renewal good. > > Owen > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. http://www.ipinc.net/IPv4.GIF From cgrundemann at gmail.com Wed Mar 31 20:40:46 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 31 Mar 2010 18:40:46 -0600 Subject: [arin-ppml] ULA-C In-Reply-To: References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com> <54827055-3AFB-4510-9592-4B2DD47F3086@delong.com> Message-ID: Organisations are not permanent. If the administration using the prefix goes away then shouldn't the prefix be reclaimed? Also, isn't it at least some what possible that the need for a prefix go away? Should that organisation be forced to keep an uneeded prefix, especially when others likely do need it? ~Chris My Android sent this message - hence the top post. On Mar 31, 2010 6:17 PM, "Fred Baker" wrote: Dumb question. The complaint with ULAs as presently formulated is that there is a non-zero probability of them colliding. If you give a prefix to your favorite admin and have them number their network with it, and then re-assign the prefix to someone else, what's the probability that you have a collision? I think you need to accept that once put into use, a ULA will be in use by that administration permanently. You obviously see otherwise. Fill me in? On Mar 30, 2010, at 9:06 AM, Owen DeLong wrote: > > On Mar 30, 2010, at 7:50 AM, Scott Leibrand w... http://www.ipinc.net/IPv4.GIF _______________________________________________ PPML You are receiving this message because you are... -------------- next part -------------- An HTML attachment was scrubbed... URL: From fred at cisco.com Wed Mar 31 20:46:21 2010 From: fred at cisco.com (Fred Baker) Date: Wed, 31 Mar 2010 17:46:21 -0700 Subject: [arin-ppml] ULA-C In-Reply-To: <4BB3E8F4.2010403@gmail.com> References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com> <54827055-3AFB-4510-9592-4B2DD47F3086@delong.com> <4BB3E8F4.2010403@gmail.com> Message-ID: <4BE237E0-147E-4F48-883E-052A2136898B@cisco.com> well, question. Do you need whois and all that for a local address? We don't use them for RFC 1918 addresses... If they were global addresses, I'd be right there with you. But a ULA is used by your favorite IT department and is not normally shared with very many other organizations. It seems like the response to "whois" should be "your IT department". On the other hand, I could imagine an allocation "policy" that consists of a web page (not my idea originally, it comes from Brian Carpenter). The web page has some variation on a counter, perhaps using a pseudo-random number generator or a cyclic feedback shift register to spread the numbers all over. When a site accesses the web page, they get a prefix, and the next person that accesses the web page gets the "next" prefix. Next question is who runs the web page; could be IANA, your favorite RIR, or anyone else the community deemed suitable. Along with that, I could imagine the person allocating the prefix having to provide some information, and some checks and balances to limit the probability of issues. The checks and balances would require discussion. They might include a name, address, and email address. On Mar 31, 2010, at 5:29 PM, Scott Leibrand wrote: > On Wed 3/31/2010 5:16 PM, Fred Baker wrote: >> Dumb question. >> >> The complaint with ULAs as presently formulated is that there is a non-zero probability of them colliding. >> >> If you give a prefix to your favorite admin and have them number their network with it, and then re-assign the prefix to someone else, what's the probability that you have a collision? >> >> I think you need to accept that once put into use, a ULA will be in use by that administration permanently. You obviously see otherwise. Fill me in? >> > > You're right, it doesn't make any sense to reassign a block once it's been assigned. However, the question of whether to maintain, remove, or mark stale contacts in whois, and/or whether to maintain or remove rDNS from companies who've disappeared, is not so straightforward, IMO. > > Do you have any opinions on what to do there? > > Thanks, > Scott http://www.ipinc.net/IPv4.GIF From fred at cisco.com Wed Mar 31 20:48:15 2010 From: fred at cisco.com (Fred Baker) Date: Wed, 31 Mar 2010 17:48:15 -0700 Subject: [arin-ppml] ULA-C In-Reply-To: References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com> <54827055-3AFB-4510-9592-4B2DD47F3086@delong.com> Message-ID: <4E376686-1540-433A-BC0B-26D1F5445D09@cisco.com> On Mar 31, 2010, at 5:40 PM, Chris Grundemann wrote: > Organisations are not permanent. If the administration using the prefix goes away then shouldn't the prefix be reclaimed? Also, isn't it at least some what possible that the need for a prefix go away? Should that organisation be forced to keep an uneeded prefix, especially when others likely do need it? well, you didn't answer my question, so maybe I shouldn't have to answer yours :-) I have no problem with your statement in principle. I'm just wondering how you enforce it. > ~Chris > > My Android sent this message - hence the top post. > > >> On Mar 31, 2010 6:17 PM, "Fred Baker" wrote: >> >> Dumb question. >> >> The complaint with ULAs as presently formulated is that there is a non-zero probability of them colliding. >> >> If you give a prefix to your favorite admin and have them number their network with it, and then re-assign the prefix to someone else, what's the probability that you have a collision? >> >> I think you need to accept that once put into use, a ULA will be in use by that administration permanently. You obviously see otherwise. Fill me in? >> On Mar 30, 2010, at 9:06 AM, Owen DeLong wrote: > > On Mar 30, 2010, at 7:50 AM, Scott Leibrand w... >> >> http://www.ipinc.net/IPv4.GIF >> _______________________________________________ PPML You are receiving this message because you are... >> > http://www.ipinc.net/IPv4.GIF From scottleibrand at gmail.com Wed Mar 31 20:50:03 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 31 Mar 2010 17:50:03 -0700 Subject: [arin-ppml] ULA-C In-Reply-To: <4BE237E0-147E-4F48-883E-052A2136898B@cisco.com> References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com> <54827055-3AFB-4510-9592-4B2DD47F3086@delong.com> <4BB3E8F4.2010403@gmail.com> <4BE237E0-147E-4F48-883E-052A2136898B@cisco.com> Message-ID: <4BB3EDBB.7080704@gmail.com> Well, it seems that one of the main advantages of ULA-C over ULA-L is (optional) reverse DNS. If you're going to have that, it seems you should have some sort of (basic) whois info, with most of the information optional. (Maybe require name, address, and e-mail, like you suggested.) If we're gonna have a central database (as opposed to just recording "that one's taken"), then it seems we have to try to keep it up to date somehow... -Scott On Wed 3/31/2010 5:46 PM, Fred Baker wrote: > well, question. Do you need whois and all that for a local address? We don't use them for RFC 1918 addresses... > > If they were global addresses, I'd be right there with you. But a ULA is used by your favorite IT department and is not normally shared with very many other organizations. It seems like the response to "whois" should be "your IT department". > > On the other hand, I could imagine an allocation "policy" that consists of a web page (not my idea originally, it comes from Brian Carpenter). The web page has some variation on a counter, perhaps using a pseudo-random number generator or a cyclic feedback shift register to spread the numbers all over. When a site accesses the web page, they get a prefix, and the next person that accesses the web page gets the "next" prefix. Next question is who runs the web page; could be IANA, your favorite RIR, or anyone else the community deemed suitable. Along with that, I could imagine the person allocating the prefix having to provide some information, and some checks and balances to limit the probability of issues. The checks and balances would require discussion. They might include a name, address, and email address. > > On Mar 31, 2010, at 5:29 PM, Scott Leibrand wrote: > > >> On Wed 3/31/2010 5:16 PM, Fred Baker wrote: >> >>> Dumb question. >>> >>> The complaint with ULAs as presently formulated is that there is a non-zero probability of them colliding. >>> >>> If you give a prefix to your favorite admin and have them number their network with it, and then re-assign the prefix to someone else, what's the probability that you have a collision? >>> >>> I think you need to accept that once put into use, a ULA will be in use by that administration permanently. You obviously see otherwise. Fill me in? >>> >>> >> You're right, it doesn't make any sense to reassign a block once it's been assigned. However, the question of whether to maintain, remove, or mark stale contacts in whois, and/or whether to maintain or remove rDNS from companies who've disappeared, is not so straightforward, IMO. >> >> Do you have any opinions on what to do there? >> >> Thanks, >> Scott >> > http://www.ipinc.net/IPv4.GIF > > From scottleibrand at gmail.com Wed Mar 31 20:29:40 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 31 Mar 2010 17:29:40 -0700 Subject: [arin-ppml] ULA-C In-Reply-To: References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com> <54827055-3AFB-4510-9592-4B2DD47F3086@delong.com> Message-ID: <4BB3E8F4.2010403@gmail.com> On Wed 3/31/2010 5:16 PM, Fred Baker wrote: > Dumb question. > > The complaint with ULAs as presently formulated is that there is a non-zero probability of them colliding. > > If you give a prefix to your favorite admin and have them number their network with it, and then re-assign the prefix to someone else, what's the probability that you have a collision? > > I think you need to accept that once put into use, a ULA will be in use by that administration permanently. You obviously see otherwise. Fill me in? > You're right, it doesn't make any sense to reassign a block once it's been assigned. However, the question of whether to maintain, remove, or mark stale contacts in whois, and/or whether to maintain or remove rDNS from companies who've disappeared, is not so straightforward, IMO. Do you have any opinions on what to do there? Thanks, Scott From farmer at umn.edu Wed Mar 31 21:16:47 2010 From: farmer at umn.edu (David Farmer) Date: Wed, 31 Mar 2010 20:16:47 -0500 Subject: [arin-ppml] ULA-C In-Reply-To: References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com> <54827055-3AFB-4510-9592-4B2DD47F3086@delong.com> Message-ID: <4BB3F3FF.6060801@umn.edu> Fred Baker wrote: > Dumb question. > > The complaint with ULAs as presently formulated is that there is a non-zero probability of them colliding. > > If you give a prefix to your favorite admin and have them number their network with it, and then re-assign the prefix to someone else, what's the probability that you have a collision? > > I think you need to accept that once put into use, a ULA will be in use by that administration permanently. You obviously see otherwise. Fill me in? Permanent; - continuing or enduring without marked change in status or condition or place; - not capable of being reversed or returned to the original condition; This may be an issue of semantics. Your argument holds for GUA too. The University of Minnesota has had 128.101.0.0/16 since 1986. For most practical purposes all allocations or assignments made by an RIR are at least semi-permanent. But the community has taken the stance that GUA assignments or allocations are not permanent, so I believe we should take that same stance for centrally assigned ULA. If you wish to use the word permanent when referring to GUA assignments, then using it for ULA would be appropriate. I believe there is a consensus building at least here on PPML that ULA-C and PI should be thought of from a policy sense as identical, other than ULA-C is by convention not routed. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From fred at cisco.com Wed Mar 31 21:29:53 2010 From: fred at cisco.com (Fred Baker) Date: Wed, 31 Mar 2010 18:29:53 -0700 Subject: [arin-ppml] ULA-C In-Reply-To: <4BB3F3FF.6060801@umn.edu> References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com> <54827055-3AFB-4510-9592-4B2DD47F3086@delong.com> <4BB3F3FF.6060801@umn.edu> Message-ID: <97CE9A51-CA70-40BD-8B1C-0BD23CC22BBF@cisco.com> On Mar 31, 2010, at 6:16 PM, David Farmer wrote: > I believe there is a consensus building at least here on PPML that ULA-C and PI should be thought of from a policy sense as identical, other than ULA-C is by convention not routed. ULA-L and ULA-C should not cross administrative boundaries without the administration's express consent. I'm all for that; ULAs become the basis for a GSE world. GSE means that the edge networks have prefixes that give them reasonable multihoming and the appearance (independence, relative simplicity, multihoming, etc) of PI while the ISPs experience the impact on their tables of PA. In addition, any device on the net can address a packet to any other device on the net, unlike today's NAT world; one uses security and routing solutions to fix that, rather than being delude by the marketing of NAT as a security solution. There are of course some issues, which one hopes folks would be smart enough to use ILNP to get around. http://www.ipinc.net/IPv4.GIF From cgrundemann at gmail.com Wed Mar 31 23:51:16 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 31 Mar 2010 21:51:16 -0600 Subject: [arin-ppml] ULA-C In-Reply-To: <4E376686-1540-433A-BC0B-26D1F5445D09@cisco.com> References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com> <54827055-3AFB-4510-9592-4B2DD47F3086@delong.com> <4E376686-1540-433A-BC0B-26D1F5445D09@cisco.com> Message-ID: On Wed, Mar 31, 2010 at 18:48, Fred Baker wrote: > well, you didn't answer my question, so maybe I shouldn't have to answer yours :-) Fair enough - answer below. =) > I have no problem with your statement in principle. I'm just wondering how you enforce it. Annual renewal required of the registrant and annual registrant-data-verification required of the registry (whois poc verification or equivalent). Or, in the case of ULA-C, perhaps pentennial renewal and verification would be adequate and appropriate. ...Or maybe annual for those blocks which the registry is providing reverse DNS and pentennial for those with no service beyond basic registration. > >> On Mar 31, 2010 6:17 PM, "Fred Baker" queried: > >> If you give a prefix to your favorite admin and have them number their network with it, and then re-assign the prefix to someone else, what's the probability that you have a collision? Much greater than if you don't re-assign it. ;-) > >> I think you need to accept that once put into use, a ULA will be in use by that administration permanently. You obviously see otherwise. ?Fill me in? See my previous statements regarding the impermanence of organizations and their networks. ~Chris -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org