From bmanning at vacation.karoshi.com Thu Mar 9 17:06:08 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 9 Mar 2006 22:06:08 +0000 Subject: [ppml] for your reading pleasure Message-ID: <20060309220608.GA13246@vacation.karoshi.com.> draft-narten-ipv6-3177bis-48boundary-01.txt in you internetdrafts archive... posted today. --bill From tme at multicasttech.com Thu Mar 9 21:53:21 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 9 Mar 2006 21:53:21 -0500 Subject: [ppml] for your reading pleasure In-Reply-To: <20060309220608.GA13246@vacation.karoshi.com.> References: <20060309220608.GA13246@vacation.karoshi.com.> Message-ID: <67F964B5-5998-47FB-B6B2-B7A6D3475492@multicasttech.com> Do you know if this document is aimed at an IETF working group, and if so, which one, or is it intended for independent RFC Editor publication ? Regards Marshall On Mar 9, 2006, at 5:06 PM, bmanning at vacation.karoshi.com wrote: > > draft-narten-ipv6-3177bis-48boundary-01.txt > > in you internetdrafts archive... posted today. > > --bill > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From narten at us.ibm.com Thu Mar 9 22:13:19 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 09 Mar 2006 22:13:19 -0500 Subject: [ppml] for your reading pleasure In-Reply-To: Message from Marshall Eubanks of "Thu, 09 Mar 2006 21:53:21 EST." <67F964B5-5998-47FB-B6B2-B7A6D3475492@multicasttech.com> Message-ID: <200603100313.k2A3DJf5015334@cichlid.raleigh.ibm.com> > Do you know if this document is aimed at an IETF working group, and > if so, which one, or is it intended for independent RFC Editor > publication ? IPv6 WG. It's aimed at the IETF. From the document: > Abstract > > RFC 3177 argued that in IPv6, end sites should be assigned /48 > blocks in most cases. The Regional Internet Registries (RIRs) > adopted those recommendations in 2002 and they have been in effect > ever since. This document revisits and updates the IAB/IESG > recommendations on the assignment of IPv6 address space to end > sites. The exact choice of how much address space to assign end > sites is a policy issue under the purview of the RIRs, subject to > IPv6 architectural considerations. This document reviews those > architectural considerations and reiterates that changing the /48 > recommendation is one of policy, and has minimal impact on the IPv6 > architecture and on IETF Standards. > > This document obsoletes RFC 3177 and reclassifies it as historic. The previous version had a lot of text attempting to motivate the need for moving from /48 to something smaller (i.e., to conserve address space). All of that text is now gone, and the real focus of this document is to update/replace RFC 3177. Thomas From Michael.Dillon at btradianz.com Fri Mar 10 04:41:46 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 10 Mar 2006 09:41:46 +0000 Subject: [ppml] for your reading pleasure In-Reply-To: <20060309220608.GA13246@vacation.karoshi.com.> Message-ID: > draft-narten-ipv6-3177bis-48boundary-01.txt > > in you internetdrafts archive... posted today. For those who do not understand the IETF secret handshake, this document can be found at the following URL. http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-01.txt It is an update of RFC 3177 so you really should google for that RFC and read it before you read this draft. People working on new routing/multihoming models should also take an interest in this RFC because of the statement: RFC3177 suggested that some multihoming approaches (e.g., GSE) might benefit from having a fixed /48 boundary. This no longer appears to be a significant issue. There is no such requirement coming out of the IETF multi6 or shim6 efforts. The reference to GSE is to an early proposal that separated the IPv6 address into a routing identifier and an end-system designator. Cynical people might see this as an IETF attempt to block the efforts of people working on new routing/multihoming models. --Michael Dillon From narten at us.ibm.com Fri Mar 10 10:01:31 2006 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 10 Mar 2006 10:01:31 -0500 Subject: [ppml] for your reading pleasure In-Reply-To: Message from Michael.Dillon@btradianz.com of "Fri, 10 Mar 2006 09:41:46 GMT." Message-ID: <200603101501.k2AF1Vge026686@cichlid.raleigh.ibm.com> > > draft-narten-ipv6-3177bis-48boundary-01.txt > > > > in you internetdrafts archive... posted today. > For those who do not understand the IETF secret handshake, > this document can be found at the following URL. > http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-01.txt Sorry, I should have included the full URL as well. > It is an update of RFC 3177 so you really should google > for that RFC and read it before you read this draft. > People working on new routing/multihoming models should > also take an interest in this RFC because of the statement: > RFC3177 suggested that some multihoming approaches (e.g., GSE) might > benefit from having a fixed /48 boundary. This no longer appears to > be a significant issue. There is no such requirement coming out of > the IETF multi6 or shim6 efforts. > The reference to GSE is to an early proposal that separated > the IPv6 address into a routing identifier and an end-system > designator. yep. > Cynical people might see this as an IETF attempt to block > the efforts of people working on new routing/multihoming > models. And others might view your comment as FUD. As an author, I state categorically that there is absolutely no attempt being made here to slow down or halt any ongoing work related to new routing or multihoming models. I too want to see a solution to the multihoming problem. The quoted statement you are having issue is a fact, AFAIK. If you believe the wording is in error, please explain and perhaps propose alternate text. That is, do you think the /48 boundary _does_ need to be retained, in order to support on-going work related to multihoming? Again, please be specific. Thomas From tme at multicasttech.com Fri Mar 10 10:21:29 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 10 Mar 2006 10:21:29 -0500 Subject: [ppml] for your reading pleasure In-Reply-To: References: Message-ID: <8B2FED9A-FDD7-4FC2-8113-132085D0C477@multicasttech.com> I must admit that I do not see much in the way of recommendations in this document, nor do I see a strong need for it. It says that This document revisits and updates the IAB/IESG recommendations on the assignment of IPv6 address space to end sites. but it would be more appropriate to say that it voids them. It does imply that smaller address blocks could be handed out - see this from the Introduction 1) It revisits the RFC 3177 recommendations and concludes that the default IPv6 assignment size could be changed from /48 to some other value (e.g., /56) with essentially no impact on existing IPv6 standards or implementations. and this from Section 2 The above concerns were met by the original /48 recommendation, but could also be realized through a more conservative approach. A key goal, however, is to avoid the need for a site to renumber into a smaller number of subnet bits when adding a new prefix. but of course the same wording could be used to justify automatically handing out larger blocks are well. Particularly, it provides no reason why /56's (or / 32's, or /64's, or any other size block) should be handed out in preference to any other size. No doubt that there is no _technical_ reason why address blocks need to be any particular size (after all, IPv4 CIDR works), but just stating that, while useful, is not actually a recommendation do to anything in particular. I am surprised that the draft does not even promote aggregation in assignment policies. Note this at the end of Section 2, where it says A key goal, however, is to avoid the need for a site to renumber into a smaller number of subnet bits when adding a new prefix. As I read it, this implies that RIR's should (or, at least, could) hand out non-contiguous blocks when end sites need more address space. It seems to approve of this, as long as the new block is the same size or larger than the existing ones. I think that the minimum any IPv6 assignment policy should do is to promote the maximum amount of aggregation possible, and that any recommendation coming out of the IETF / IESG / IAB should clearly state that as a goal. Regards Marshall On Mar 10, 2006, at 4:41 AM, Michael.Dillon at btradianz.com wrote: >> draft-narten-ipv6-3177bis-48boundary-01.txt >> >> in you internetdrafts archive... posted today. > > For those who do not understand the IETF secret handshake, > this document can be found at the following URL. > http://www.ietf.org/internet-drafts/draft-narten- > ipv6-3177bis-48boundary-01.txt > > It is an update of RFC 3177 so you really should google > for that RFC and read it before you read this draft. > People working on new routing/multihoming models should > also take an interest in this RFC because of the statement: > > RFC3177 suggested that some multihoming approaches (e.g., GSE) > might > benefit from having a fixed /48 boundary. This no longer appears to > be a significant issue. There is no such requirement coming out of > the IETF multi6 or shim6 efforts. > > The reference to GSE is to an early proposal that separated > the IPv6 address into a routing identifier and an end-system > designator. > > Cynical people might see this as an IETF attempt to block > the efforts of people working on new routing/multihoming > models. > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From narten at us.ibm.com Fri Mar 10 10:44:24 2006 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 10 Mar 2006 10:44:24 -0500 Subject: [ppml] for your reading pleasure In-Reply-To: Message from Marshall Eubanks of "Fri, 10 Mar 2006 10:21:29 EST." <8B2FED9A-FDD7-4FC2-8113-132085D0C477@multicasttech.com> Message-ID: <200603101544.k2AFiOBL027609@cichlid.raleigh.ibm.com> Marshall Eubanks writes: > I must admit that I do not see much in the way of recommendations in > this document, nor do I see a strong need for it. One need is to make clear that 3177 has been superceded, and that folk should stop pointing to it for justification of things. Note that in the past, at some RIR meetings, people have made reference to 3177 and wondered if it was appropriate to change the /48 policy given the existance of 3177. Also, it's useful to the IETF community to have it go through the formal steps of recognizing that 3177 needs to be updated/replaced. So, I agree, maybe not hugely important, but I view this is part of closing the loop and recognizing where we are today. > It says that > This document revisits and updates the IAB/IESG recommendations on > the assignment of IPv6 address space to end sites. > but it would be more appropriate to say that it voids them. It does > imply that smaller address blocks could be handed out - see this > from the Introduction > 1) It revisits the RFC 3177 recommendations and concludes that the > default IPv6 assignment size could be changed from /48 to some > other value (e.g., /56) with essentially no impact on existing > IPv6 standards or implementations. > and this from Section 2 > The above concerns were met by the original /48 recommendation, but > could also be realized through a more conservative approach. A key > goal, however, is to avoid the need for a site to renumber into a > smaller number of subnet bits when adding a new prefix. Right. > but of course the same wording could be used to justify > automatically handing out larger blocks are well. Particularly, it > provides no reason why /56's (or / 32's, or /64's, or any other size > block) should be handed out in preference to any other size. I'll have to think about this a bit and see if some text should be added. There are lots of things this document doesn't rule out, by virtue of not saying something explicit. :-) But it probably is useful to say something more specific on your point. > No doubt that there is no _technical_ reason why address blocks need > to be any particular size (after all, IPv4 CIDR works), but just > stating that, while useful, is not actually a recommendation do to > anything in particular. To be clear, this document is not intended to make a recommendation on what the RIRs should do. But it does want to make clear that updating/changing the current /48 recommendation is reasonable, from an architectural/standards perspective. > I am surprised that the draft does not even promote aggregation in > assignment policies. > Note this at the end of Section 2, where it says > A key goal, however, is to avoid the need for a site to renumber > into a smaller number of subnet bits when adding a new prefix. > As I read it, this implies that RIR's should (or, at least, could) > hand out non-contiguous blocks when end sites need more address > space. It seems to approve of this, as long as the new block is the > same size or larger than the existing ones. Not clear this document should say anything here (though of course we support better aggregation). But in the specific case of end sites, it's not immediately clear they need to aggregate the same way as we want ISP customers (as a whole) to be aggregated. For example, giving an end site 3 different (non-aggregatable) prefixes that the ISP flat routes internally, but that are still covered by an ISP's overall aggregate would seem like a fine think to do. Or in any case, I don't think this should be ruled out. > I think that the minimum any IPv6 assignment policy should do is to > promote the maximum amount of aggregation possible, and that any > recommendation coming out of the IETF / IESG / IAB should clearly > state that as a goal. I don't disagree with the point, but that isn't really in scope with what I had in mind when writing the document. Thomas From randy at psg.com Fri Mar 10 13:03:05 2006 From: randy at psg.com (Randy Bush) Date: Fri, 10 Mar 2006 08:03:05 -1000 Subject: [ppml] for your reading pleasure References: <8B2FED9A-FDD7-4FC2-8113-132085D0C477@multicasttech.com> <200603101544.k2AFiOBL027609@cichlid.raleigh.ibm.com> Message-ID: <17425.48985.714740.306465@roam.psg.com> >> I must admit that I do not see much in the way of recommendations in >> this document, nor do I see a strong need for it. > One need is to make clear that 3177 has been superceded, and that folk > should stop pointing to it for justification of things. Note that in > the past, at some RIR meetings, people have made reference to 3177 and > wondered if it was appropriate to change the /48 policy given the > existance of 3177. Also, it's useful to the IETF community to have it > go through the formal steps of recognizing that 3177 needs to be > updated/replaced. thank you for that > To be clear, this document is not intended to make a recommendation on > what the RIRs should do. But it does want to make clear that > updating/changing the current /48 recommendation is reasonable, from > an architectural/standards perspective. same thank you! randy From owen at delong.com Fri Mar 10 16:08:41 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Mar 2006 13:08:41 -0800 Subject: [ppml] for your reading pleasure In-Reply-To: <8B2FED9A-FDD7-4FC2-8113-132085D0C477@multicasttech.com> References: <8B2FED9A-FDD7-4FC2-8113-132085D0C477@multicasttech.com> Message-ID: > I am surprised that the draft does not even promote aggregation in > assignment policies. > Note this at the end of Section 2, where it says > > A key goal, however, is to avoid the need for a site to renumber > into a > smaller number of subnet bits when adding a new prefix. > > As I read it, this implies that RIR's should (or, at least, could) > hand out non-contiguous blocks > when end sites need more address space. It seems to approve of this, > as long as the new block is the same size or larger than the existing > ones. > I believe the intent there, instead, is to encourage RIRs to hand out large enough blocks or do sparse enough allocations that a non-contiguous block is not necessary. > I think that the minimum any IPv6 assignment policy should do is to > promote the maximum amount of aggregation possible, and that any > recommendation coming out of the IETF / IESG / IAB should clearly > state that as a goal. > Yes, but, it should, where possible, attempt to do so without requiring sites to renumber. Another key provision of this draft which I think is somewhat important (albeit unlikely to have much real world effect) is that it provides formal recognition that address assignment policy is an RIR public policy issue and not an IETF design or IAB architecture issue. The RIRs will make address allocation policy, and, if necessary will ignore IETF overreaching in this area. I think it is better if the RFCs provide recognition of this reality and do not overreach. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From christopher.morrow at gmail.com Sat Mar 11 01:35:53 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Sat, 11 Mar 2006 06:35:53 +0000 Subject: [ppml] for your reading pleasure In-Reply-To: References: <8B2FED9A-FDD7-4FC2-8113-132085D0C477@multicasttech.com> Message-ID: <75cb24520603102235t71848fe6k448f91db1df21e2e@mail.gmail.com> On 3/10/06, Owen DeLong wrote: > > I think that the minimum any IPv6 assignment policy should do is to > > promote the maximum amount of aggregation possible, and that any > > recommendation coming out of the IETF / IESG / IAB should clearly > > state that as a goal. > > > Yes, but, it should, where possible, attempt to do so without requiring > sites to renumber. > but I thought renumbeing was a non-issue with v6... so why would the IETF include that wording? From randy at psg.com Sat Mar 11 01:49:11 2006 From: randy at psg.com (Randy Bush) Date: Fri, 10 Mar 2006 20:49:11 -1000 Subject: [ppml] for your reading pleasure In-Reply-To: <75cb24520603102235t71848fe6k448f91db1df21e2e@mail.gmail.com> References: <8B2FED9A-FDD7-4FC2-8113-132085D0C477@multicasttech.com> <75cb24520603102235t71848fe6k448f91db1df21e2e@mail.gmail.com> Message-ID: <441272E7.5040104@psg.com> > but I thought renumbeing was a non-issue with v6... so why would the > IETF include that wording? let's be optimistic, and view it as clue absorption and a teensie sign of progress. thomas gets it. he even managed to sell a teensie bit of it to the ivtf v6sionaries. buy the guy a cuppa, he must have given blood. randy From lea.roberts at stanford.edu Sat Mar 11 03:34:09 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Sat, 11 Mar 2006 00:34:09 -0800 (PST) Subject: [ppml] a modified proposal 2005-8 In-Reply-To: <441272E7.5040104@psg.com> Message-ID: was just sent in to ARIN... for your additional reading pleasure. /Lea Policy Proposal 2005-8, version 2: Proposal to amend ARIN IPv6 assignment and utilisation requirement This proposal would amend the IPv6 address allocation policies (ARIN's NRPM, section 6) regarding the definition of the default size of End Site assignments and the threshold value for End Site allocation efficiency, no longer assuming the fixed values for End Site assignments established by RFC3177. Many references to "/48" will need to be replaced by "End Site assignment". for example, section 6.5.4.1 should be replaced as follows: 6.5.4.1. Assignment address space size End Users are assigned an End Site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the End Site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): - /64 when it is known that one and only one subnet is needed - /56 for small sites, those expected to need only a few subnets over the next 5 years. - /48 for larger sites For end sites to whom DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to allow to simplify reverse lookup delegation. RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns. Accordingly, RIRs/NIRs will not request the detailed information on IPv6 user networks as they did in IPv4, except for the cases described in Section 6.4.4 and for the purposes of measuring utilization as defined in this document. also, section 6.9 will need to be replaced: 6.9. IPv6 Reassignments policy The size of IPv6 address assignments to End Sites is to be determined by the ISP/LIR. ISPs and LIRs may choose whether to make changes to their procedures for assigning address blocks to End Sites. The threshold End Site allocation efficiency level is between 20% to 50% for most ISPs and LIRs when based on a 0.94 HD Ratio. ISPs and LIRs will need to operate address plans according to this target level of End Site allocation efficiency. there's a need to change ARIN NRPM IPv6 Utilization: The ARIN NRPM Section 6.7 will be amended so its IPv6 allocation utilization criteria will reflect the use of a /56 as the unit quantity in the calculation of the ISP or LIR's end site allocation efficiency. Rationale: The current IPv6 Address Allocation and Assignment Policy (section 6 of ARIN's NRPM) indicates that end sites should be allocated a /48 as a uniform allocation unit if using more than one host or one subnet. This proposal alters the existing policy regarding LIR and ISP assignments to End Sites to allow the unit of assignment to be an LIR or ISP decision. In assessing the address utilization efficiency for ISPs or LIRs, the definition of an End Site for the purposes of the calculation of ISP or LIR End Site allocation efficiency, is to be made according to a /56 size. This measure, if undertaken generally by all RIRs, in conjunction with the further measures undertaken by the addressing community regarding increasing the HD ratio to 0.94, would increase the anticipated useful lifetime of IPv6 to encompass a period in excess of 100 years, in which case no further allocation policy changes would be anticipated. A more detailed rationale is available in Geoff Huston's presentation on the subject, at RIPE 50, which can be found at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv6-roundtable-report.pdf ------------------------------------------------------------------------ Appendix A. References This material is not formally part of the Policy Proposal. It is included here for informational purposes. 1. The IPv6 Address Plan - Geoff Huston http://www.potaroo.net/ispcol/2005-07/ipv6size.html 2. Internet Draft: Issues Related to the Management of IPv6 Address Space - Thomas Narten http://tools.ietf.org/wg/ipv6/draft-narten-iana-rir-ipv6-considerations-00.txt [unfortunately, the ID expired, so use the URL: http://www.cs.duke.edu/~narten/ietf/draft-narten-iana-rir-ipv6-considerations-00.txt] 3. Internet Draft: IPv6 Address Allocation to End Sites - Thomas Narten, Geoff Huston & Lea Roberts http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-01.txt From owen at delong.com Sat Mar 11 14:43:22 2006 From: owen at delong.com (Owen DeLong) Date: Sat, 11 Mar 2006 11:43:22 -0800 Subject: [ppml] for your reading pleasure In-Reply-To: <75cb24520603102235t71848fe6k448f91db1df21e2e@mail.gmail.com> References: <8B2FED9A-FDD7-4FC2-8113-132085D0C477@multicasttech.com> <75cb24520603102235t71848fe6k448f91db1df21e2e@mail.gmail.com> Message-ID: <1E69DDF67E25223B9015CF1F@odpwrbook.hq.netli.lan> --On March 11, 2006 6:35:53 AM +0000 Christopher Morrow wrote: > On 3/10/06, Owen DeLong wrote: >> > I think that the minimum any IPv6 assignment policy should do is to >> > promote the maximum amount of aggregation possible, and that any >> > recommendation coming out of the IETF / IESG / IAB should clearly >> > state that as a goal. >> > >> Yes, but, it should, where possible, attempt to do so without requiring >> sites to renumber. >> > > but I thought renumbeing was a non-issue with v6... so why would the > IETF include that wording? That provision was removed from the kool-aid formulation in IPv6 some time ago. Current IPv6 offers little more than the original TUBA proposal. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From terry.l.davis at boeing.com Sat Mar 11 15:56:37 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Sat, 11 Mar 2006 12:56:37 -0800 Subject: [ppml] a modified proposal 2005-8 In-Reply-To: Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BCC7@XCH-NW-8V1.nw.nos.boeing.com> Lea The proposal is fine. But I am actually hard pressed to imagine a single entity site that will have only a single local subnet under an IP-v6 architecture. I tend to believe that IP-v6 architectures will be very different from our traditional IP-v4 concepts. My power, entertain, City, and communications company will probably allocate me one each from there individual spaces but I still think I will several of my own as I do today. Take care Terry -----Original Message----- From: Lea Roberts [mailto:lea.roberts at stanford.edu] Sent: Saturday, March 11, 2006 12:34 AM To: ppml at arin.net Subject: [ppml] a modified proposal 2005-8 was just sent in to ARIN... for your additional reading pleasure. /Lea Policy Proposal 2005-8, version 2: Proposal to amend ARIN IPv6 assignment and utilisation requirement This proposal would amend the IPv6 address allocation policies (ARIN's NRPM, section 6) regarding the definition of the default size of End Site assignments and the threshold value for End Site allocation efficiency, no longer assuming the fixed values for End Site assignments established by RFC3177. Many references to "/48" will need to be replaced by "End Site assignment". for example, section 6.5.4.1 should be replaced as follows: 6.5.4.1. Assignment address space size End Users are assigned an End Site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the End Site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): - /64 when it is known that one and only one subnet is needed - /56 for small sites, those expected to need only a few subnets over the next 5 years. - /48 for larger sites For end sites to whom DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to allow to simplify reverse lookup delegation. RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns. Accordingly, RIRs/NIRs will not request the detailed information on IPv6 user networks as they did in IPv4, except for the cases described in Section 6.4.4 and for the purposes of measuring utilization as defined in this document. also, section 6.9 will need to be replaced: 6.9. IPv6 Reassignments policy The size of IPv6 address assignments to End Sites is to be determined by the ISP/LIR. ISPs and LIRs may choose whether to make changes to their procedures for assigning address blocks to End Sites. The threshold End Site allocation efficiency level is between 20% to 50% for most ISPs and LIRs when based on a 0.94 HD Ratio. ISPs and LIRs will need to operate address plans according to this target level of End Site allocation efficiency. there's a need to change ARIN NRPM IPv6 Utilization: The ARIN NRPM Section 6.7 will be amended so its IPv6 allocation utilization criteria will reflect the use of a /56 as the unit quantity in the calculation of the ISP or LIR's end site allocation efficiency. Rationale: The current IPv6 Address Allocation and Assignment Policy (section 6 of ARIN's NRPM) indicates that end sites should be allocated a /48 as a uniform allocation unit if using more than one host or one subnet. This proposal alters the existing policy regarding LIR and ISP assignments to End Sites to allow the unit of assignment to be an LIR or ISP decision. In assessing the address utilization efficiency for ISPs or LIRs, the definition of an End Site for the purposes of the calculation of ISP or LIR End Site allocation efficiency, is to be made according to a /56 size. This measure, if undertaken generally by all RIRs, in conjunction with the further measures undertaken by the addressing community regarding increasing the HD ratio to 0.94, would increase the anticipated useful lifetime of IPv6 to encompass a period in excess of 100 years, in which case no further allocation policy changes would be anticipated. A more detailed rationale is available in Geoff Huston's presentation on the subject, at RIPE 50, which can be found at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-w ed-ipv6-roundtable-report.pdf ------------------------------------------------------------------------ Appendix A. References This material is not formally part of the Policy Proposal. It is included here for informational purposes. 1. The IPv6 Address Plan - Geoff Huston http://www.potaroo.net/ispcol/2005-07/ipv6size.html 2. Internet Draft: Issues Related to the Management of IPv6 Address Space - Thomas Narten http://tools.ietf.org/wg/ipv6/draft-narten-iana-rir-ipv6-considerations- 00.txt [unfortunately, the ID expired, so use the URL: http://www.cs.duke.edu/~narten/ietf/draft-narten-iana-rir-ipv6-considera tions-00.txt] 3. Internet Draft: IPv6 Address Allocation to End Sites - Thomas Narten, Geoff Huston & Lea Roberts http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary -01.txt _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From lea.roberts at stanford.edu Sat Mar 11 17:08:19 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Sat, 11 Mar 2006 14:08:19 -0800 (PST) Subject: [ppml] a modified proposal 2005-8 In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BCC7@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: thanks for the comment, Terry! I certainly agree with you... and that's one reason why I would like to see the option for multiple subnet assignments other than /48! /Lea On Sat, 11 Mar 2006, Davis, Terry L wrote: > Lea > > The proposal is fine. > > But I am actually hard pressed to imagine a single entity site that will > have only a single local subnet under an IP-v6 architecture. I tend to > believe that IP-v6 architectures will be very different from our > traditional IP-v4 concepts. > > My power, entertain, City, and communications company will probably > allocate me one each from there individual spaces but I still think I > will several of my own as I do today. > > Take care > Terry > > -----Original Message----- > From: Lea Roberts [mailto:lea.roberts at stanford.edu] > Sent: Saturday, March 11, 2006 12:34 AM > To: ppml at arin.net > Subject: [ppml] a modified proposal 2005-8 > > was just sent in to ARIN... for your additional reading pleasure. /Lea > > Policy Proposal 2005-8, version 2: > > Proposal to amend ARIN IPv6 assignment and utilisation requirement > > This proposal would amend the IPv6 address allocation policies (ARIN's > NRPM, section 6) regarding the definition of the default size of End > Site assignments and the threshold value for End Site allocation > efficiency, no longer assuming the fixed values for End Site > assignments established by RFC3177. Many references to "/48" will > need to be replaced by "End Site assignment". > > for example, section 6.5.4.1 should be replaced as follows: > > 6.5.4.1. Assignment address space size > > End Users are assigned an End Site assignment from their LIR or > ISP. The exact size of the assignment is a local decision for the > LIR or ISP to make, using a minimum value of a /64 (when only one > subnet is anticipated for the End Site) up to the normal maximum > of /48, except in cases of extra large end sites where a larger > assignment can be justified. > > The following guidelines may be useful (but they are only > guidelines): > > - /64 when it is known that one and only one subnet is needed > > - /56 for small sites, those expected to need only a few subnets > over the next 5 years. > > - /48 for larger sites > > For end sites to whom DNS will be delegated, the LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to allow > to simplify reverse lookup delegation. > > RIRs/NIRs are not concerned about which address size an LIR/ISP > actually assigns. Accordingly, RIRs/NIRs will not request the > detailed information on IPv6 user networks as they did in IPv4, > except for the cases described in Section 6.4.4 and for the > purposes of measuring utilization as defined in this document. > > also, section 6.9 will need to be replaced: > > 6.9. IPv6 Reassignments policy > > The size of IPv6 address assignments to End Sites is to be > determined by the ISP/LIR. > > ISPs and LIRs may choose whether to make changes to their > procedures for assigning address blocks to End Sites. The threshold > End Site allocation efficiency level is between 20% to 50% for most > ISPs and LIRs when based on a 0.94 HD Ratio. ISPs and LIRs will > need to operate address plans according to this target level of End > Site allocation efficiency. > > > there's a need to change ARIN NRPM IPv6 Utilization: > > The ARIN NRPM Section 6.7 will be amended so its IPv6 allocation > utilization criteria will reflect the use of a /56 as the unit > quantity in the calculation of the ISP or LIR's end site allocation > efficiency. > > Rationale: > > The current IPv6 Address Allocation and Assignment Policy (section 6 > of ARIN's NRPM) indicates that end sites should be allocated a /48 as > a uniform allocation unit if using more than one host or one subnet. > > This proposal alters the existing policy regarding LIR and ISP > assignments to End Sites to allow the unit of assignment to be an LIR > or ISP decision. > > In assessing the address utilization efficiency for ISPs or LIRs, the > definition of an End Site for the purposes of the calculation of ISP > or LIR End Site allocation efficiency, is to be made according to a /56 > size. > > This measure, if undertaken generally by all RIRs, in conjunction with > the further measures undertaken by the addressing community regarding > increasing the HD ratio to 0.94, would increase the anticipated useful > lifetime of IPv6 to encompass a period in excess of 100 years, in > which case no further allocation policy changes would be anticipated. > > > A more detailed rationale is available in Geoff Huston's presentation on > the subject, at RIPE 50, which can be found at: > http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-w > ed-ipv6-roundtable-report.pdf > > > > ------------------------------------------------------------------------ > > Appendix A. References > This material is not formally part of the Policy Proposal. It is > included > here for informational purposes. > > 1. The IPv6 Address Plan - Geoff Huston > http://www.potaroo.net/ispcol/2005-07/ipv6size.html > > 2. Internet Draft: Issues Related to the Management of IPv6 Address > Space - > Thomas Narten > http://tools.ietf.org/wg/ipv6/draft-narten-iana-rir-ipv6-considerations- > 00.txt > > [unfortunately, the ID expired, so use the URL: > > http://www.cs.duke.edu/~narten/ietf/draft-narten-iana-rir-ipv6-considera > tions-00.txt] > > > 3. Internet Draft: IPv6 Address Allocation to End Sites - Thomas Narten, > Geoff Huston & Lea Roberts > http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary > -01.txt > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From randy at psg.com Sat Mar 11 19:06:10 2006 From: randy at psg.com (Randy Bush) Date: Sat, 11 Mar 2006 14:06:10 -1000 Subject: [ppml] a modified proposal 2005-8 References: <441272E7.5040104@psg.com> Message-ID: <17427.26098.851714.907439@roam.psg.com> > The following guidelines may be useful (but they are only guidelines): > > - /64 when it is known that one and only one subnet is needed > > - /56 for small sites, those expected to need only a few subnets > over the next 5 years. 256 is a few? if you have to nibble away at it, isn't a /60 more like a few? > - /48 for larger sites i still do not understand why/how you are picking these points on the knob. what we really mean is allocate what is justifiable for the next few ( !=256 :-) years. > For end sites to whom DNS will be delegated, the LIR/ISP ^ reverse randy From lea.roberts at stanford.edu Sat Mar 11 19:44:36 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Sat, 11 Mar 2006 16:44:36 -0800 (PST) Subject: [ppml] a modified proposal 2005-8 In-Reply-To: <17427.26098.851714.907439@roam.psg.com> Message-ID: hi Randy - On Sat, 11 Mar 2006, Randy Bush wrote: > > The following guidelines may be useful (but they are only guidelines): ^^^^^^^^^^^^^^^^^^^^^^^^ > > - /56 for small sites, those expected to need only a few subnets > > over the next 5 years. > > 256 is a few? if you have to nibble away at it, isn't a /60 more > like a few I don't disagree... we just put out some talking numbers and thank you for your suggestion(s). I think one thing I would like to know is what people think about providing generous assignments with the justification being to make sure to provide flexibility to adapt to new architectures that we have yet to imagine. That's been the argument for /48 everywhere and I don't want to fall into the tighten it too much trap. I believe it is *really* important to try to make sure that everyone who needs lots of subnets can get them easily. This needs to be balanced against careless waste of the address space. that said, do others think we should add the /60 "for a few" to the guidelines? > > - /48 for larger sites > > i still do not understand why/how you are picking these points on > the knob. what we really mean is allocate what is justifiable for > the next few ( !=256 :-) years. Our goal is to provide some numbers for people with less clue than you. Are you suggesting that we should assume a sufficient clue level for all ISP/LIRs? > > For end sites to whom DNS will be delegated, the LIR/ISP > ^ reverse thanks for this editorial suggestion. I will ask Einar to include it if he can... thanks again, /Lea From sleibrand at internap.com Sat Mar 11 20:27:23 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 11 Mar 2006 20:27:23 -0500 (EST) Subject: [ppml] a modified proposal 2005-8 In-Reply-To: References: Message-ID: On 03/11/06 at 4:44pm -0800, Lea Roberts wrote: > On Sat, 11 Mar 2006, Randy Bush wrote: > > > > The following guidelines may be useful (but they are only guidelines): > ^^^^^^^^^^^^^^^^^^^^^^^^ > > > - /56 for small sites, those expected to need only a few subnets > > > over the next 5 years. > > > > 256 is a few? if you have to nibble away at it, isn't a /60 more > > like a few > > I don't disagree... we just put out some talking numbers and thank you > for your suggestion(s). I think one thing I would like to know is what > people think about providing generous assignments with the justification > being to make sure to provide flexibility to adapt to new architectures > that we have yet to imagine. That's been the argument for /48 everywhere > and I don't want to fall into the tighten it too much trap. I believe it > is *really* important to try to make sure that everyone who needs lots of > subnets can get them easily. This needs to be balanced against careless > waste of the address space. > > that said, do others think we should add the /60 "for a few" to the > guidelines? I don't think we should encourage anything less than a /56. I can think of all kinds of network topologies just for home users that might need more than 16 subnets. For example, an autoconfigured mesh network (where everyone provides backup connectivity for their neighbors) might be implemented by automatically allocating a /64 to each of your neighbors. -Scott From kloch at hotnic.net Sat Mar 11 20:30:42 2006 From: kloch at hotnic.net (Kevin Loch) Date: Sat, 11 Mar 2006 20:30:42 -0500 Subject: [ppml] a modified proposal 2005-8 In-Reply-To: References: Message-ID: <441379C2.2050301@hotnic.net> Lea Roberts wrote: > I don't disagree... we just put out some talking numbers and thank you > for your suggestion(s). I think one thing I would like to know is what > people think about providing generous assignments with the justification > being to make sure to provide flexibility to adapt to new architectures > that we have yet to imagine. Generous minimums are beneficial for allocations/assignments made directly by an RIR. This helps reduce the number of non-aggregatable prefixes per AS. This benefit does not seem to apply to assignments from LIR->end user. > That's been the argument for /48 everywhere > and I don't want to fall into the tighten it too much trap. I believe it > is *really* important to try to make sure that everyone who needs lots of > subnets can get them easily. I think what Rany is saying is to allow end users whatever address space they need, but don't give them space they don't need. They can always go back and get more if their needs change. > that said, do others think we should add the /60 "for a few" to the > guidelines? Yes, 16 subnets seems like a sufficient size for most residential/small business networks today. Now how do we ensure that end users can get more space if they do need it? Should the policy require LIR's to assign up to /48 to an org if they request it? - Kevin From randy at psg.com Sat Mar 11 20:41:54 2006 From: randy at psg.com (Randy Bush) Date: Sat, 11 Mar 2006 15:41:54 -1000 Subject: [ppml] a modified proposal 2005-8 References: <17427.26098.851714.907439@roam.psg.com> Message-ID: <17427.31842.564744.267307@roam.psg.com> > Are you suggesting that we should assume a sufficient clue level > for all ISP/LIRs? if we assume cluelessness, then we should only hand out address space to isps who take and pass a written exam. and we could put their grade in a bgp attribute, so we could treat their routes accordingly. get real. set the guidelines that should be followed. read nanog to see what happens to low quality isps, customers make the quality vs pricing decision pretty well. in line with that, basing policy on every usage scenario we can imagine in our fantasies is mentally deficient. it leads right back to tlas, nlas, ... we should be doing our best to be reality-based. that's hard enough that we don't need more koolaid. randy From lea.roberts at stanford.edu Sat Mar 11 22:06:17 2006 From: lea.roberts at stanford.edu (Lea Roberts) Date: Sat, 11 Mar 2006 19:06:17 -0800 (PST) Subject: [ppml] a modified proposal 2005-8 In-Reply-To: <17427.31842.564744.267307@roam.psg.com> Message-ID: On Sat, 11 Mar 2006, Randy Bush wrote: > > Are you suggesting that we should assume a sufficient clue level > > for all ISP/LIRs? > > if we assume cluelessness, then we should only hand out address > space to isps who take and pass a written exam. and we could put > their grade in a bgp attribute, so we could treat their routes > accordingly. > > get real. set the guidelines that should be followed. read nanog > to see what happens to low quality isps, customers make the quality > vs pricing decision pretty well. > > in line with that, basing policy on every usage scenario we can > imagine in our fantasies is mentally deficient. it leads right > back to tlas, nlas, ... > > we should be doing our best to be reality-based. that's hard > enough that we don't need more koolaid. I'll take that as a "Yes!!" thanks, /Lea From Crumb_Anthony_A at cat.com Mon Mar 13 11:07:27 2006 From: Crumb_Anthony_A at cat.com (Anthony A. Crumb) Date: Mon, 13 Mar 2006 10:07:27 -0600 Subject: [ppml] IPv6 initial allocation policy Message-ID: My organization has begun working through the definition of an enterprise IPv6 acquisition, allocation, and deployment strategy. I was charged with identifying the process required to acquire IPv6 address space from the three registrars (ARIN, RIPE, and APNIC) from which we currently have carrier independent IPv4 allocations. Our thoughts are, because we have a dual carrier connected Internet POP within each of these IPv4 allocations we should request provider independent IPv6 space from each of the registrars. Imagine my surprise when I found that each registrar has adopted a policy that does not allow for the assignment of carrier independent IPv6 address space to end customers. This policy runs counter to an obligation to our customers, supplier and dealer to provide no less than two connection paths into and out of our Internet facing network application environments. Not to mention robbing us of the leverage needed to be able to shop our very considerable WAN circuit business between carriers. Is anyone aware of a coalition of companies that is working together to over turn this policy? Anthony A. Crumb Enterprise IP/DNS Management Global IT Solutions, Caterpillar Inc. Email: crumbaa at cat.com Phone: 309-494-7816 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleibrand at internap.com Mon Mar 13 11:29:13 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 13 Mar 2006 11:29:13 -0500 (EST) Subject: [ppml] IPv6 initial allocation policy In-Reply-To: References: Message-ID: Anthony, Check out the policy proposals on ARIN's website for the upcoming Montreal meeting. There's a policy under consideration that would allow anyone who qualifies for IPv4 provider-independent (PI) space to get IPv6 PI space as well. It sounds like you're strongly in favor of such a policy, so I would recommend reading over it, expressing your opinion of the policy to this list, and then participating in the Montreal ARIN meeting (either in person or remotely) to have a part in the process. -Scott On 03/13/06 at 10:07am -0600, Anthony A. Crumb wrote: > My organization has begun working through the definition of an enterprise > IPv6 acquisition, allocation, and deployment strategy. I was charged with > identifying the process required to acquire IPv6 address space from the > three registrars (ARIN, RIPE, and APNIC) from which we currently have > carrier independent IPv4 allocations. Our thoughts are, because we have a > dual carrier connected Internet POP within each of these IPv4 allocations > we should request provider independent IPv6 space from each of the > registrars. Imagine my surprise when I found that each registrar has > adopted a policy that does not allow for the assignment of carrier > independent IPv6 address space to end customers. This policy runs counter > to an obligation to our customers, supplier and dealer to provide no less > than two connection paths into and out of our Internet facing network > application environments. Not to mention robbing us of the leverage needed > to be able to shop our very considerable WAN circuit business between > carriers. Is anyone aware of a coalition of companies that is working > together to over turn this policy? > > > > Anthony A. Crumb > Enterprise IP/DNS Management > Global IT Solutions, Caterpillar Inc. > Email: crumbaa at cat.com > Phone: 309-494-7816 -------------- next part -------------- _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From terry.l.davis at boeing.com Mon Mar 13 11:50:25 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Mon, 13 Mar 2006 08:50:25 -0800 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BCD5@XCH-NW-8V1.nw.nos.boeing.com> Anthony All of us in the large corporate realm are facing exactly that same dilemma. We literally cannot consider deploying IP-v6 until this is resolved such that we can obtain our own provider independent address space. Besides our obligations to our customers and suppliers; we also still have to meet the new Sarbanes-Oxley rules which may actually prohibit us from utilizing IP-v6 due to an increased risk that acceptance of a single provider solution seems to imply. And regardless, our business folks simply point out it is a bad business practice to be so dependent on a single supplier, especially for global corporations like ours. Take care Terry L Davis Boeing Technical Fellow ________________________________ From: Anthony A. Crumb [mailto:Crumb_Anthony_A at cat.com] Sent: Monday, March 13, 2006 8:07 AM To: ppml at arin.net Subject: [ppml] IPv6 initial allocation policy My organization has begun working through the definition of an enterprise IPv6 acquisition, allocation, and deployment strategy. I was charged with identifying the process required to acquire IPv6 address space from the three registrars (ARIN, RIPE, and APNIC) from which we currently have carrier independent IPv4 allocations. Our thoughts are, because we have a dual carrier connected Internet POP within each of these IPv4 allocations we should request provider independent IPv6 space from each of the registrars. Imagine my surprise when I found that each registrar has adopted a policy that does not allow for the assignment of carrier independent IPv6 address space to end customers. This policy runs counter to an obligation to our customers, supplier and dealer to provide no less than two connection paths into and out of our Internet facing network application environments. Not to mention robbing us of the leverage needed to be able to shop our very considerable WAN circuit business between carriers. Is anyone aware of a coalition of companies that is working together to over turn this policy? Anthony A. Crumb Enterprise IP/DNS Management Global IT Solutions, Caterpillar Inc. Email: crumbaa at cat.com Phone: 309-494-7816 -------------- next part -------------- An HTML attachment was scrubbed... URL: From memsvcs at arin.net Mon Mar 13 13:38:09 2006 From: memsvcs at arin.net (Member Services) Date: Mon, 13 Mar 2006 13:38:09 -0500 Subject: [ppml] ARIN XVII - Policy Proposals Message-ID: <4415BC11.2060205@arin.net> ARIN will hold its next Public Policy and Members Meeting in Montreal on April 10-12, 2006. Meeting and registration details can be found at: http://www.arin.net/ARIN-XVII/index.html Policy discussions at this meeting will focus on policy proposals recently introduced to the Public Policy Mailing List (PPML), and those carried over from the previous Public Policy Meeting. Policy Proposals recently introduced on PPML: 2005-9: 4-Byte AS Number 2006-1: Residential Customer Privacy 2006-2: Micro-allocations for Internal Infrastructure 2006-3: Capturing Originations in Templates 2006-4: IPv6 Direct PI Assignments for End Sites 2006-5: IPv4 Micro-allocations for anycast services (temporary) Policy Proposals carried over from the previous Public Policy Meeting: 2005-1: Provider-independent IPv6 Assignments for End Sites 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement Policy proposals are open for discussion on PPML. Each of the policy proposals has been previously posted to PPML as an independent thread to facilitate discussion. A summary of the active policy proposals under discussion can be found at: http://www.arin.net/policy/proposal_archive.html The entire Internet community is invited and encouraged to participate in these policy discussions. Your active participation in these discussions is vital to the process and will help to form policies that are beneficial to all. Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services Department American Registry for Internet Numbers From memsvcs at arin.net Mon Mar 13 13:54:29 2006 From: memsvcs at arin.net (Member Services) Date: Mon, 13 Mar 2006 13:54:29 -0500 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - revised text Message-ID: <4415BFE5.8020202@arin.net> Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement has been revised by the authors. This proposal is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting. The current policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2005_8.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement Authors: Lea Roberts and Thomas Narten Proposal Version: 2 (10-Mar-2006) Proposal type: modify Policy term: permanent Policy statement: This proposal would amend the IPv6 address allocation policies (ARIN's NRPM, section 6) regarding the definition of the default size of End Site assignments and the threshold value for End Site allocation efficiency, no longer assuming the fixed values for End Site assignments established by RFC3177. Many references to "/48" will need to be replaced by "End Site assignment". for example, section 6.5.4.1 should be replaced as follows: 6.5.4.1. Assignment address space size End Users are assigned an End Site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the End Site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): - /64 when it is known that one and only one subnet is needed - /56 for small sites, those expected to need only a few subnets over the next 5 years. - /48 for larger sites For end sites to whom reverse DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to simplify reverse lookup delegation. RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns. Accordingly, RIRs/NIRs will not request the detailed information on IPv6 user networks as they did in IPv4, except for the cases described in Section 6.4.4 and for the purposes of measuring utilization as defined in this document. also, section 6.9 will need to be replaced: 6.9. IPv6 Reassignments policy The size of IPv6 address assignments to End Sites is to be determined by the ISP/LIR. ISPs and LIRs may choose whether to make changes to their procedures for assigning address blocks to End Sites. The threshold End Site allocation efficiency level is between 20% to 50% for most ISPs and LIRs when based on a 0.94 HD Ratio. ISPs and LIRs will need to operate address plans according to this target level of End Site allocation efficiency. there's a need to change ARIN NRPM IPv6 Utilization: The ARIN NRPM Section 6.7 will be amended so its IPv6 allocation utilization criteria will reflect the use of a /56 as the unit quantity in the calculation of the ISP or LIR's end site allocation efficiency. 8. Rationale: The current IPv6 Address Allocation and Assignment Policy (section 6 of ARIN's NRPM) indicates that end sites should be allocated a /48 as a uniform allocation unit if using more than one host or one subnet. This proposal alters the existing policy regarding LIR and ISP assignments to End Sites to allow the unit of assignment to be an LIR or ISP decision. In assessing the address utilization efficiency for ISPs or LIRs, the definition of an End Site for the purposes of the calculation of ISP or LIR End Site allocation efficiency, is to be made according to a /56 size. This measure, if undertaken generally by all RIRs, in conjunction with the further measures undertaken by the addressing community regarding increasing the HD ratio to 0.94, would increase the anticipated useful lifetime of IPv6 to encompass a period in excess of 100 years, in which case no further allocation policy changes would be anticipated. A more detailed rationale is available in Geoff Huston's presentation on the subject, at RIPE 50, which can be found at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv6-roundtable-report.pdf ------------------------------------------------------------------------ Appendix A. References This material is not formally part of the Policy Proposal. It is included here for informational purposes. 1. The IPv6 Address Plan - Geoff Huston http://www.potaroo.net/ispcol/2005-07/ipv6size.html 2. Internet Draft: Issues Related to the Management of IPv6 Address Space - Thomas Narten http://tools.ietf.org/wg/ipv6/draft-narten-iana-rir-ipv6-considerations-00.txt [unfortunately, the ID expired, so use the URL: http://www.cs.duke.edu/~narten/ietf/draft-narten-iana-rir-ipv6-considerations-00.txt] 3. Internet Draft: IPv6 Address Allocation to End Sites - Thomas Narten, Geoff Huston & Lea Roberts http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-01.txt Timetable for implementation: upon adoption From tme at multicasttech.com Mon Mar 13 13:59:17 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 13 Mar 2006 13:59:17 -0500 Subject: [ppml] ARIN XVII - Policy Proposals In-Reply-To: <4415BC11.2060205@arin.net> References: <4415BC11.2060205@arin.net> Message-ID: 1.) 2005-1 and 2006-4 and to some extent 2005-8 all deal with the same subject. Could it be arranged for these three to be discussed together, whether at once or sequentially, for those of us with tight travel schedules ? 2.) If that can be done, I would like to attend and present the results of a statistical analysis of the potential for IPv6 address aggregation (or "defragmentation") that I have been working on. Regards Marshall Eubanks On Mar 13, 2006, at 1:38 PM, Member Services wrote: > ARIN will hold its next Public Policy and Members Meeting in > Montreal on > April 10-12, 2006. Meeting and registration details can be found at: > http://www.arin.net/ARIN-XVII/index.html > > Policy discussions at this meeting will focus on policy proposals > recently introduced to the Public Policy Mailing List (PPML), and > those > carried over from the previous Public Policy Meeting. > > Policy Proposals recently introduced on PPML: > 2005-9: 4-Byte AS Number > 2006-1: Residential Customer Privacy > 2006-2: Micro-allocations for Internal Infrastructure > 2006-3: Capturing Originations in Templates > 2006-4: IPv6 Direct PI Assignments for End Sites > 2006-5: IPv4 Micro-allocations for anycast services (temporary) > > Policy Proposals carried over from the previous Public Policy Meeting: > 2005-1: Provider-independent IPv6 Assignments for End Sites > 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation > requirement > > Policy proposals are open for discussion on PPML. Each of the policy > proposals has been previously posted to PPML as an independent > thread to > facilitate discussion. A summary of the active policy proposals under > discussion can be found at: > http://www.arin.net/policy/proposal_archive.html > > The entire Internet community is invited and encouraged to participate > in these policy discussions. Your active participation in these > discussions is vital to the process and will help to form policies > that > are beneficial to all. > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > Regards, > > Member Services Department > American Registry for Internet Numbers > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From sleibrand at internap.com Mon Mar 13 14:15:22 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 13 Mar 2006 14:15:22 -0500 (EST) Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - revised text In-Reply-To: <4415BFE5.8020202@arin.net> References: <4415BFE5.8020202@arin.net> Message-ID: I think I support this proposal, but I have a couple questions about the change to "the use of a /56 as the unit quantity in the calculation of the ISP or LIR's end site allocation efficiency." Specifically, will assignment of a /48 to a customer automatically count as 256 fully utilized /56's for these purposes? What about the allocation of 128 /64's? Would that count as a fully utilized or fully unutilized /56? Or can it be counted as what it is, a half-utilized /56? I guess I'm just trying to tease out the implications on an ISPs ability to get more space from using different assignment sizes for different customers. Thanks, Scott On 03/13/06 at 1:54pm -0500, Member Services wrote: > Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and > utilisation requirement has been revised by the authors. This proposal > is open for discussion on this mailing list and will be on the agenda at > the upcoming ARIN Public Policy Meeting. > > The current policy proposal text is provided below and is also available > at: http://www.arin.net/policy/proposals/2005_8.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ### * ### > > > Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and > utilisation requirement > > Authors: Lea Roberts and Thomas Narten > > Proposal Version: 2 (10-Mar-2006) > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > This proposal would amend the IPv6 address allocation policies (ARIN's > NRPM, section 6) regarding the definition of the default size of End > Site assignments and the threshold value for End Site allocation > efficiency, no longer assuming the fixed values for End Site assignments > established by RFC3177. Many references to "/48" will need to be > replaced by "End Site assignment". > > for example, section 6.5.4.1 should be replaced as follows: > > 6.5.4.1. Assignment address space size > > End Users are assigned an End Site assignment from their LIR or > ISP. The exact size of the assignment is a local decision for the > LIR or ISP to make, using a minimum value of a /64 (when only one > subnet is anticipated for the End Site) up to the normal maximum > of /48, except in cases of extra large end sites where a larger > assignment can be justified. > > The following guidelines may be useful (but they are only guidelines): > > - /64 when it is known that one and only one subnet is needed > > - /56 for small sites, those expected to need only a few subnets > over the next 5 years. > > - /48 for larger sites > > For end sites to whom reverse DNS will be delegated, the LIR/ISP > should consider making an assignment on a nibble (4-bit) boundary > to simplify reverse lookup delegation. > > RIRs/NIRs are not concerned about which address size an LIR/ISP > actually assigns. Accordingly, RIRs/NIRs will not request the > detailed information on IPv6 user networks as they did in IPv4, > except for the cases described in Section 6.4.4 and for the > purposes of measuring utilization as defined in this document. > > also, section 6.9 will need to be replaced: > > 6.9. IPv6 Reassignments policy > > The size of IPv6 address assignments to End Sites is to be > determined by the ISP/LIR. > > ISPs and LIRs may choose whether to make changes to their > procedures for assigning address blocks to End Sites. The threshold > End Site allocation efficiency level is between 20% to 50% for most > ISPs and LIRs when based on a 0.94 HD Ratio. ISPs and LIRs will > need to operate address plans according to this target level of End > Site allocation efficiency. > > > there's a need to change ARIN NRPM IPv6 Utilization: > > The ARIN NRPM Section 6.7 will be amended so its IPv6 allocation > utilization criteria will reflect the use of a /56 as the unit > quantity in the calculation of the ISP or LIR's end site allocation > efficiency. > > 8. Rationale: > > The current IPv6 Address Allocation and Assignment Policy (section 6 of > ARIN's NRPM) indicates that end sites should be allocated a /48 as a > uniform allocation unit if using more than one host or one subnet. > > This proposal alters the existing policy regarding LIR and ISP > assignments to End Sites to allow the unit of assignment to be an LIR or > ISP decision. > > In assessing the address utilization efficiency for ISPs or LIRs, the > definition of an End Site for the purposes of the calculation of ISP or > LIR End Site allocation efficiency, is to be made according to a /56 size. > > This measure, if undertaken generally by all RIRs, in conjunction with > the further measures undertaken by the addressing community regarding > increasing the HD ratio to 0.94, would increase the anticipated useful > lifetime of IPv6 to encompass a period in excess of 100 years, in which > case no further allocation policy changes would be anticipated. > > > A more detailed rationale is available in Geoff Huston's presentation on > the subject, at RIPE 50, which can be found at: > http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv6-roundtable-report.pdf > > > ------------------------------------------------------------------------ > > Appendix A. References > This material is not formally part of the Policy Proposal. It is > included here for informational purposes. > > 1. The IPv6 Address Plan - Geoff Huston > http://www.potaroo.net/ispcol/2005-07/ipv6size.html > > 2. Internet Draft: Issues Related to the Management of IPv6 Address > Space - Thomas Narten > http://tools.ietf.org/wg/ipv6/draft-narten-iana-rir-ipv6-considerations-00.txt > > [unfortunately, the ID expired, so use the URL: > > http://www.cs.duke.edu/~narten/ietf/draft-narten-iana-rir-ipv6-considerations-00.txt] > > > 3. Internet Draft: IPv6 Address Allocation to End Sites - Thomas Narten, > Geoff Huston & Lea Roberts > http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-01.txt > > > Timetable for implementation: upon adoption > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From owen at delong.com Mon Mar 13 14:29:29 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Mar 2006 11:29:29 -0800 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: References: Message-ID: <0AB9E5FC928638C15F600D6E@imac-en0.delong.sj.ca.us> I don't know about a coalition of companies, but, in the ARIN region, there are at least 2 policy proposals under discussion to try and resolve this issue. Kevin Loch and I have authored 2005-1 which is one of the proposals. Andrew Dul has authored 2006-4 which is the other. 2006-4 is more restrictive and limited to much larger organizations (requires 80% utilization of at least an IPv4 /19 and makes no allowance for sites which do not already have at least a /19 IPv4 direct assignment). I hope you will support 2005-1 as I believe it provides a solution to not only the largest and wealthiest companies, but, also to any company currently eligible for IPv4 PI space. Owen DeLong Policy Author DeLong Consulting owen at delong.com 408-921-6984 --On March 13, 2006 10:07:27 AM -0600 "Anthony A. Crumb" wrote: > > My organization has begun working through the definition of an enterprise > IPv6 acquisition, allocation, and deployment strategy. I was charged with > identifying the process required to acquire IPv6 address space from the > three registrars (ARIN, RIPE, and APNIC) from which we currently have > carrier independent IPv4 allocations. Our thoughts are, because we have a > dual carrier connected Internet POP within each of these IPv4 allocations > we should request provider independent IPv6 space from each of the > registrars. Imagine my surprise when I found that each registrar has > adopted a policy that does not allow for the assignment of carrier > independent IPv6 address space to end customers. This policy runs counter > to an obligation to our customers, supplier and dealer to provide no less > than two connection paths into and out of our Internet facing network > application environments. Not to mention robbing us of the leverage > needed to be able to shop our very considerable WAN circuit business > between carriers. Is anyone aware of a coalition of companies that is > working together to over turn this policy? > > > > Anthony A. Crumb > Enterprise IP/DNS Management > Global IT Solutions, Caterpillar Inc. > Email: crumbaa at cat.com > Phone: 309-494-7816 -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From alh-ietf at tndh.net Mon Mar 13 16:06:06 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 13 Mar 2006 13:06:06 -0800 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: <0AB9E5FC928638C15F600D6E@imac-en0.delong.sj.ca.us> Message-ID: <11c701c646e1$f1afe420$a291150a@tndh.net> Owen, One consideration for 2005-1 is what happens when IPv4 space runs out? A related question is what if IPv4 PI space becomes harder to get over time? Fundamentally, why should IPv6 PI space have anything to do with IPv4 PI space? Tony > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Owen DeLong > Sent: Monday, March 13, 2006 11:29 AM > To: Anthony A. Crumb; ppml at arin.net > Subject: Re: [ppml] IPv6 initial allocation policy > > I don't know about a coalition of companies, but, in the ARIN region, > there > are at least 2 policy proposals under discussion to try and resolve this > issue. Kevin Loch and I have authored 2005-1 which is one of the > proposals. > Andrew Dul has authored 2006-4 which is the other. 2006-4 is more > restrictive > and limited to much larger organizations (requires 80% utilization of at > least an IPv4 /19 and makes no allowance for sites which do not already > have at least a /19 IPv4 direct assignment). > > I hope you will support 2005-1 as I believe it provides a solution to > not only the largest and wealthiest companies, but, also to any company > currently eligible for IPv4 PI space. > > Owen DeLong > Policy Author > DeLong Consulting > owen at delong.com > 408-921-6984 > > > --On March 13, 2006 10:07:27 AM -0600 "Anthony A. Crumb" > wrote: > > > > > My organization has begun working through the definition of an > enterprise > > IPv6 acquisition, allocation, and deployment strategy. I was charged > with > > identifying the process required to acquire IPv6 address space from the > > three registrars (ARIN, RIPE, and APNIC) from which we currently have > > carrier independent IPv4 allocations. Our thoughts are, because we have > a > > dual carrier connected Internet POP within each of these IPv4 > allocations > > we should request provider independent IPv6 space from each of the > > registrars. Imagine my surprise when I found that each registrar has > > adopted a policy that does not allow for the assignment of carrier > > independent IPv6 address space to end customers. This policy runs > counter > > to an obligation to our customers, supplier and dealer to provide no > less > > than two connection paths into and out of our Internet facing network > > application environments. Not to mention robbing us of the leverage > > needed to be able to shop our very considerable WAN circuit business > > between carriers. Is anyone aware of a coalition of companies that is > > working together to over turn this policy? > > > > > > > > Anthony A. Crumb > > Enterprise IP/DNS Management > > Global IT Solutions, Caterpillar Inc. > > Email: crumbaa at cat.com > > Phone: 309-494-7816 > > > > -- > If it wasn't crypto-signed, it probably didn't come from me. From kloch at hotnic.net Mon Mar 13 16:30:15 2006 From: kloch at hotnic.net (Kevin Loch) Date: Mon, 13 Mar 2006 16:30:15 -0500 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: <11c701c646e1$f1afe420$a291150a@tndh.net> References: <11c701c646e1$f1afe420$a291150a@tndh.net> Message-ID: <4415E467.6080208@hotnic.net> Tony Hain wrote: > Owen, > > One consideration for 2005-1 is what happens when IPv4 space runs out? Hopefully we will have a compatible migration path to IPv6 before that happens. > A related question is what if IPv4 PI space becomes harder to get over time? > Fundamentally, why should IPv6 PI space have anything to do with IPv4 PI > space? The current version of 2005-1 is focused on transition activity. To provide a way for IPv4 networks using PI space today to begin using IPv6 without fundamentally changing the way the operate. With that goal in mind referencing IPv4 policy makes sense and seems to be generally supported. It was alot less controversial than any of the IPv6 only ideas that were suggested. It also represents a known metric that we have alot of operational experience with. I do think we need an IPv6 only PI policy at some point. Despite many attempts so far there is still alot of disagreement on how that should work. - Kevin From gih at apnic.net Mon Mar 13 16:36:59 2006 From: gih at apnic.net (Geoff Huston) Date: Tue, 14 Mar 2006 08:36:59 +1100 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - revised text In-Reply-To: References: <4415BFE5.8020202@arin.net> Message-ID: <6.2.0.14.2.20060314081835.02fe1ed0@kahuna.telstra.net> The HD ratio is calculated as the ratio of the log of the number of allocated 'objects' divided by the log of the maximum number of allocatable objects If you have been assigned a /32 then the number of allocatable units of /56 is 24 bits, or 16,777216 allocatable objects If you assigned a single /48 then you have assigned 8 bits, or 256 allocated objects. Your HD ratio for the assignment efficiency an address block with a single /48 assignment is log(256) / log(16777216) = 0.33333 The proposed HD metric to consider a block fully utilised is 0.94. This implies that a /32 would be considered fully utilised if you had allocated 24,154 /48s to end sites, or if you allocated 6,183,424 /56s to end sites, or 1,582,956,544 /64s to end sites A more detailed example may see you allocating 2,000 /48s, 2,000,000 /56s and 10,000,000 /64s - in /56 units this corresponds to 512,000, 2,000,000 and 39,062.5 /56 units respectively. Their total is 2,551,062.5, and the corresponding HD ratio for a /32 address block with this allocation spread is 0.88 regards, Geoff At 06:15 AM 14/03/2006, Scott Leibrand wrote: >I think I support this proposal, but I have a couple questions about the >change to "the use of a /56 as the unit quantity in the calculation of the >ISP or LIR's end site allocation efficiency." Specifically, will >assignment of a /48 to a customer automatically count as 256 fully >utilized /56's for these purposes? What about the allocation of 128 >/64's? Would that count as a fully utilized or fully unutilized /56? Or >can it be counted as what it is, a half-utilized /56? > >I guess I'm just trying to tease out the implications on an ISPs ability >to get more space from using different assignment sizes for different >customers. > >Thanks, >Scott > >On 03/13/06 at 1:54pm -0500, Member Services wrote: > > > Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and > > utilisation requirement has been revised by the authors. This proposal > > is open for discussion on this mailing list and will be on the agenda at > > the upcoming ARIN Public Policy Meeting. > > > > The current policy proposal text is provided below and is also available > > at: http://www.arin.net/policy/proposals/2005_8.html > > > > Regards, > > > > Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ### * ### > > > > > > Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and > > utilisation requirement > > > > Authors: Lea Roberts and Thomas Narten > > > > Proposal Version: 2 (10-Mar-2006) > > > > Proposal type: modify > > > > Policy term: permanent > > > > Policy statement: > > > > This proposal would amend the IPv6 address allocation policies (ARIN's > > NRPM, section 6) regarding the definition of the default size of End > > Site assignments and the threshold value for End Site allocation > > efficiency, no longer assuming the fixed values for End Site assignments > > established by RFC3177. Many references to "/48" will need to be > > replaced by "End Site assignment". > > > > for example, section 6.5.4.1 should be replaced as follows: > > > > 6.5.4.1. Assignment address space size > > > > End Users are assigned an End Site assignment from their LIR or > > ISP. The exact size of the assignment is a local decision for the > > LIR or ISP to make, using a minimum value of a /64 (when only one > > subnet is anticipated for the End Site) up to the normal maximum > > of /48, except in cases of extra large end sites where a larger > > assignment can be justified. > > > > The following guidelines may be useful (but they are only guidelines): > > > > - /64 when it is known that one and only one subnet is needed > > > > - /56 for small sites, those expected to need only a few subnets > > over the next 5 years. > > > > - /48 for larger sites > > > > For end sites to whom reverse DNS will be delegated, the LIR/ISP > > should consider making an assignment on a nibble (4-bit) boundary > > to simplify reverse lookup delegation. > > > > RIRs/NIRs are not concerned about which address size an LIR/ISP > > actually assigns. Accordingly, RIRs/NIRs will not request the > > detailed information on IPv6 user networks as they did in IPv4, > > except for the cases described in Section 6.4.4 and for the > > purposes of measuring utilization as defined in this document. > > > > also, section 6.9 will need to be replaced: > > > > 6.9. IPv6 Reassignments policy > > > > The size of IPv6 address assignments to End Sites is to be > > determined by the ISP/LIR. > > > > ISPs and LIRs may choose whether to make changes to their > > procedures for assigning address blocks to End Sites. The threshold > > End Site allocation efficiency level is between 20% to 50% for most > > ISPs and LIRs when based on a 0.94 HD Ratio. ISPs and LIRs will > > need to operate address plans according to this target level of End > > Site allocation efficiency. > > > > > > there's a need to change ARIN NRPM IPv6 Utilization: > > > > The ARIN NRPM Section 6.7 will be amended so its IPv6 allocation > > utilization criteria will reflect the use of a /56 as the unit > > quantity in the calculation of the ISP or LIR's end site allocation > > efficiency. > > > > 8. Rationale: > > > > The current IPv6 Address Allocation and Assignment Policy (section 6 of > > ARIN's NRPM) indicates that end sites should be allocated a /48 as a > > uniform allocation unit if using more than one host or one subnet. > > > > This proposal alters the existing policy regarding LIR and ISP > > assignments to End Sites to allow the unit of assignment to be an LIR or > > ISP decision. > > > > In assessing the address utilization efficiency for ISPs or LIRs, the > > definition of an End Site for the purposes of the calculation of ISP or > > LIR End Site allocation efficiency, is to be made according to a /56 size. > > > > This measure, if undertaken generally by all RIRs, in conjunction with > > the further measures undertaken by the addressing community regarding > > increasing the HD ratio to 0.94, would increase the anticipated useful > > lifetime of IPv6 to encompass a period in excess of 100 years, in which > > case no further allocation policy changes would be anticipated. > > > > > > A more detailed rationale is available in Geoff Huston's presentation on > > the subject, at RIPE 50, which can be found at: > > > http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv6-roundtable-report.pdf > > > > > > ------------------------------------------------------------------------ > > > > Appendix A. References > > This material is not formally part of the Policy Proposal. It is > > included here for informational purposes. > > > > 1. The IPv6 Address Plan - Geoff Huston > > http://www.potaroo.net/ispcol/2005-07/ipv6size.html > > > > 2. Internet Draft: Issues Related to the Management of IPv6 Address > > Space - Thomas Narten > > > http://tools.ietf.org/wg/ipv6/draft-narten-iana-rir-ipv6-considerations-00.txt > > > > [unfortunately, the ID expired, so use the URL: > > > > > http://www.cs.duke.edu/~narten/ietf/draft-narten-iana-rir-ipv6-considerations-00.txt] > > > > > > 3. Internet Draft: IPv6 Address Allocation to End Sites - Thomas Narten, > > Geoff Huston & Lea Roberts > > > http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-01.txt > > > > > > Timetable for implementation: upon adoption > > > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > >_______________________________________________ >PPML mailing list >PPML at arin.net >http://lists.arin.net/mailman/listinfo/ppml From alh-ietf at tndh.net Mon Mar 13 16:53:03 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 13 Mar 2006 13:53:03 -0800 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: <4415E467.6080208@hotnic.net> Message-ID: <11e301c646e8$80b54c40$a291150a@tndh.net> Given the burn rate on the remaining IPv4 pool and the length of time it takes to get agreement on policies, the math doesn't really support an IPv4 biased approach. > -----Original Message----- > From: Kevin Loch [mailto:kloch at hotnic.net] > Sent: Monday, March 13, 2006 1:30 PM > To: Tony Hain > Cc: 'Owen DeLong'; 'Anthony A. Crumb'; ppml at arin.net > Subject: Re: [ppml] IPv6 initial allocation policy > > Tony Hain wrote: > > Owen, > > > > One consideration for 2005-1 is what happens when IPv4 space runs out? > > Hopefully we will have a compatible migration path to IPv6 before that > happens. > > > A related question is what if IPv4 PI space becomes harder to get over > time? > > Fundamentally, why should IPv6 PI space have anything to do with IPv4 PI > > space? > > The current version of 2005-1 is focused on transition activity. To > provide a way for IPv4 networks using PI space today to begin using > IPv6 without fundamentally changing the way the operate. With that goal > in mind referencing IPv4 policy makes sense and seems to be > generally supported. It was alot less controversial than any of the > IPv6 only ideas that were suggested. It also represents a known metric > that we have alot of operational experience with. > > I do think we need an IPv6 only PI policy at some point. Despite many > attempts so far there is still alot of disagreement on how that should > work. > > - Kevin From andrew.dul at quark.net Mon Mar 13 17:22:36 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Mon, 13 Mar 2006 22:22:36 +0000 Subject: [ppml] IPv6 initial allocation policy Message-ID: <20060313222236.25357.qmail@hoster908.com> > -------Original Message------- > From: Tony Hain > Subject: Re: [ppml] IPv6 initial allocation policy > Sent: 13 Mar '06 13:53 > > Given the burn rate on the remaining IPv4 pool and the length of time it > takes to get agreement on policies, the math doesn't really support an IPv4 > biased approach. What text/policy would you support for IPv6 PI space to end sites? If any? I seem to remember at the ARIN last meeting there was absolutely no agreement on the proposed policies which used IPv6 language to define requirements for end site organizations. Number of hosts, number of subnets, etc... I agree that IPv4 and IPv6 are different and we probably shouldn't tie the two together, however we know and understand IPv4 allocation requirements. Creating a policy that builds on this knowledge seems likely to have the greatest possibility of achieving consensus, since I don't think we know what IPv6 networks will look like at this point. Andrew From alh-ietf at tndh.net Mon Mar 13 18:30:00 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 13 Mar 2006 15:30:00 -0800 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: <20060313222236.25357.qmail@hoster908.com> Message-ID: <11e701c646f6$0c6a25a0$a291150a@tndh.net> Lets start with what we do know: 1) The number and density of hosts in IPv6 networks is & will be irrelevant. 2) We need to work within the constraints of the existing BGP protocol for the foreseeable future. 3) As long as IPv4 is run in parallel, the number of subnets will be the same because it would be too hard to explain to ops how it works otherwise. 4) If a subsequent allocation needs to be made, it should aggregate the current one, not just be adjacent (6.5.8.3 needs work) 5) The need for PI space has absolutely nothing to do with the size of the network. 6) The only reason for having any measure is to preclude the masses from taking global routing slots; though specifically RIR policies 'say nothing about routability of the assignments'. 7) There really is no single global DFZ even today, so approaches that allow pockets of aggregation 'as needed' will not break anything. 8) The number of PI entries and the capabilities of routers will evolve over time, so whatever approach is taken now it should be clearly identifiable and allow for future aggregation of early assignments if/when/where the need arises. The fundamental point of discussion is 6. At the end of the day ARIN needs to come to grips with the conflicting viewpoint that they 'don't talk about routability' while at the same time saying 'if you want an assignment that might take up a global routing slot you have to play by our rules'. When/if that gets resolved then we can consider how to accomplish 8 in the context of 7. In the mean time we could discuss the relative importance of putting something in place before it becomes an issue for the ITU to bolster their drive to take over global IPv6 assignments. Tony > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Andrew Dul > Sent: Monday, March 13, 2006 2:23 PM > To: ppml at arin.net > Subject: Re: [ppml] IPv6 initial allocation policy > > > -------Original Message------- > > From: Tony Hain > > Subject: Re: [ppml] IPv6 initial allocation policy > > Sent: 13 Mar '06 13:53 > > > > Given the burn rate on the remaining IPv4 pool and the length of time > it > > takes to get agreement on policies, the math doesn't really support an > IPv4 > > biased approach. > > What text/policy would you support for IPv6 PI space to end sites? If > any? > > I seem to remember at the ARIN last meeting there was absolutely no > agreement on the proposed policies which used IPv6 language to define > requirements for end site organizations. Number of hosts, number of > subnets, etc... > > I agree that IPv4 and IPv6 are different and we probably shouldn't tie the > two together, however we know and understand IPv4 allocation requirements. > Creating a policy that builds on this knowledge seems likely to have the > greatest possibility of achieving consensus, since I don't think we know > what IPv6 networks will look like at this point. > > Andrew > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From dgolding at burtongroup.com Mon Mar 13 19:56:09 2006 From: dgolding at burtongroup.com (Daniel Golding) Date: Mon, 13 Mar 2006 19:56:09 -0500 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: Message-ID: On 3/13/06 11:07 AM, "Anthony A. Crumb" wrote: > > My organization has begun working through the definition of an enterprise IPv6 > acquisition, allocation, and deployment strategy. I was charged with > identifying the process required to acquire IPv6 address space from the three > registrars (ARIN, RIPE, and APNIC) from which we currently have carrier > independent IPv4 allocations. Our thoughts are, because we have a dual carrier > connected Internet POP within each of these IPv4 allocations we should request > provider independent IPv6 space from each of the registrars. Imagine my > surprise when I found that each registrar has adopted a policy that does not > allow for the assignment of carrier independent IPv6 address space to end > customers. This policy runs counter to an obligation to our customers, > supplier and dealer to provide no less than two connection paths into and out > of our Internet facing network application environments. Not to mention > robbing us of the leverage needed to be able to shop our very considerable WAN > circuit business between carriers. Is anyone aware of a coalition of companies > that is working together to over turn this policy? > > > [snip] > Apologies for the off-topic post, but I?d suggest any enterprises interested in this issue should contact the IPv6 Business Council, ASAP. -- Daniel Golding -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Mon Mar 13 20:37:30 2006 From: randy at psg.com (Randy Bush) Date: Mon, 13 Mar 2006 15:37:30 -1000 Subject: [ppml] IPv6 initial allocation policy References: <0AB9E5FC928638C15F600D6E@imac-en0.delong.sj.ca.us> <11c701c646e1$f1afe420$a291150a@tndh.net> Message-ID: <17430.7770.138261.328161@roam.psg.com> > Fundamentally, why should IPv6 PI space have anything to do with > IPv4 PI space? shame you did not face that when folk wanted to make a better routing solution part of v6 before we created the current disaster. but it is the disaster. so v4 and v6 routing are intertwined. as routing and addressing are inextricably related ... randy From randy at psg.com Mon Mar 13 20:42:21 2006 From: randy at psg.com (Randy Bush) Date: Mon, 13 Mar 2006 15:42:21 -1000 Subject: [ppml] IPv6 initial allocation policy References: <11c701c646e1$f1afe420$a291150a@tndh.net> <4415E467.6080208@hotnic.net> Message-ID: <17430.8061.641467.977083@roam.psg.com> >> One consideration for 2005-1 is what happens when IPv4 space runs out? > Hopefully we will have a compatible migration path to IPv6 before that > happens. there is a problem with your mail system. it is regurgitating mail a decade or more old. but strangely it has a current Date: header. randy From randy at psg.com Mon Mar 13 21:02:04 2006 From: randy at psg.com (Randy Bush) Date: Mon, 13 Mar 2006 16:02:04 -1000 Subject: [ppml] IPv6 initial allocation policy References: <20060313222236.25357.qmail@hoster908.com> <11e701c646f6$0c6a25a0$a291150a@tndh.net> Message-ID: <17430.9244.571326.279710@roam.psg.com> > 1) The number and density of hosts in IPv6 networks is & will be > irrelevant. once upon a time, we thought that of v4. luckily, history never repeats. > 2) We need to work within the constraints of the existing BGP > protocol for the foreseeable future. thanks for that. > 3) As long as IPv4 is run in parallel, the number of subnets will > be the same because it would be too hard to explain to ops how it > works otherwise. this seems to assume that the v6 net is essentially congruent with the v4 network. perhaps this assumption is worthy of exploration. > 4) If a subsequent allocation needs to be made, it should > aggregate the current one, not just be adjacent (6.5.8.3 needs > work) like the thousands of de-aggregated adjascent /24s are aggregated today? not. > 5) The need for PI space has absolutely nothing to do with the > size of the network. this is a political, not an engineering statement. while politics should not be ignored, social theories which are a radical departure, such as every home should be pi, deserve suspicion. > 6) The only reason for having any measure is to preclude the > masses from taking global routing slots; though specifically RIR > policies 'say nothing about routability of the assignments'. the reasons for prudence have nothing to do with suppressing the proletariat. they are based in a history of problems with address space turning out not to be infinite and routing churn turning out to be a serious problem. > 7) There really is no single global DFZ even today, so approaches > that allow pockets of aggregation 'as needed' will not break > anything. can you describe examples of these "pockets of aggregation" as deployed today? > 8) The number of PI entries and the capabilities of routers will > evolve over time, so whatever approach is taken now it should be > clearly identifiable and allow for future aggregation of early > assignments if/when/where the need arises. for us to bet on this, the protocols and engineering also "should be clearly identifiable and allow for future aggregation of early assignments." are they? > In the mean time we could discuss the relative importance of > putting something in place before it becomes an issue for the ITU > to bolster their drive to take over global IPv6 assignments. or the chinese. muslims. or the christian right. or the boogeyman. can we focus on the engineering discussion? randy From bmanning at vacation.karoshi.com Mon Mar 13 21:27:17 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 14 Mar 2006 02:27:17 +0000 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: <17430.9244.571326.279710@roam.psg.com> References: <20060313222236.25357.qmail@hoster908.com> <11e701c646f6$0c6a25a0$a291150a@tndh.net> <17430.9244.571326.279710@roam.psg.com> Message-ID: <20060314022717.GA14286@vacation.karoshi.com.> > > 2) We need to work within the constraints of the existing BGP > > protocol for the foreseeable future. > > thanks for that. > > > 3) As long as IPv4 is run in parallel, the number of subnets will > > be the same because it would be too hard to explain to ops how it > > works otherwise. > > this seems to assume that the v6 net is essentially congruent with > the v4 network. perhaps this assumption is worthy of exploration. > > can we focus on the engineering discussion? er... this is a public policy list... not quite sure where/how engineering plays a role. :) anyway, lets peek at the two points above. presuming existing BGP, (which you express gratitude for) then one might rightly presume that unless any given ISP is going to replicate the CAPX to buy independent gear for building a v6 net that ignores any synergy w/ their v4 net and their various peering buddies seems to be a stretch. e.g. the "edge" of bills bait & sushi will be roughly congruent for the v4 and v6 nets due to cost of gear. or put another way, dual-stack is the presumed wave'o'the future. (can you even get a cisco box to NOT run v4?... last time i built one, it was impossible to run v6 only... needed v4 for SNMP & assorted other cruft) and if dual-stack is mandatory to run, then there will be v4/v6 net overlap. so not so much engineering as a pragmatic operational tactic. but your experiences may differ from mine. can you build a network that is v6 only from either cisco or juniper kit? if not, then i posit that #3, as far as "As long as IPv4 is run in parallel, the number of subnets will be the same.." is a reasonable presumption. --bill > > randy > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From randy at psg.com Mon Mar 13 21:34:30 2006 From: randy at psg.com (Randy Bush) Date: Mon, 13 Mar 2006 16:34:30 -1000 Subject: [ppml] IPv6 initial allocation policy References: <20060313222236.25357.qmail@hoster908.com> <11e701c646f6$0c6a25a0$a291150a@tndh.net> <17430.9244.571326.279710@roam.psg.com> <20060314022717.GA14286@vacation.karoshi.com.> Message-ID: <17430.11190.105257.363497@roam.psg.com> >>> 2) We need to work within the constraints of the existing BGP >>> protocol for the foreseeable future. >> thanks for that. and thanks for that to you too, bill >>> 3) As long as IPv4 is run in parallel, the number of subnets will >>> be the same because it would be too hard to explain to ops how it >>> works otherwise. >> this seems to assume that the v6 net is essentially congruent with >> the v4 network. perhaps this assumption is worthy of exploration. > (which you express gratitude for) then one might rightly presume that > unless any given ISP is going to replicate the CAPX to buy independent > gear for building a v6 net that ignores any synergy w/ their v4 net > and their various peering buddies seems to be a stretch. e.g. the > "edge" of bills bait & sushi will be roughly congruent for the v4 and > v6 nets due to cost of gear. "Congruent: adj ... Coinciding exactly when superimposed" this assumes v6 and v4 are deployed with the identical footprint. i doubt they will come close to that. especially given v4 nats and v6 nats, e.g., shim6. randy From bmanning at vacation.karoshi.com Mon Mar 13 21:49:13 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 14 Mar 2006 02:49:13 +0000 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: <17430.11190.105257.363497@roam.psg.com> References: <20060313222236.25357.qmail@hoster908.com> <11e701c646f6$0c6a25a0$a291150a@tndh.net> <17430.9244.571326.279710@roam.psg.com> <20060314022717.GA14286@vacation.karoshi.com.> <17430.11190.105257.363497@roam.psg.com> Message-ID: <20060314024913.GC14286@vacation.karoshi.com.> On Mon, Mar 13, 2006 at 04:34:30PM -1000, Randy Bush wrote: > >>> 2) We need to work within the constraints of the existing BGP > >>> protocol for the foreseeable future. > >> thanks for that. > > and thanks for that to you too, bill > > >>> 3) As long as IPv4 is run in parallel, the number of subnets will > >>> be the same because it would be too hard to explain to ops how it > >>> works otherwise. > >> this seems to assume that the v6 net is essentially congruent with > >> the v4 network. perhaps this assumption is worthy of exploration. > > (which you express gratitude for) then one might rightly presume that > > unless any given ISP is going to replicate the CAPX to buy independent > > gear for building a v6 net that ignores any synergy w/ their v4 net > > and their various peering buddies seems to be a stretch. e.g. the > > "edge" of bills bait & sushi will be roughly congruent for the v4 and > > v6 nets due to cost of gear. > you did notice the modifier... "roughly"?? my presumption is @/near the AS boundaries. > "Congruent: adj ... Coinciding exactly when superimposed" > > this assumes v6 and v4 are deployed with the identical footprint. > i doubt they will come close to that. especially given v4 nats > and v6 nats, e.g., shim6. > > randy From randy at psg.com Mon Mar 13 21:51:09 2006 From: randy at psg.com (Randy Bush) Date: Mon, 13 Mar 2006 16:51:09 -1000 Subject: [ppml] IPv6 initial allocation policy References: <20060313222236.25357.qmail@hoster908.com> <11e701c646f6$0c6a25a0$a291150a@tndh.net> <17430.9244.571326.279710@roam.psg.com> <20060314022717.GA14286@vacation.karoshi.com.> <17430.11190.105257.363497@roam.psg.com> <20060314024913.GC14286@vacation.karoshi.com.> Message-ID: <17430.12189.333600.866918@roam.psg.com> > you did notice the modifier... "roughly"?? yep. and considering how much of the net today is behind nats, i think you're idea of rough is not somthing i would advise anyone to try and hike across. From david.kessens at nokia.com Mon Mar 13 21:55:48 2006 From: david.kessens at nokia.com (David Kessens) Date: Mon, 13 Mar 2006 18:55:48 -0800 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: <20060314022717.GA14286@vacation.karoshi.com.> References: <20060313222236.25357.qmail@hoster908.com> <11e701c646f6$0c6a25a0$a291150a@tndh.net> <17430.9244.571326.279710@roam.psg.com> <20060314022717.GA14286@vacation.karoshi.com.> Message-ID: <20060314025548.GN31240@nokia.com> On Tue, Mar 14, 2006 at 02:27:17AM +0000, ppml-bounces at arin.net wrote: > > so not so much engineering as a pragmatic operational tactic. > but your experiences may differ from mine. can you build a network > that is v6 only from either cisco or juniper kit? if not, then > i posit that #3, as far as "As long as IPv4 is run in parallel, the > number of subnets will be the same.." is a reasonable presumption. It would be nice if we could go back to a discussion about the real issues on the ground as opposed to presumptions. Yes, there are people who build an exact mirror of their v4 network. There are other operators who don't. It really doessn't matter whether you were using v4 or not. What matters is that you have serious plan to deploy v6 and a real need for ipv6 addresses (eg. you don't need /32 if you are only deploying a few machines in a lab even if you have a huge v4 network). Another problem is the inequality in the proposals that I have seen so far. We really cannot afford to have policies in place that allow a small ISP in the midwest to get a /32 while a company like Boeing or Caterpillar gets treated like an 'End-User'. We have been discussing potential policies for end-users now for eternity but we have not shown any ability to come to a conclusion that is fair and equitable for a very large cross-section of the organizations that have shown a real interest in deploying ipv6. What we need is to fix is the 'global ipv6 allocation policy' and make it work for the people who actually do need ipv6 addresses. All these seperate proposals for certain special interest groups is not going to get that fixed and only creates new categories of haves and have-nots. David Kessens --- From randy at psg.com Mon Mar 13 21:58:49 2006 From: randy at psg.com (Randy Bush) Date: Mon, 13 Mar 2006 16:58:49 -1000 Subject: [ppml] IPv6 initial allocation policy References: <20060313222236.25357.qmail@hoster908.com> <11e701c646f6$0c6a25a0$a291150a@tndh.net> <17430.9244.571326.279710@roam.psg.com> <20060314022717.GA14286@vacation.karoshi.com.> <20060314025548.GN31240@nokia.com> Message-ID: <17430.12649.277043.899526@roam.psg.com> > What we need is to fix is the 'global ipv6 allocation policy' and make > it work for the people who actually do need ipv6 addresses. and to all those who will have to route the result and to our children who will ask why those big companies got all those class as, oops /40s or whatever. randy From bmanning at vacation.karoshi.com Mon Mar 13 22:00:10 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 14 Mar 2006 03:00:10 +0000 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: <17430.12189.333600.866918@roam.psg.com> References: <20060313222236.25357.qmail@hoster908.com> <11e701c646f6$0c6a25a0$a291150a@tndh.net> <17430.9244.571326.279710@roam.psg.com> <20060314022717.GA14286@vacation.karoshi.com.> <17430.11190.105257.363497@roam.psg.com> <20060314024913.GC14286@vacation.karoshi.com.> <17430.12189.333600.866918@roam.psg.com> Message-ID: <20060314030010.GA14505@vacation.karoshi.com.> On Mon, Mar 13, 2006 at 04:51:09PM -1000, Randy Bush wrote: > > you did notice the modifier... "roughly"?? > > yep. and considering how much of the net today is behind > nats, i think you're idea of rough is not somthing i would > advise anyone to try and hike across. so... just how -much- of the net today is behind nats? 20%? 80%? 99.8% --- and can those networks be said to be on the net in any realistic sense? (ok, pragmatically you can make that argument, that nats/algs are just another gateway linking up disparate bits of infrastructure and i'll likely believe you) but i'm not sure if you are talking the count of protocol stacks behind ALG/NAT boxen, or subnets behind ALG/NAT boxen. and as far as the ASN boundary btwn BGP speakers is concerned, do we need to care? --bill From owen at delong.com Tue Mar 14 00:37:36 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Mar 2006 21:37:36 -0800 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: <11c701c646e1$f1afe420$a291150a@tndh.net> References: <11c701c646e1$f1afe420$a291150a@tndh.net> Message-ID: <54E8C9096002EB1D6F634E06@odpwrbook.hq.netli.lan> If IPv4 space runs out, nothing changes unless IPv4 policy changes. If IPv4 policy changes, it is unlikely that it would be done without consideration of effects on IPv6 policy at the time. In the meantime, this seemed like the best available yardstick given the limitations we are faced with: 1. Host counts have been determined to be a bad metric. 2. Locations or Sites have been determined an inaccurate metric. 3. Noone has presented a better metric. As such, we are faced with two choices: 1. Copy current IPv4 allocation and assignment policy in it's entirety. 2. Incorporate it by reference with the understanding that future updates will affect both policies. Of these choices, I believe the latter to be preferable at this time. Certainly, this is a greater concern with 2006-4 which is completely tied to possession of existing IPv4 space. Owen --On March 13, 2006 1:06:06 PM -0800 Tony Hain wrote: > Owen, > > One consideration for 2005-1 is what happens when IPv4 space runs out? A > related question is what if IPv4 PI space becomes harder to get over > time? > > Fundamentally, why should IPv6 PI space have anything to do with IPv4 PI > space? > > Tony > > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of >> Owen DeLong >> Sent: Monday, March 13, 2006 11:29 AM >> To: Anthony A. Crumb; ppml at arin.net >> Subject: Re: [ppml] IPv6 initial allocation policy >> >> I don't know about a coalition of companies, but, in the ARIN region, >> there >> are at least 2 policy proposals under discussion to try and resolve this >> issue. Kevin Loch and I have authored 2005-1 which is one of the >> proposals. >> Andrew Dul has authored 2006-4 which is the other. 2006-4 is more >> restrictive >> and limited to much larger organizations (requires 80% utilization of at >> least an IPv4 /19 and makes no allowance for sites which do not already >> have at least a /19 IPv4 direct assignment). >> >> I hope you will support 2005-1 as I believe it provides a solution to >> not only the largest and wealthiest companies, but, also to any company >> currently eligible for IPv4 PI space. >> >> Owen DeLong >> Policy Author >> DeLong Consulting >> owen at delong.com >> 408-921-6984 >> >> >> --On March 13, 2006 10:07:27 AM -0600 "Anthony A. Crumb" >> wrote: >> >> > >> > My organization has begun working through the definition of an >> enterprise >> > IPv6 acquisition, allocation, and deployment strategy. I was charged >> with >> > identifying the process required to acquire IPv6 address space from the >> > three registrars (ARIN, RIPE, and APNIC) from which we currently have >> > carrier independent IPv4 allocations. Our thoughts are, because we have >> a >> > dual carrier connected Internet POP within each of these IPv4 >> allocations >> > we should request provider independent IPv6 space from each of the >> > registrars. Imagine my surprise when I found that each registrar has >> > adopted a policy that does not allow for the assignment of carrier >> > independent IPv6 address space to end customers. This policy runs >> counter >> > to an obligation to our customers, supplier and dealer to provide no >> less >> > than two connection paths into and out of our Internet facing network >> > application environments. Not to mention robbing us of the leverage >> > needed to be able to shop our very considerable WAN circuit business >> > between carriers. Is anyone aware of a coalition of companies that is >> > working together to over turn this policy? >> > >> > >> > >> > Anthony A. Crumb >> > Enterprise IP/DNS Management >> > Global IT Solutions, Caterpillar Inc. >> > Email: crumbaa at cat.com >> > Phone: 309-494-7816 >> >> >> >> -- >> If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Tue Mar 14 00:44:20 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Mar 2006 21:44:20 -0800 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: References: Message-ID: <6B1C49CF010396078DA47754@odpwrbook.hq.netli.lan> I'd encourage as many businesses and members of the IPv6 Business Council that care about this as possible to attend the Montreal meeting or comment on PPML or both. Owen --On March 13, 2006 7:56:09 PM -0500 Daniel Golding wrote: > On 3/13/06 11:07 AM, "Anthony A. Crumb" wrote: > > > > My organization has begun working through the definition of an enterprise > IPv6 acquisition, allocation, and deployment strategy. I was charged with > identifying the process required to acquire IPv6 address space from the > three registrars (ARIN, RIPE, and APNIC) from which we currently have > carrier independent IPv4 allocations. Our thoughts are, because we have a > dual carrier connected Internet POP within each of these IPv4 allocations > we should request provider independent IPv6 space from each of the > registrars. Imagine my surprise when I found that each registrar has > adopted a policy that does not allow for the assignment of carrier > independent IPv6 address space to end customers. This policy runs counter > to an obligation to our customers, supplier and dealer to provide no less > than two connection paths into and out of our Internet facing network > application environments. Not to mention robbing us of the leverage > needed to be able to shop our very considerable WAN circuit business > between carriers. Is anyone aware of a coalition of companies that is > working together to over turn this policy? > > > [snip] > > > > Apologies for the off-topic post, but I?d suggest any enterprises > interested in this issue should contact the IPv6 Business Council, ASAP. -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Tue Mar 14 00:56:37 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Mar 2006 21:56:37 -0800 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: <17430.9244.571326.279710@roam.psg.com> References: <20060313222236.25357.qmail@hoster908.com> <11e701c646f6$0c6a25a0$a291150a@tndh.net> <17430.9244.571326.279710@roam.psg.com> Message-ID: --On March 13, 2006 4:02:04 PM -1000 Randy Bush wrote: >> 1) The number and density of hosts in IPv6 networks is & will be >> irrelevant. > > once upon a time, we thought that of v4. luckily, history never > repeats. > No, we didn't. Once upon a time, we did not think that there would ever be enough hosts for the 32 bit address space to be inadequate, but, that's not the same thing. >From the earliest days of IPv4, you were not able to get a class A network for 20 hosts. >> 3) As long as IPv4 is run in parallel, the number of subnets will >> be the same because it would be too hard to explain to ops how it >> works otherwise. > > this seems to assume that the v6 net is essentially congruent with > the v4 network. perhaps this assumption is worthy of exploration. > As long as they are run in parallel, at least the overlapping sections generally will be. >> 4) If a subsequent allocation needs to be made, it should >> aggregate the current one, not just be adjacent (6.5.8.3 needs >> work) > > like the thousands of de-aggregated adjascent /24s are aggregated > today? not. > v6 allows for better sparse allocation planning to facilitate this, however. v4 did not have sufficient space for sparse allocation planning. >> 5) The need for PI space has absolutely nothing to do with the >> size of the network. > > this is a political, not an engineering statement. while politics > should not be ignored, social theories which are a radical > departure, such as every home should be pi, deserve suspicion. > There is an engineering requirement for any business which considers their network access mission critical to be able to multihome in a way that does not depend on modifications to hosts they do not control. Whether we choose to meet this engineering requirement or not is a political decision, but, that is an engineering requirement. >> 6) The only reason for having any measure is to preclude the >> masses from taking global routing slots; though specifically RIR >> policies 'say nothing about routability of the assignments'. > > the reasons for prudence have nothing to do with suppressing the > proletariat. they are based in a history of problems with address > space turning out not to be infinite and routing churn turning out > to be a serious problem. > Nonetheless, the current approach to solving those problems is to attempt to control the number of organizations which obtain such resources through some selection process. Like it or not, the end result is, essentially, the division of the network into two or more classes of citizenship based on ability to obtain independently routable IP space. >> 8) The number of PI entries and the capabilities of routers will >> evolve over time, so whatever approach is taken now it should be >> clearly identifiable and allow for future aggregation of early >> assignments if/when/where the need arises. > > for us to bet on this, the protocols and engineering also "should > be clearly identifiable and allow for future aggregation of early > assignments." are they? > Not yet to the best of my knowledge. However, I don't see the long term solution possibly including anything short of separation between IDR Locator and End System Identifier. >> In the mean time we could discuss the relative importance of >> putting something in place before it becomes an issue for the ITU >> to bolster their drive to take over global IPv6 assignments. > > or the chinese. muslims. or the christian right. or the > boogeyman. > > can we focus on the engineering discussion? > Perhaps you mistook this list for an IETF working group. This _IS_ a public policy list. As such, while the policies are engineering related and thus, engineering is a factor in the discussions, it is not entirely appropriate to ignore the political. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at btradianz.com Tue Mar 14 05:07:10 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 14 Mar 2006 10:07:10 +0000 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: <11c701c646e1$f1afe420$a291150a@tndh.net> Message-ID: > Fundamentally, why should IPv6 PI space have anything to do with IPv4 PI > space? Fundamentally, IPv6 is a replacement for IPv4. It seems logical and rational to have policies that ease the transition. --Michael Dillon From Michael.Dillon at btradianz.com Tue Mar 14 05:28:53 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 14 Mar 2006 10:28:53 +0000 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: Message-ID: > Apologies for the off-topic post, but I?d suggest any enterprises > interested in this issue should contact the IPv6 Business Council, ASAP. That's a good idea, but don't make the mistake of thinking that you can just go off and discuss the PI issue in a different forum and just present ARIN with some kind of joint position paper. That will NOT fly! ARIN runs an open public policy making process. Every enterprise with an interest in sensible IPv6 PI addressing policy should make their position known here on the PPML mailing list. That way, when the time comes to count how many people are pro and how many are con, your voice WILL get counted. So far we have heard from Boeing, a member of the IPv6 Business Council, and from Cat, a non-member. But we haven't yet heard the views of any of the other members of the council. --Michael Dillon From Michael.Dillon at btradianz.com Tue Mar 14 05:38:09 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 14 Mar 2006 10:38:09 +0000 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: <17430.9244.571326.279710@roam.psg.com> Message-ID: > this is a political, not an engineering statement. And this is a policy forum, not an engineering one. > for us to bet on this, the protocols and engineering also "should > be clearly identifiable and allow for future aggregation of early > assignments." are they? BGP proxy aggregation This discussion from NANOG 11 years ago: http://www.academ.com/nanog/september1995/proxy.html leads me to suspect that proxy aggregation is a tried and tested way of dealing with the future aggregation of early assignments, as long as ARIN allocates the address blocks so that they are aggregatable. If ARIN does allocate these PI blocks from a single identifiable aggregate, then I suspect that ISPs outside North America will proxy aggregate these prefixes. Of course, with a little more effort, ARIN could allow for several regional aggregates within North America. > can we focus on the engineering discussion? I think you want the IETF mailing list. This is ARIN's public policy mailing list where engineering is secondary to policy. --Michael Dillon From li.tony at comcast.net Tue Mar 14 11:49:33 2006 From: li.tony at comcast.net (Tony Li) Date: Tue, 14 Mar 2006 08:49:33 -0800 Subject: [ppml] IPv6 initial allocation policy In-Reply-To: Message-ID: <001201c64787$45d2d580$9c01a8c0@tropos.com> > BGP proxy aggregation > This discussion from NANOG 11 years ago: > http://www.academ.com/nanog/september1995/proxy.html > leads me to suspect that proxy aggregation is a tried > and tested way of dealing with the future aggregation of > early assignments, as long as ARIN allocates the address > blocks so that they are aggregatable. As one who was there: proxy aggregation was tried, tested, and rejected by the operational community because of the traffic engineeering implications. Sound familiar? To revive proxy aggregation, it would be necessary to put into place an operational group of service providers who could consider different abstraction naming boundaries and appropriate abstraction action boundaries, make a long term commitment to implementing them and only then make recommendations to a RIR. Only by careful planning could we avoid making the same mistakes again. Tony P.s. I'm actually a supporter of doing this, but as always, I think that you'll find that I'm in the minority. From randy at psg.com Tue Mar 14 12:39:32 2006 From: randy at psg.com (Randy Bush) Date: Tue, 14 Mar 2006 07:39:32 -1000 Subject: [ppml] IPv6 initial allocation policy References: <001201c64787$45d2d580$9c01a8c0@tropos.com> Message-ID: <17430.65492.599133.548567@roam.psg.com> > As one who was there: proxy aggregation was tried, tested, > and rejected by the operational community because of the > traffic engineeering implications. Sound familiar? another way of saying it is that it was not clear that an 'upstream' (or sidestream) had the contractual right to alter someone else's routing. hence, almost the only public place(s) proxy aggregation is used today is by the military, who do have that kind of authority over their customers. randy From jdhoule at att.com Wed Mar 15 19:13:16 2006 From: jdhoule at att.com (Houle, Joseph D (Joe), CMO) Date: Wed, 15 Mar 2006 18:13:16 -0600 Subject: [ppml] a modified proposal 2005-8 In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BCC7@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: Terry: I hope I am reading your last paragraph incorrectly? Are you suggesting these other entities will "allocate to you a subnet or an address" for devices on your location? I would hope not, I would hope you have some number of subnets at your location and these other entities will want to communicate with some devices at your location which you have addressed from an aggregated block. Right? Joe Houle -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Davis, Terry L Sent: Saturday, March 11, 2006 3:57 PM To: Lea Roberts; ppml at arin.net Subject: Re: [ppml] a modified proposal 2005-8 Lea The proposal is fine. But I am actually hard pressed to imagine a single entity site that will have only a single local subnet under an IP-v6 architecture. I tend to believe that IP-v6 architectures will be very different from our traditional IP-v4 concepts. My power, entertain, City, and communications company will probably allocate me one each from there individual spaces but I still think I will several of my own as I do today. Take care Terry -----Original Message----- From: Lea Roberts [mailto:lea.roberts at stanford.edu] Sent: Saturday, March 11, 2006 12:34 AM To: ppml at arin.net Subject: [ppml] a modified proposal 2005-8 was just sent in to ARIN... for your additional reading pleasure. /Lea Policy Proposal 2005-8, version 2: Proposal to amend ARIN IPv6 assignment and utilisation requirement This proposal would amend the IPv6 address allocation policies (ARIN's NRPM, section 6) regarding the definition of the default size of End Site assignments and the threshold value for End Site allocation efficiency, no longer assuming the fixed values for End Site assignments established by RFC3177. Many references to "/48" will need to be replaced by "End Site assignment". for example, section 6.5.4.1 should be replaced as follows: 6.5.4.1. Assignment address space size End Users are assigned an End Site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the End Site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): - /64 when it is known that one and only one subnet is needed - /56 for small sites, those expected to need only a few subnets over the next 5 years. - /48 for larger sites For end sites to whom DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to allow to simplify reverse lookup delegation. RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns. Accordingly, RIRs/NIRs will not request the detailed information on IPv6 user networks as they did in IPv4, except for the cases described in Section 6.4.4 and for the purposes of measuring utilization as defined in this document. also, section 6.9 will need to be replaced: 6.9. IPv6 Reassignments policy The size of IPv6 address assignments to End Sites is to be determined by the ISP/LIR. ISPs and LIRs may choose whether to make changes to their procedures for assigning address blocks to End Sites. The threshold End Site allocation efficiency level is between 20% to 50% for most ISPs and LIRs when based on a 0.94 HD Ratio. ISPs and LIRs will need to operate address plans according to this target level of End Site allocation efficiency. there's a need to change ARIN NRPM IPv6 Utilization: The ARIN NRPM Section 6.7 will be amended so its IPv6 allocation utilization criteria will reflect the use of a /56 as the unit quantity in the calculation of the ISP or LIR's end site allocation efficiency. Rationale: The current IPv6 Address Allocation and Assignment Policy (section 6 of ARIN's NRPM) indicates that end sites should be allocated a /48 as a uniform allocation unit if using more than one host or one subnet. This proposal alters the existing policy regarding LIR and ISP assignments to End Sites to allow the unit of assignment to be an LIR or ISP decision. In assessing the address utilization efficiency for ISPs or LIRs, the definition of an End Site for the purposes of the calculation of ISP or LIR End Site allocation efficiency, is to be made according to a /56 size. This measure, if undertaken generally by all RIRs, in conjunction with the further measures undertaken by the addressing community regarding increasing the HD ratio to 0.94, would increase the anticipated useful lifetime of IPv6 to encompass a period in excess of 100 years, in which case no further allocation policy changes would be anticipated. A more detailed rationale is available in Geoff Huston's presentation on the subject, at RIPE 50, which can be found at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-w ed-ipv6-roundtable-report.pdf ------------------------------------------------------------------------ Appendix A. References This material is not formally part of the Policy Proposal. It is included here for informational purposes. 1. The IPv6 Address Plan - Geoff Huston http://www.potaroo.net/ispcol/2005-07/ipv6size.html 2. Internet Draft: Issues Related to the Management of IPv6 Address Space - Thomas Narten http://tools.ietf.org/wg/ipv6/draft-narten-iana-rir-ipv6-considerations- 00.txt [unfortunately, the ID expired, so use the URL: http://www.cs.duke.edu/~narten/ietf/draft-narten-iana-rir-ipv6-considera tions-00.txt] 3. Internet Draft: IPv6 Address Allocation to End Sites - Thomas Narten, Geoff Huston & Lea Roberts http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary -01.txt _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From terry.l.davis at boeing.com Wed Mar 15 22:28:49 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Wed, 15 Mar 2006 19:28:49 -0800 Subject: [ppml] a modified proposal 2005-8 In-Reply-To: Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BD03@XCH-NW-8V1.nw.nos.boeing.com> Joe Nope, you read it correctly! The power company will require your electrical systems to be on their PLC networks in order to control your electrical systems; it would make a completely unworkable control and routing system for the electric company to try to map the homeowners ISP assigned networks to your home load controller. You will need to interface to their control center somehow to set your home systems/load controllers and that could be via any available networks but the actual controls will need to come in over their networks. Likewise government would like to give each home a permanent subnet from "its addresses" for their use especially including advanced EMS services such that they can handle both 911 and direct fire alarms. I wouldn't be surprised if in a couple decades, your home City/County has your properties IP address on your deed. I already have two ISP's serving my home; cable and DSL both and will probably add an EVDO link with a third. In my case, because of the incredibly poor physical plant in my area, neither are very reliable. Try this list, you can validate it with some of the folks working community networking: - Internet Service Provider - Entertainment Service Provider - Home Application Service Provider - Government Services - Communication Service Provider - Power Provider - Metering Provider - EMS (911 and fire alarm) - Security Service Provider None of these will be a simple single IP address either as most will have multiple controls or sensors serving your home. And no your ISP will NOT work as the sole provider of my home IP's! I'll personally fight that on capital hill! We fought for the right not to be forced to switch phone numbers when we move and I'm on my 4th (or 5th) ISP serving my home in the last ten years. (AT&T, Earthlink, Qwest, MSN, Speakeasy, and Comcast, ok 6th) All of which provided me with new IP's and email addresses which had no relation to any my previous ones so I had to contact everyone I emailed with and have them update my email address. Bill paying services make this even worse! It takes months to get them all updated; one-at-a-time. This is exactly why I would prefer a local government provided IP that was associated with my home address that didn't change until I moved! And I certainly don't want to worry that if I change ISP, 911 or fire won't be able to find me. Likewise I want to keep my phone number when I move and my email even if I have to change service providers. Sorry but my view of the future world has little to do with today's! Take care Terry -----Original Message----- From: Houle, Joseph D (Joe), CMO [mailto:jdhoule at att.com] Sent: Wednesday, March 15, 2006 4:13 PM To: Davis, Terry L Cc: Lea Roberts; ppml at arin.net Subject: RE: [ppml] a modified proposal 2005-8 Terry: I hope I am reading your last paragraph incorrectly? Are you suggesting these other entities will "allocate to you a subnet or an address" for devices on your location? I would hope not, I would hope you have some number of subnets at your location and these other entities will want to communicate with some devices at your location which you have addressed from an aggregated block. Right? Joe Houle -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Davis, Terry L Sent: Saturday, March 11, 2006 3:57 PM To: Lea Roberts; ppml at arin.net Subject: Re: [ppml] a modified proposal 2005-8 Lea The proposal is fine. But I am actually hard pressed to imagine a single entity site that will have only a single local subnet under an IP-v6 architecture. I tend to believe that IP-v6 architectures will be very different from our traditional IP-v4 concepts. My power, entertain, City, and communications company will probably allocate me one each from there individual spaces but I still think I will several of my own as I do today. Take care Terry -----Original Message----- From: Lea Roberts [mailto:lea.roberts at stanford.edu] Sent: Saturday, March 11, 2006 12:34 AM To: ppml at arin.net Subject: [ppml] a modified proposal 2005-8 was just sent in to ARIN... for your additional reading pleasure. /Lea Policy Proposal 2005-8, version 2: Proposal to amend ARIN IPv6 assignment and utilisation requirement This proposal would amend the IPv6 address allocation policies (ARIN's NRPM, section 6) regarding the definition of the default size of End Site assignments and the threshold value for End Site allocation efficiency, no longer assuming the fixed values for End Site assignments established by RFC3177. Many references to "/48" will need to be replaced by "End Site assignment". for example, section 6.5.4.1 should be replaced as follows: 6.5.4.1. Assignment address space size End Users are assigned an End Site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the End Site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): - /64 when it is known that one and only one subnet is needed - /56 for small sites, those expected to need only a few subnets over the next 5 years. - /48 for larger sites For end sites to whom DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to allow to simplify reverse lookup delegation. RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns. Accordingly, RIRs/NIRs will not request the detailed information on IPv6 user networks as they did in IPv4, except for the cases described in Section 6.4.4 and for the purposes of measuring utilization as defined in this document. also, section 6.9 will need to be replaced: 6.9. IPv6 Reassignments policy The size of IPv6 address assignments to End Sites is to be determined by the ISP/LIR. ISPs and LIRs may choose whether to make changes to their procedures for assigning address blocks to End Sites. The threshold End Site allocation efficiency level is between 20% to 50% for most ISPs and LIRs when based on a 0.94 HD Ratio. ISPs and LIRs will need to operate address plans according to this target level of End Site allocation efficiency. there's a need to change ARIN NRPM IPv6 Utilization: The ARIN NRPM Section 6.7 will be amended so its IPv6 allocation utilization criteria will reflect the use of a /56 as the unit quantity in the calculation of the ISP or LIR's end site allocation efficiency. Rationale: The current IPv6 Address Allocation and Assignment Policy (section 6 of ARIN's NRPM) indicates that end sites should be allocated a /48 as a uniform allocation unit if using more than one host or one subnet. This proposal alters the existing policy regarding LIR and ISP assignments to End Sites to allow the unit of assignment to be an LIR or ISP decision. In assessing the address utilization efficiency for ISPs or LIRs, the definition of an End Site for the purposes of the calculation of ISP or LIR End Site allocation efficiency, is to be made according to a /56 size. This measure, if undertaken generally by all RIRs, in conjunction with the further measures undertaken by the addressing community regarding increasing the HD ratio to 0.94, would increase the anticipated useful lifetime of IPv6 to encompass a period in excess of 100 years, in which case no further allocation policy changes would be anticipated. A more detailed rationale is available in Geoff Huston's presentation on the subject, at RIPE 50, which can be found at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-w ed-ipv6-roundtable-report.pdf ------------------------------------------------------------------------ Appendix A. References This material is not formally part of the Policy Proposal. It is included here for informational purposes. 1. The IPv6 Address Plan - Geoff Huston http://www.potaroo.net/ispcol/2005-07/ipv6size.html 2. Internet Draft: Issues Related to the Management of IPv6 Address Space - Thomas Narten http://tools.ietf.org/wg/ipv6/draft-narten-iana-rir-ipv6-considerations- 00.txt [unfortunately, the ID expired, so use the URL: http://www.cs.duke.edu/~narten/ietf/draft-narten-iana-rir-ipv6-considera tions-00.txt] 3. Internet Draft: IPv6 Address Allocation to End Sites - Thomas Narten, Geoff Huston & Lea Roberts http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary -01.txt _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From jason.schiller at mci.com Thu Mar 16 12:54:12 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Thu, 16 Mar 2006 12:54:12 -0500 (EST) Subject: [ppml] a modified proposal 2005-8 Message-ID: Some how this didn't get posted. ___Jason ---------- Forwarded message ---------- Date: Mon, 13 Mar 2006 11:58:49 -0500 (EST) From: "Jason Schiller (schiller at uu.net)" To: Lea Roberts Cc: Randy Bush , ppml at arin.net Subject: Re: [ppml] a modified proposal 2005-8 First let me say I think the policy is a good one. I agree with the general concept that we should consider moving away from "classful" and towards CIDR, and agree that the end site assignemnt should generally be between /64 and /48 and should not be "fixed values". The guidelines (and I understand they are just a guidelines) clearly defines the upper and lower bounds, but then offers a fixed value of a /56 for small sites, or /60 as some suggest. I guess I would like to see guidelines for how an ISP or LIR would determine best fit for an end site assignment that does not center around a fixed number such as /56 or /60 for small sites. I understand there is a trade off between aggregation and efficent use, and I understand aggregation is currently more important, but I'm not sure how much more important aggregation is over efficent use. Should an ISP plan for as many subnets as the end site could ever imagine using and then round up to the nearest CIDR? Should we plan for twice as many as thay can imaging using in the next 10 years and then round up? OR manybe the exact number of subnets today then rounded up to the nearest CIDR and then doubled? ___Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Sat, 11 Mar 2006, Lea Roberts wrote: > Date: Sat, 11 Mar 2006 16:44:36 -0800 (PST) > From: Lea Roberts > To: Randy Bush > Cc: ppml at arin.net > Subject: Re: [ppml] a modified proposal 2005-8 > > hi Randy - > > On Sat, 11 Mar 2006, Randy Bush wrote: > > > > The following guidelines may be useful (but they are only guidelines): > ^^^^^^^^^^^^^^^^^^^^^^^^ > > > > - /56 for small sites, those expected to need only a few subnets > > > over the next 5 years. > > > > 256 is a few? if you have to nibble away at it, isn't a /60 more > > like a few > > I don't disagree... we just put out some talking numbers and thank you > for your suggestion(s). I think one thing I would like to know is what > people think about providing generous assignments with the justification > being to make sure to provide flexibility to adapt to new architectures > that we have yet to imagine. That's been the argument for /48 everywhere > and I don't want to fall into the tighten it too much trap. I believe it > is *really* important to try to make sure that everyone who needs lots of > subnets can get them easily. This needs to be balanced against careless > waste of the address space. > > that said, do others think we should add the /60 "for a few" to the > guidelines? > > > > - /48 for larger sites > > > > i still do not understand why/how you are picking these points on > > the knob. what we really mean is allocate what is justifiable for > > the next few ( !=256 :-) years. > > Our goal is to provide some numbers for people with less clue than you. > Are you suggesting that we should assume a sufficient clue level for all > ISP/LIRs? > > > > For end sites to whom DNS will be delegated, the LIR/ISP > > ^ reverse > > thanks for this editorial suggestion. I will ask Einar to include it if > he can... thanks again, /Lea > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From Lee.Howard at stanleyassociates.com Thu Mar 16 16:45:01 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 16 Mar 2006 16:45:01 -0500 Subject: [ppml] a modified proposal 2005-8 Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4018CA8A2@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Davis, Terry L > Sent: Wednesday, March 15, 2006 10:29 PM > To: Houle, Joseph D (Joe), CMO > Cc: ppml at arin.net; bookeym at pachenalight.com > Subject: Re: [ppml] a modified proposal 2005-8 > > Joe > > Nope, you read it correctly! > > The power company will require your electrical systems to be on their > PLC networks in order to control your electrical systems; it > would make > a completely unworkable control and routing system for the electric > company to try to map the homeowners ISP assigned networks to > your home load controller. Why? They have to have a table mapping (IP) address to (home) address, so why does it matter if the IP address is theirs? > You will need to interface to their control center somehow to set your > home systems/load controllers and that could be via any available > networks but the actual controls will need to come in over their > networks. I'm trying to understand your position: The power company needs to build its own IP network in order to manage power systems at each home; their IP address assignments will be from their aggregatable block. > Likewise government would like to give each home a permanent > subnet from > "its addresses" for their use especially including advanced > EMS services > such that they can handle both 911 and direct fire alarms. I wouldn't > be surprised if in a couple decades, your home City/County has your > properties IP address on your deed. I would be surprised. IP addresses are not property, and are not transferable in that sense. > I already have two ISP's serving my home; cable and DSL both and will > probably add an EVDO link with a third. In my case, because of the > incredibly poor physical plant in my area, neither are very reliable. > > Try this list, you can validate it with some of the folks working > community networking: > - Internet Service Provider > - Entertainment Service Provider > - Home Application Service Provider > - Government Services > - Communication Service Provider > - Power Provider > - Metering Provider > - EMS (911 and fire alarm) > - Security Service Provider > > None of these will be a simple single IP address either as most will > have multiple controls or sensors serving your home. Would a /64 be sufficient for each, do you think? Especially if they're not from a single aggregate block, this would be important to understand. > > And no your ISP will NOT work as the sole provider of my home IP's! > I'll personally fight that on capital hill! This is the place to fight for that, not Capitol Hill. > We fought for the right not > to be forced to switch phone numbers when we move and I'm on > my 4th (or > 5th) ISP serving my home in the last ten years. (AT&T, Earthlink, > Qwest, MSN, Speakeasy, and Comcast, ok 6th) All of which provided me > with new IP's and email addresses which had no relation to any my > previous ones so I had to contact everyone I emailed with and > have them > update my email address. Bill paying services make this even > worse! It > takes months to get them all updated; one-at-a-time. Just to make sure I understand your position: You'd rather have nine provider aggregated addresses (counting networks above) than one (PI or PA) address? There are some differences here. Your choice of local phone carriers has been extremely limited. The local carrier has physical facilities to your house; now the cable company and power company also have facilities. An ISP provides a service using those facilities. They may provide multiple services, including routing (pretty essential, and requiring aggregatable addressing) and maybe also email, but these are disjoint: there's no reason your Internet access provider has to be your email provider. > This is exactly why I would prefer a local government provided IP that > was associated with my home address that didn't change until I moved! I must have misunderstood your previous points then. There are a lot of points to take away from this sentence: 1. "Local" government meaning city, county, state, federal, or some kind of regional Internet registry? 2. You want a government authority to replace the current system of IP address allocation? Can you outline the ways in which this is superior to the current system? 3. How would IP addresses be "associated with my home address"? Do you envision embedding physical address information in the IP address, like GPS coordinates, or a database owned and operated by the government? 4. How would routing work? Would every network have to carry a separate route for every home? Or do you mean that local governments should take over all Internet access? > And I certainly don't want to worry that if I change ISP, 911 or fire > won't be able to find me. Likewise I want to keep my phone > number when > I move and my email even if I have to change service providers. > > Sorry but my view of the future world has little to do with today's! That's fair to say. I don't quite understand whether you favor competition, monopolization, or nationalization. I'm hoping you can clarify how routing might work in your vision. I definitely advise you to take advantage of one of the many companies providing free email, so that you don't have to go through the pain of updating your contacts next time you switch ISPs. Or you can set up your own mail server, of course. Lee > > Take care > Terry > > -----Original Message----- > From: Houle, Joseph D (Joe), CMO [mailto:jdhoule at att.com] > Sent: Wednesday, March 15, 2006 4:13 PM > To: Davis, Terry L > Cc: Lea Roberts; ppml at arin.net > Subject: RE: [ppml] a modified proposal 2005-8 > > Terry: > I hope I am reading your last paragraph incorrectly? > Are you suggesting these other entities will "allocate to you a > subnet or an address" for devices on your location? > I would hope not, I would hope you have some number of subnets at > your location and these other entities will want to communicate with > some devices at your location which you have addressed from an > aggregated block. > Right? > > Joe Houle > > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of > Davis, Terry L > Sent: Saturday, March 11, 2006 3:57 PM > To: Lea Roberts; ppml at arin.net > Subject: Re: [ppml] a modified proposal 2005-8 > > Lea > > The proposal is fine. > > But I am actually hard pressed to imagine a single entity > site that will > have only a single local subnet under an IP-v6 architecture. > I tend to > believe that IP-v6 architectures will be very different from our > traditional IP-v4 concepts. > > My power, entertain, City, and communications company will probably > allocate me one each from there individual spaces but I still think I > will several of my own as I do today. > > Take care > Terry > > -----Original Message----- > From: Lea Roberts [mailto:lea.roberts at stanford.edu] > Sent: Saturday, March 11, 2006 12:34 AM > To: ppml at arin.net > Subject: [ppml] a modified proposal 2005-8 > > was just sent in to ARIN... for your additional reading > pleasure. /Lea > > Policy Proposal 2005-8, version 2: > > Proposal to amend ARIN IPv6 assignment and utilisation requirement > > This proposal would amend the IPv6 address allocation policies (ARIN's > NRPM, section 6) regarding the definition of the default size of End > Site assignments and the threshold value for End Site allocation > efficiency, no longer assuming the fixed values for End Site > assignments established by RFC3177. Many references to "/48" will > need to be replaced by "End Site assignment". > > for example, section 6.5.4.1 should be replaced as follows: > > 6.5.4.1. Assignment address space size > > End Users are assigned an End Site assignment from their LIR or > ISP. The exact size of the assignment is a local decision for the > LIR or ISP to make, using a minimum value of a /64 (when only one > subnet is anticipated for the End Site) up to the normal maximum > of /48, except in cases of extra large end sites where a larger > assignment can be justified. > > The following guidelines may be useful (but they are only > guidelines): > > - /64 when it is known that one and only one subnet is needed > > - /56 for small sites, those expected to need only a few subnets > over the next 5 years. > > - /48 for larger sites > > For end sites to whom DNS will be delegated, the LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to allow > to simplify reverse lookup delegation. > > RIRs/NIRs are not concerned about which address size an LIR/ISP > actually assigns. Accordingly, RIRs/NIRs will not request the > detailed information on IPv6 user networks as they did in IPv4, > except for the cases described in Section 6.4.4 and for the > purposes of measuring utilization as defined in this document. > > also, section 6.9 will need to be replaced: > > 6.9. IPv6 Reassignments policy > > The size of IPv6 address assignments to End Sites is to be > determined by the ISP/LIR. > > ISPs and LIRs may choose whether to make changes to their > procedures for assigning address blocks to End Sites. The threshold > End Site allocation efficiency level is between 20% to 50% for most > ISPs and LIRs when based on a 0.94 HD Ratio. ISPs and LIRs will > need to operate address plans according to this target level of End > Site allocation efficiency. > > > there's a need to change ARIN NRPM IPv6 Utilization: > > The ARIN NRPM Section 6.7 will be amended so its IPv6 allocation > utilization criteria will reflect the use of a /56 as the unit > quantity in the calculation of the ISP or LIR's end site allocation > efficiency. > > Rationale: > > The current IPv6 Address Allocation and Assignment Policy (section 6 > of ARIN's NRPM) indicates that end sites should be allocated a /48 as > a uniform allocation unit if using more than one host or one subnet. > > This proposal alters the existing policy regarding LIR and ISP > assignments to End Sites to allow the unit of assignment to be an LIR > or ISP decision. > > In assessing the address utilization efficiency for ISPs or LIRs, the > definition of an End Site for the purposes of the calculation of ISP > or LIR End Site allocation efficiency, is to be made > according to a /56 > size. > > This measure, if undertaken generally by all RIRs, in conjunction with > the further measures undertaken by the addressing community regarding > increasing the HD ratio to 0.94, would increase the anticipated useful > lifetime of IPv6 to encompass a period in excess of 100 years, in > which case no further allocation policy changes would be anticipated. > > > A more detailed rationale is available in Geoff Huston's > presentation on > the subject, at RIPE 50, which can be found at: > http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50 > -plenary-w > ed-ipv6-roundtable-report.pdf > > > > -------------------------------------------------------------- > ---------- > > Appendix A. References > This material is not formally part of the Policy Proposal. It is > included > here for informational purposes. > > 1. The IPv6 Address Plan - Geoff Huston > http://www.potaroo.net/ispcol/2005-07/ipv6size.html > > 2. Internet Draft: Issues Related to the Management of IPv6 Address > Space - > Thomas Narten > http://tools.ietf.org/wg/ipv6/draft-narten-iana-rir-ipv6-consi derations- > 00.txt > > [unfortunately, the ID expired, so use the URL: > > http://www.cs.duke.edu/~narten/ietf/draft-narten-iana-rir-ipv6 -considera > tions-00.txt] > > > 3. Internet Draft: IPv6 Address Allocation to End Sites - > Thomas Narten, > Geoff Huston & Lea Roberts > http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis- 48boundary > -01.txt > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From bonomi at mail.r-bonomi.com Thu Mar 16 17:04:03 2006 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Thu, 16 Mar 2006 16:04:03 -0600 (CST) Subject: [ppml] a modified proposal 2005-8 Message-ID: <200603162204.k2GM433n028760@s25.firmware.com> > Date: Thu, 16 Mar 2006 16:45:01 -0500 > From: "Howard, W. Lee" > Subject: Re: [ppml] a modified proposal 2005-8 > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > Behalf Of Davis, Terry L > > Sent: Wednesday, March 15, 2006 10:29 PM > > To: Houle, Joseph D (Joe), CMO > > Cc: ppml at arin.net; bookeym at pachenalight.com > > Subject: Re: [ppml] a modified proposal 2005-8 > > > > Joe > > > > Nope, you read it correctly! > > > > The power company will require your electrical systems to be on their > > PLC networks in order to control your electrical systems; it > > would make > > a completely unworkable control and routing system for the electric > > company to try to map the homeowners ISP assigned networks to > > your home load controller. > > Why? They have to have a table mapping (IP) address to (home) address, > so why does it matter if the IP address is theirs? The anser to that has to do with "O'Brien's Law". Which states rather pithily: "Murphy was an _optimist_!" Why the 'mapping table' approach won't work on the public IP network: *dynamic* IP addresses assigned by ISPs are subject to change at any time, without notice. IF the ISP changes your address, the utility 'mapping table' is obselete. Or, how about an ISP that uses RFC-1918 space internally, w/ NAT/PAT for that traffic that goes 'off net' to an external network? Every 'SYN' packet from your machine may have a _different_ source IP address at the destination. *WHICH* address should be in the 'mapping table'. If the utility does query/polling of your load controllers, you're running *servers*. this complicates ISP network architecture considerably. The utility has *GOOD* reasons to run a 'private' -- *not* connected to the public Internet for power-control functions. Contemplate what could happen if a hacker started 'spoofing' directives from the power company -- whether it be to 'shut down all equipment immediately', or to 'run everything at full power'. > > You will need to interface to their control center somehow to set your > > home systems/load controllers and that could be via any available > > networks but the actual controls will need to come in over their > > networks. > > I'm trying to understand your position: The power company needs to > build its own IP network in order to manage power systems at each > home; their IP address assignments will be from their aggregatable > block. *Yes*, they need their own _isolated_ network. _NO_, the IP address assignments on that network do not need to be from a block assigned for 'public internet' use. They can be from IPv4 RFC-1918 space, or an IPv6 equivalent, for example. Or, they _can_ be from a block of public internet addresses -- but they don't _have_ to be. Since it _is_ an *isolated* network, they could even use addresses in collision with use on the public Internet. > > > Likewise government would like to give each home a permanent > > subnet from > > "its addresses" for their use especially including advanced > > EMS services > > such that they can handle both 911 and direct fire alarms. I wouldn't > > be surprised if in a couple decades, your home City/County has your > > properties IP address on your deed. > > I would be surprised. IP addresses are not property, and are not > transferable in that sense. > > > I already have two ISP's serving my home; cable and DSL both and will > > probably add an EVDO link with a third. In my case, because of the > > incredibly poor physical plant in my area, neither are very reliable. > > > > Try this list, you can validate it with some of the folks working > > community networking: > > - Internet Service Provider > > - Entertainment Service Provider > > - Home Application Service Provider > > - Government Services > > - Communication Service Provider > > - Power Provider > > - Metering Provider > > - EMS (911 and fire alarm) > > - Security Service Provider > > > > None of these will be a simple single IP address either as most will > > have multiple controls or sensors serving your home. > > Would a /64 be sufficient for each, do you think? Especially if > they're not from a single aggregate block, this would be important > to understand. > > > > > And no your ISP will NOT work as the sole provider of my home IP's! > > I'll personally fight that on capital hill! > > This is the place to fight for that, not Capitol Hill. > > > We fought for the right not > > to be forced to switch phone numbers when we move and I'm on > > my 4th (or > > 5th) ISP serving my home in the last ten years. (AT&T, Earthlink, > > Qwest, MSN, Speakeasy, and Comcast, ok 6th) All of which provided me > > with new IP's and email addresses which had no relation to any my > > previous ones so I had to contact everyone I emailed with and > > have them > > update my email address. Bill paying services make this even > > worse! It > > takes months to get them all updated; one-at-a-time. > > Just to make sure I understand your position: > You'd rather have nine provider aggregated addresses (counting networks > above) than one (PI or PA) address? > > There are some differences here. Your choice of local phone carriers > has been extremely limited. The local carrier has physical facilities > to your house; now the cable company and power company also have > facilities. An ISP provides a service using those facilities. They > may provide multiple services, including routing (pretty essential, and > requiring aggregatable addressing) and maybe also email, but these are > disjoint: there's no reason your Internet access provider has to be your > > email provider. > > > > This is exactly why I would prefer a local government provided IP that > > was associated with my home address that didn't change until I moved! > > I must have misunderstood your previous points then. There are a lot > of points to take away from this sentence: > 1. "Local" government meaning city, county, state, federal, or some > kind of regional Internet registry? > 2. You want a government authority to replace the current system of IP > address allocation? Can you outline the ways in which this is superior > to the current system? > 3. How would IP addresses be "associated with my home address"? > Do you envision embedding physical address information in the IP > address, like GPS coordinates, or a database owned and operated by the > government? > 4. How would routing work? Would every network have to carry a > separate > route for every home? Or do you mean that local governments should > take over all Internet access? > > > And I certainly don't want to worry that if I change ISP, 911 or fire > > won't be able to find me. Likewise I want to keep my phone > > number when > > I move and my email even if I have to change service providers. > > > > Sorry but my view of the future world has little to do with today's! > > That's fair to say. I don't quite understand whether you favor > competition, monopolization, or nationalization. I'm hoping you can > clarify how routing might work in your vision. I definitely advise > you to take advantage of one of the many companies providing free > email, so that you don't have to go through the pain of updating your > contacts next time you switch ISPs. Or you can set up your own mail > server, of course. > > Lee > > > > > > Take care > > Terry > > > > -----Original Message----- > > From: Houle, Joseph D (Joe), CMO [mailto:jdhoule at att.com] > > Sent: Wednesday, March 15, 2006 4:13 PM > > To: Davis, Terry L > > Cc: Lea Roberts; ppml at arin.net > > Subject: RE: [ppml] a modified proposal 2005-8 > > > > Terry: > > I hope I am reading your last paragraph incorrectly? > > Are you suggesting these other entities will "allocate to you a > > subnet or an address" for devices on your location? > > I would hope not, I would hope you have some number of subnets at > > your location and these other entities will want to communicate with > > some devices at your location which you have addressed from an > > aggregated block. > > Right? > > > > Joe Houle > > > > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > Behalf Of > > Davis, Terry L > > Sent: Saturday, March 11, 2006 3:57 PM > > To: Lea Roberts; ppml at arin.net > > Subject: Re: [ppml] a modified proposal 2005-8 > > > > Lea > > > > The proposal is fine. > > > > But I am actually hard pressed to imagine a single entity > > site that will > > have only a single local subnet under an IP-v6 architecture. > > I tend to > > believe that IP-v6 architectures will be very different from our > > traditional IP-v4 concepts. > > > > My power, entertain, City, and communications company will probably > > allocate me one each from there individual spaces but I still think I > > will several of my own as I do today. > > > > Take care > > Terry > > > > -----Original Message----- > > From: Lea Roberts [mailto:lea.roberts at stanford.edu] > > Sent: Saturday, March 11, 2006 12:34 AM > > To: ppml at arin.net > > Subject: [ppml] a modified proposal 2005-8 > > > > was just sent in to ARIN... for your additional reading > > pleasure. /Lea > > > > Policy Proposal 2005-8, version 2: > > > > Proposal to amend ARIN IPv6 assignment and utilisation requirement > > > > This proposal would amend the IPv6 address allocation policies (ARIN's > > NRPM, section 6) regarding the definition of the default size of End > > Site assignments and the threshold value for End Site allocation > > efficiency, no longer assuming the fixed values for End Site > > assignments established by RFC3177. Many references to "/48" will > > need to be replaced by "End Site assignment". > > > > for example, section 6.5.4.1 should be replaced as follows: > > > > 6.5.4.1. Assignment address space size > > > > End Users are assigned an End Site assignment from their LIR or > > ISP. The exact size of the assignment is a local decision for the > > LIR or ISP to make, using a minimum value of a /64 (when only one > > subnet is anticipated for the End Site) up to the normal maximum > > of /48, except in cases of extra large end sites where a larger > > assignment can be justified. > > > > The following guidelines may be useful (but they are only > > guidelines): > > > > - /64 when it is known that one and only one subnet is needed > > > > - /56 for small sites, those expected to need only a few subnets > > over the next 5 years. > > > > - /48 for larger sites > > > > For end sites to whom DNS will be delegated, the LIR/ISP should > > consider making an assignment on a nibble (4-bit) boundary to allow > > to simplify reverse lookup delegation. > > > > RIRs/NIRs are not concerned about which address size an LIR/ISP > > actually assigns. Accordingly, RIRs/NIRs will not request the > > detailed information on IPv6 user networks as they did in IPv4, > > except for the cases described in Section 6.4.4 and for the > > purposes of measuring utilization as defined in this document. > > > > also, section 6.9 will need to be replaced: > > > > 6.9. IPv6 Reassignments policy > > > > The size of IPv6 address assignments to End Sites is to be > > determined by the ISP/LIR. > > > > ISPs and LIRs may choose whether to make changes to their > > procedures for assigning address blocks to End Sites. The threshold > > End Site allocation efficiency level is between 20% to 50% for most > > ISPs and LIRs when based on a 0.94 HD Ratio. ISPs and LIRs will > > need to operate address plans according to this target level of End > > Site allocation efficiency. > > > > > > there's a need to change ARIN NRPM IPv6 Utilization: > > > > The ARIN NRPM Section 6.7 will be amended so its IPv6 allocation > > utilization criteria will reflect the use of a /56 as the unit > > quantity in the calculation of the ISP or LIR's end site allocation > > efficiency. > > > > Rationale: > > > > The current IPv6 Address Allocation and Assignment Policy (section 6 > > of ARIN's NRPM) indicates that end sites should be allocated a /48 as > > a uniform allocation unit if using more than one host or one subnet. > > > > This proposal alters the existing policy regarding LIR and ISP > > assignments to End Sites to allow the unit of assignment to be an LIR > > or ISP decision. > > > > In assessing the address utilization efficiency for ISPs or LIRs, the > > definition of an End Site for the purposes of the calculation of ISP > > or LIR End Site allocation efficiency, is to be made > > according to a /56 > > size. > > > > This measure, if undertaken generally by all RIRs, in conjunction with > > the further measures undertaken by the addressing community regarding > > increasing the HD ratio to 0.94, would increase the anticipated useful > > lifetime of IPv6 to encompass a period in excess of 100 years, in > > which case no further allocation policy changes would be anticipated. > > > > > > A more detailed rationale is available in Geoff Huston's > > presentation on > > the subject, at RIPE 50, which can be found at: > > http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50 > > -plenary-w > > ed-ipv6-roundtable-report.pdf > > > > > > > > -------------------------------------------------------------- > > ---------- > > > > Appendix A. References > > This material is not formally part of the Policy Proposal. It is > > included > > here for informational purposes. > > > > 1. The IPv6 Address Plan - Geoff Huston > > http://www.potaroo.net/ispcol/2005-07/ipv6size.html > > > > 2. Internet Draft: Issues Related to the Management of IPv6 Address > > Space - > > Thomas Narten > > http://tools.ietf.org/wg/ipv6/draft-narten-iana-rir-ipv6-consi > derations- > > 00.txt > > > > [unfortunately, the ID expired, so use the URL: > > > > http://www.cs.duke.edu/~narten/ietf/draft-narten-iana-rir-ipv6 > -considera > > tions-00.txt] > > > > > > 3. Internet Draft: IPv6 Address Allocation to End Sites - > > Thomas Narten, > > Geoff Huston & Lea Roberts > > http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis- > 48boundary > > -01.txt > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From terry.l.davis at boeing.com Thu Mar 16 17:55:30 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Thu, 16 Mar 2006 14:55:30 -0800 Subject: [ppml] a modified proposal 2005-8 In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4018CA8A2@CL-S-EX-1.stanleyassociates.com> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BD13@XCH-NW-8V1.nw.nos.boeing.com> Lee Responses below. (All, apologies for the formatting. My responses are between the ++++ lines.) Take care Terry -----Original Message----- From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] Sent: Thursday, March 16, 2006 1:45 PM To: Davis, Terry L Cc: ppml at arin.net; bookeym at pachenalight.com Subject: RE: [ppml] a modified proposal 2005-8 > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Davis, Terry L > Sent: Wednesday, March 15, 2006 10:29 PM > To: Houle, Joseph D (Joe), CMO > Cc: ppml at arin.net; bookeym at pachenalight.com > Subject: Re: [ppml] a modified proposal 2005-8 > > Joe > > Nope, you read it correctly! > > The power company will require your electrical systems to be on their > PLC networks in order to control your electrical systems; it > would make > a completely unworkable control and routing system for the electric > company to try to map the homeowners ISP assigned networks to > your home load controller. Why? They have to have a table mapping (IP) address to (home) address, so why does it matter if the IP address is theirs? ++++++++++++++++++++++++++ If they don't go directly to the home, they will constantly be: - Unable to connect due home firewall/network changes - Have to deal with an IP churn rate per home that will force them to change approaching 20% of their entries annually because someone either moves or change service providers. - Will have to require their customers ALSO get an ISP to get load control service. ++++++++++++++++++++++++++ > You will need to interface to their control center somehow to set your > home systems/load controllers and that could be via any available > networks but the actual controls will need to come in over their > networks. I'm trying to understand your position: The power company needs to build its own IP network in order to manage power systems at each home; their IP address assignments will be from their aggregatable block. +++++++++++++++++++++++++ Correct. +++++++++++++++++++++++++ > Likewise government would like to give each home a permanent > subnet from > "its addresses" for their use especially including advanced > EMS services > such that they can handle both 911 and direct fire alarms. I wouldn't > be surprised if in a couple decades, your home City/County has your > properties IP address on your deed. I would be surprised. IP addresses are not property, and are not transferable in that sense. ++++++++++++++++++++++++++ We will see how it develops. My guess is that EMS will win although with IP-v6 they could certainly allocate the address portion of the space themselves to the property permanently and allow the network portion to change. ++++++++++++++++++++++++++ > I already have two ISP's serving my home; cable and DSL both and will > probably add an EVDO link with a third. In my case, because of the > incredibly poor physical plant in my area, neither are very reliable. > > Try this list, you can validate it with some of the folks working > community networking: > - Internet Service Provider > - Entertainment Service Provider > - Home Application Service Provider > - Government Services > - Communication Service Provider > - Power Provider > - Metering Provider > - EMS (911 and fire alarm) > - Security Service Provider > > None of these will be a simple single IP address either as most will > have multiple controls or sensors serving your home. Would a /64 be sufficient for each, do you think? Especially if they're not from a single aggregate block, this would be important to understand. +++++++++++++++++++++++++++ I would certainly think so. +++++++++++++++++++++++++++ > > And no your ISP will NOT work as the sole provider of my home IP's! > I'll personally fight that on capital hill! This is the place to fight for that, not Capitol Hill. ++++++++++++++++++++++++++++ I'd like to think so but history seems to say otherwise. ++++++++++++++++++++++++++++ > We fought for the right not > to be forced to switch phone numbers when we move and I'm on > my 4th (or > 5th) ISP serving my home in the last ten years. (AT&T, Earthlink, > Qwest, MSN, Speakeasy, and Comcast, ok 6th) All of which provided me > with new IP's and email addresses which had no relation to any my > previous ones so I had to contact everyone I emailed with and > have them > update my email address. Bill paying services make this even > worse! It > takes months to get them all updated; one-at-a-time. Just to make sure I understand your position: You'd rather have nine provider aggregated addresses (counting networks above) than one (PI or PA) address? +++++++++++++++++++++++++++++ I think that is what will happen. Whether I care or not depends on how well they can hide the details. Regardless which option wins, we cannot expect the average homeowner to be able to deal IP networking detail at this level. +++++++++++++++++++++++++++++ There are some differences here. Your choice of local phone carriers has been extremely limited. The local carrier has physical facilities to your house; now the cable company and power company also have facilities. An ISP provides a service using those facilities. They may provide multiple services, including routing (pretty essential, and requiring aggregatable addressing) and maybe also email, but these are disjoint: there's no reason your Internet access provider has to be your email provider. +++++++++++++++++++++++++++++ Agreed but what we have to do is figure out how to provide the homeowner at stable set of logical addresses (email/web/voice/etc) that map their physical ones. Otherwise I am certain that local government will win here. +++++++++++++++++++++++++++++ > This is exactly why I would prefer a local government provided IP that > was associated with my home address that didn't change until I moved! I must have misunderstood your previous points then. There are a lot of points to take away from this sentence: 1. "Local" government meaning city, county, state, federal, or some kind of regional Internet registry? +++++++++++++++++++++++++++++++++ The first four although the fifth could work. +++++++++++++++++++++++++++++++++ 2. You want a government authority to replace the current system of IP address allocation? Can you outline the ways in which this is superior to the current system? ++++++++++++++++++++++++++++++++++ NO, but that is what I will probably get. The reason is simple; they can provide me with a stable set of logical relationships that map to my physical home. A present this is simply not possible for a service provider to do. +++++++++++++++++++++++++++++++++++ 3. How would IP addresses be "associated with my home address"? Do you envision embedding physical address information in the IP address, like GPS coordinates, or a database owned and operated by the government? +++++++++++++++++++++++++++++++++++ I think that either GPS or a government DB is most likely. +++++++++++++++++++++++++++++++++++ 4. How would routing work? Would every network have to carry a Separate route for every home? Or do you mean that local governments should take over all Internet access? ++++++++++++++++++++++++++++++++++++ In the scenario I envision occurring, local government just becomes another "service provider" and each of the home service providers does their own routing. ++++++++++++++++++++++++++++++++++++ > And I certainly don't want to worry that if I change ISP, 911 or fire > won't be able to find me. Likewise I want to keep my phone > number when > I move and my email even if I have to change service providers. > > Sorry but my view of the future world has little to do with today's! That's fair to say. I don't quite understand whether you favor competition, monopolization, or nationalization. I'm hoping you can clarify how routing might work in your vision. I definitely advise you to take advantage of one of the many companies providing free email, so that you don't have to go through the pain of updating your contacts next time you switch ISPs. Or you can set up your own mail server, of course. +++++++++++++++++++++++++++++++++++++ I'm in favor of a solution that provides the home owner or individual with a set of "stable" logical relationships. I certainly won't go through a "free email provider" as I need them to both be around for the long term and to be responsible. As an example, I keep paying MSN monthly even though I have no used them as an ISP for over five years; this is simply to provide my wife a stable email for a large non-profit group she works with. It is that important! +++++++++++++++++++++++++++++++++++++ Lee > > Take care > Terry > > -----Original Message----- > From: Houle, Joseph D (Joe), CMO [mailto:jdhoule at att.com] > Sent: Wednesday, March 15, 2006 4:13 PM > To: Davis, Terry L > Cc: Lea Roberts; ppml at arin.net > Subject: RE: [ppml] a modified proposal 2005-8 > > Terry: > I hope I am reading your last paragraph incorrectly? > Are you suggesting these other entities will "allocate to you a > subnet or an address" for devices on your location? > I would hope not, I would hope you have some number of subnets at > your location and these other entities will want to communicate with > some devices at your location which you have addressed from an > aggregated block. > Right? > > Joe Houle > > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of > Davis, Terry L > Sent: Saturday, March 11, 2006 3:57 PM > To: Lea Roberts; ppml at arin.net > Subject: Re: [ppml] a modified proposal 2005-8 > > Lea > > The proposal is fine. > > But I am actually hard pressed to imagine a single entity > site that will > have only a single local subnet under an IP-v6 architecture. > I tend to > believe that IP-v6 architectures will be very different from our > traditional IP-v4 concepts. > > My power, entertain, City, and communications company will probably > allocate me one each from there individual spaces but I still think I > will several of my own as I do today. > > Take care > Terry > > -----Original Message----- > From: Lea Roberts [mailto:lea.roberts at stanford.edu] > Sent: Saturday, March 11, 2006 12:34 AM > To: ppml at arin.net > Subject: [ppml] a modified proposal 2005-8 > > was just sent in to ARIN... for your additional reading > pleasure. /Lea > > Policy Proposal 2005-8, version 2: > > Proposal to amend ARIN IPv6 assignment and utilisation requirement > > This proposal would amend the IPv6 address allocation policies (ARIN's > NRPM, section 6) regarding the definition of the default size of End > Site assignments and the threshold value for End Site allocation > efficiency, no longer assuming the fixed values for End Site > assignments established by RFC3177. Many references to "/48" will > need to be replaced by "End Site assignment". > > for example, section 6.5.4.1 should be replaced as follows: > > 6.5.4.1. Assignment address space size > > End Users are assigned an End Site assignment from their LIR or > ISP. The exact size of the assignment is a local decision for the > LIR or ISP to make, using a minimum value of a /64 (when only one > subnet is anticipated for the End Site) up to the normal maximum > of /48, except in cases of extra large end sites where a larger > assignment can be justified. > > The following guidelines may be useful (but they are only > guidelines): > > - /64 when it is known that one and only one subnet is needed > > - /56 for small sites, those expected to need only a few subnets > over the next 5 years. > > - /48 for larger sites > > For end sites to whom DNS will be delegated, the LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to allow > to simplify reverse lookup delegation. > > RIRs/NIRs are not concerned about which address size an LIR/ISP > actually assigns. Accordingly, RIRs/NIRs will not request the > detailed information on IPv6 user networks as they did in IPv4, > except for the cases described in Section 6.4.4 and for the > purposes of measuring utilization as defined in this document. > > also, section 6.9 will need to be replaced: > > 6.9. IPv6 Reassignments policy > > The size of IPv6 address assignments to End Sites is to be > determined by the ISP/LIR. > > ISPs and LIRs may choose whether to make changes to their > procedures for assigning address blocks to End Sites. The threshold > End Site allocation efficiency level is between 20% to 50% for most > ISPs and LIRs when based on a 0.94 HD Ratio. ISPs and LIRs will > need to operate address plans according to this target level of End > Site allocation efficiency. > > > there's a need to change ARIN NRPM IPv6 Utilization: > > The ARIN NRPM Section 6.7 will be amended so its IPv6 allocation > utilization criteria will reflect the use of a /56 as the unit > quantity in the calculation of the ISP or LIR's end site allocation > efficiency. > > Rationale: > > The current IPv6 Address Allocation and Assignment Policy (section 6 > of ARIN's NRPM) indicates that end sites should be allocated a /48 as > a uniform allocation unit if using more than one host or one subnet. > > This proposal alters the existing policy regarding LIR and ISP > assignments to End Sites to allow the unit of assignment to be an LIR > or ISP decision. > > In assessing the address utilization efficiency for ISPs or LIRs, the > definition of an End Site for the purposes of the calculation of ISP > or LIR End Site allocation efficiency, is to be made > according to a /56 > size. > > This measure, if undertaken generally by all RIRs, in conjunction with > the further measures undertaken by the addressing community regarding > increasing the HD ratio to 0.94, would increase the anticipated useful > lifetime of IPv6 to encompass a period in excess of 100 years, in > which case no further allocation policy changes would be anticipated. > > > A more detailed rationale is available in Geoff Huston's > presentation on > the subject, at RIPE 50, which can be found at: > http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50 > -plenary-w > ed-ipv6-roundtable-report.pdf > > > > -------------------------------------------------------------- > ---------- > > Appendix A. References > This material is not formally part of the Policy Proposal. It is > included > here for informational purposes. > > 1. The IPv6 Address Plan - Geoff Huston > http://www.potaroo.net/ispcol/2005-07/ipv6size.html > > 2. Internet Draft: Issues Related to the Management of IPv6 Address > Space - > Thomas Narten > http://tools.ietf.org/wg/ipv6/draft-narten-iana-rir-ipv6-consi derations- > 00.txt > > [unfortunately, the ID expired, so use the URL: > > http://www.cs.duke.edu/~narten/ietf/draft-narten-iana-rir-ipv6 -considera > tions-00.txt] > > > 3. Internet Draft: IPv6 Address Allocation to End Sites - > Thomas Narten, > Geoff Huston & Lea Roberts > http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis- 48boundary > -01.txt > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From terry.l.davis at boeing.com Thu Mar 16 18:00:23 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Thu, 16 Mar 2006 15:00:23 -0800 Subject: [ppml] a modified proposal 2005-8 In-Reply-To: <200603162204.k2GM433n028760@s25.firmware.com> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BD15@XCH-NW-8V1.nw.nos.boeing.com> Robert Obviously someone who has at least been around utility companies. Good responses. I think we will find a lot of industries that need their own separate networks as we grow the Internet. Take care Terry -----Original Message----- From: Robert Bonomi [mailto:bonomi at mail.r-bonomi.com] Sent: Thursday, March 16, 2006 2:04 PM To: ppml at arin.net Subject: Re: [ppml] a modified proposal 2005-8 > Date: Thu, 16 Mar 2006 16:45:01 -0500 > From: "Howard, W. Lee" > Subject: Re: [ppml] a modified proposal 2005-8 > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > Behalf Of Davis, Terry L > > Sent: Wednesday, March 15, 2006 10:29 PM > > To: Houle, Joseph D (Joe), CMO > > Cc: ppml at arin.net; bookeym at pachenalight.com > > Subject: Re: [ppml] a modified proposal 2005-8 > > > > Joe > > > > Nope, you read it correctly! > > > > The power company will require your electrical systems to be on their > > PLC networks in order to control your electrical systems; it > > would make > > a completely unworkable control and routing system for the electric > > company to try to map the homeowners ISP assigned networks to > > your home load controller. > > Why? They have to have a table mapping (IP) address to (home) address, > so why does it matter if the IP address is theirs? The anser to that has to do with "O'Brien's Law". Which states rather pithily: "Murphy was an _optimist_!" Why the 'mapping table' approach won't work on the public IP network: *dynamic* IP addresses assigned by ISPs are subject to change at any time, without notice. IF the ISP changes your address, the utility 'mapping table' is obselete. Or, how about an ISP that uses RFC-1918 space internally, w/ NAT/PAT for that traffic that goes 'off net' to an external network? Every 'SYN' packet from your machine may have a _different_ source IP address at the destination. *WHICH* address should be in the 'mapping table'. If the utility does query/polling of your load controllers, you're running *servers*. this complicates ISP network architecture considerably. The utility has *GOOD* reasons to run a 'private' -- *not* connected to the public Internet for power-control functions. Contemplate what could happen if a hacker started 'spoofing' directives from the power company -- whether it be to 'shut down all equipment immediately', or to 'run everything at full power'. > > You will need to interface to their control center somehow to set your > > home systems/load controllers and that could be via any available > > networks but the actual controls will need to come in over their > > networks. > > I'm trying to understand your position: The power company needs to > build its own IP network in order to manage power systems at each > home; their IP address assignments will be from their aggregatable > block. *Yes*, they need their own _isolated_ network. _NO_, the IP address assignments on that network do not need to be from a block assigned for 'public internet' use. They can be from IPv4 RFC-1918 space, or an IPv6 equivalent, for example. Or, they _can_ be from a block of public internet addresses -- but they don't _have_ to be. Since it _is_ an *isolated* network, they could even use addresses in collision with use on the public Internet. > > > Likewise government would like to give each home a permanent > > subnet from > > "its addresses" for their use especially including advanced > > EMS services > > such that they can handle both 911 and direct fire alarms. I wouldn't > > be surprised if in a couple decades, your home City/County has your > > properties IP address on your deed. > > I would be surprised. IP addresses are not property, and are not > transferable in that sense. > > > I already have two ISP's serving my home; cable and DSL both and will > > probably add an EVDO link with a third. In my case, because of the > > incredibly poor physical plant in my area, neither are very reliable. > > > > Try this list, you can validate it with some of the folks working > > community networking: > > - Internet Service Provider > > - Entertainment Service Provider > > - Home Application Service Provider > > - Government Services > > - Communication Service Provider > > - Power Provider > > - Metering Provider > > - EMS (911 and fire alarm) > > - Security Service Provider > > > > None of these will be a simple single IP address either as most will > > have multiple controls or sensors serving your home. > > Would a /64 be sufficient for each, do you think? Especially if > they're not from a single aggregate block, this would be important > to understand. > > > > > And no your ISP will NOT work as the sole provider of my home IP's! > > I'll personally fight that on capital hill! > > This is the place to fight for that, not Capitol Hill. > > > We fought for the right not > > to be forced to switch phone numbers when we move and I'm on > > my 4th (or > > 5th) ISP serving my home in the last ten years. (AT&T, Earthlink, > > Qwest, MSN, Speakeasy, and Comcast, ok 6th) All of which provided me > > with new IP's and email addresses which had no relation to any my > > previous ones so I had to contact everyone I emailed with and > > have them > > update my email address. Bill paying services make this even > > worse! It > > takes months to get them all updated; one-at-a-time. > > Just to make sure I understand your position: > You'd rather have nine provider aggregated addresses (counting networks > above) than one (PI or PA) address? > > There are some differences here. Your choice of local phone carriers > has been extremely limited. The local carrier has physical facilities > to your house; now the cable company and power company also have > facilities. An ISP provides a service using those facilities. They > may provide multiple services, including routing (pretty essential, and > requiring aggregatable addressing) and maybe also email, but these are > disjoint: there's no reason your Internet access provider has to be your > > email provider. > > > > This is exactly why I would prefer a local government provided IP that > > was associated with my home address that didn't change until I moved! > > I must have misunderstood your previous points then. There are a lot > of points to take away from this sentence: > 1. "Local" government meaning city, county, state, federal, or some > kind of regional Internet registry? > 2. You want a government authority to replace the current system of IP > address allocation? Can you outline the ways in which this is superior > to the current system? > 3. How would IP addresses be "associated with my home address"? > Do you envision embedding physical address information in the IP > address, like GPS coordinates, or a database owned and operated by the > government? > 4. How would routing work? Would every network have to carry a > separate > route for every home? Or do you mean that local governments should > take over all Internet access? > > > And I certainly don't want to worry that if I change ISP, 911 or fire > > won't be able to find me. Likewise I want to keep my phone > > number when > > I move and my email even if I have to change service providers. > > > > Sorry but my view of the future world has little to do with today's! > > That's fair to say. I don't quite understand whether you favor > competition, monopolization, or nationalization. I'm hoping you can > clarify how routing might work in your vision. I definitely advise > you to take advantage of one of the many companies providing free > email, so that you don't have to go through the pain of updating your > contacts next time you switch ISPs. Or you can set up your own mail > server, of course. > > Lee > > > > > > Take care > > Terry > > > > -----Original Message----- > > From: Houle, Joseph D (Joe), CMO [mailto:jdhoule at att.com] > > Sent: Wednesday, March 15, 2006 4:13 PM > > To: Davis, Terry L > > Cc: Lea Roberts; ppml at arin.net > > Subject: RE: [ppml] a modified proposal 2005-8 > > > > Terry: > > I hope I am reading your last paragraph incorrectly? > > Are you suggesting these other entities will "allocate to you a > > subnet or an address" for devices on your location? > > I would hope not, I would hope you have some number of subnets at > > your location and these other entities will want to communicate with > > some devices at your location which you have addressed from an > > aggregated block. > > Right? > > > > Joe Houle > > > > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > Behalf Of > > Davis, Terry L > > Sent: Saturday, March 11, 2006 3:57 PM > > To: Lea Roberts; ppml at arin.net > > Subject: Re: [ppml] a modified proposal 2005-8 > > > > Lea > > > > The proposal is fine. > > > > But I am actually hard pressed to imagine a single entity > > site that will > > have only a single local subnet under an IP-v6 architecture. > > I tend to > > believe that IP-v6 architectures will be very different from our > > traditional IP-v4 concepts. > > > > My power, entertain, City, and communications company will probably > > allocate me one each from there individual spaces but I still think I > > will several of my own as I do today. > > > > Take care > > Terry > > > > -----Original Message----- > > From: Lea Roberts [mailto:lea.roberts at stanford.edu] > > Sent: Saturday, March 11, 2006 12:34 AM > > To: ppml at arin.net > > Subject: [ppml] a modified proposal 2005-8 > > > > was just sent in to ARIN... for your additional reading > > pleasure. /Lea > > > > Policy Proposal 2005-8, version 2: > > > > Proposal to amend ARIN IPv6 assignment and utilisation requirement > > > > This proposal would amend the IPv6 address allocation policies (ARIN's > > NRPM, section 6) regarding the definition of the default size of End > > Site assignments and the threshold value for End Site allocation > > efficiency, no longer assuming the fixed values for End Site > > assignments established by RFC3177. Many references to "/48" will > > need to be replaced by "End Site assignment". > > > > for example, section 6.5.4.1 should be replaced as follows: > > > > 6.5.4.1. Assignment address space size > > > > End Users are assigned an End Site assignment from their LIR or > > ISP. The exact size of the assignment is a local decision for the > > LIR or ISP to make, using a minimum value of a /64 (when only one > > subnet is anticipated for the End Site) up to the normal maximum > > of /48, except in cases of extra large end sites where a larger > > assignment can be justified. > > > > The following guidelines may be useful (but they are only > > guidelines): > > > > - /64 when it is known that one and only one subnet is needed > > > > - /56 for small sites, those expected to need only a few subnets > > over the next 5 years. > > > > - /48 for larger sites > > > > For end sites to whom DNS will be delegated, the LIR/ISP should > > consider making an assignment on a nibble (4-bit) boundary to allow > > to simplify reverse lookup delegation. > > > > RIRs/NIRs are not concerned about which address size an LIR/ISP > > actually assigns. Accordingly, RIRs/NIRs will not request the > > detailed information on IPv6 user networks as they did in IPv4, > > except for the cases described in Section 6.4.4 and for the > > purposes of measuring utilization as defined in this document. > > > > also, section 6.9 will need to be replaced: > > > > 6.9. IPv6 Reassignments policy > > > > The size of IPv6 address assignments to End Sites is to be > > determined by the ISP/LIR. > > > > ISPs and LIRs may choose whether to make changes to their > > procedures for assigning address blocks to End Sites. The threshold > > End Site allocation efficiency level is between 20% to 50% for most > > ISPs and LIRs when based on a 0.94 HD Ratio. ISPs and LIRs will > > need to operate address plans according to this target level of End > > Site allocation efficiency. > > > > > > there's a need to change ARIN NRPM IPv6 Utilization: > > > > The ARIN NRPM Section 6.7 will be amended so its IPv6 allocation > > utilization criteria will reflect the use of a /56 as the unit > > quantity in the calculation of the ISP or LIR's end site allocation > > efficiency. > > > > Rationale: > > > > The current IPv6 Address Allocation and Assignment Policy (section 6 > > of ARIN's NRPM) indicates that end sites should be allocated a /48 as > > a uniform allocation unit if using more than one host or one subnet. > > > > This proposal alters the existing policy regarding LIR and ISP > > assignments to End Sites to allow the unit of assignment to be an LIR > > or ISP decision. > > > > In assessing the address utilization efficiency for ISPs or LIRs, the > > definition of an End Site for the purposes of the calculation of ISP > > or LIR End Site allocation efficiency, is to be made > > according to a /56 > > size. > > > > This measure, if undertaken generally by all RIRs, in conjunction with > > the further measures undertaken by the addressing community regarding > > increasing the HD ratio to 0.94, would increase the anticipated useful > > lifetime of IPv6 to encompass a period in excess of 100 years, in > > which case no further allocation policy changes would be anticipated. > > > > > > A more detailed rationale is available in Geoff Huston's > > presentation on > > the subject, at RIPE 50, which can be found at: > > http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50 > > -plenary-w > > ed-ipv6-roundtable-report.pdf > > > > > > > > -------------------------------------------------------------- > > ---------- > > > > Appendix A. References > > This material is not formally part of the Policy Proposal. It is > > included > > here for informational purposes. > > > > 1. The IPv6 Address Plan - Geoff Huston > > http://www.potaroo.net/ispcol/2005-07/ipv6size.html > > > > 2. Internet Draft: Issues Related to the Management of IPv6 Address > > Space - > > Thomas Narten > > http://tools.ietf.org/wg/ipv6/draft-narten-iana-rir-ipv6-consi > derations- > > 00.txt > > > > [unfortunately, the ID expired, so use the URL: > > > > http://www.cs.duke.edu/~narten/ietf/draft-narten-iana-rir-ipv6 > -considera > > tions-00.txt] > > > > > > 3. Internet Draft: IPv6 Address Allocation to End Sites - > > Thomas Narten, > > Geoff Huston & Lea Roberts > > http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis- > 48boundary > > -01.txt > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Fri Mar 17 04:44:48 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Mar 2006 01:44:48 -0800 Subject: [ppml] a modified proposal 2005-8 In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4018CA8A2@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB4018CA8A2@CL-S-EX-1.stanleyassoc iates.com> Message-ID: <9067F78C86A4BA5C261EE37F@odpwrbook.hq.netli.lan> > I'm trying to understand your position: The power company needs to > build its own IP network in order to manage power systems at each > home; their IP address assignments will be from their aggregatable > block. > Given the push for BPL, it is not unlikely that the power companies will simply implement BPL networks whether consumers use them for network access or not, and, use said BPL network as their preferred mechanism for device control. (Note, I am not a fan of BPL and I think the FCC made serious errors in allowing it to go forward. However, what I want to see happen to BPL and what I expect the power companies to do with it are separate discussions). >> Likewise government would like to give each home a permanent >> subnet from >> "its addresses" for their use especially including advanced >> EMS services >> such that they can handle both 911 and direct fire alarms. I wouldn't >> be surprised if in a couple decades, your home City/County has your >> properties IP address on your deed. > > I would be surprised. IP addresses are not property, and are not > transferable in that sense. > That's a political reality today. Transferability would only take a small amount of policy change. Finally, the IP address described in the paragraph above isn't being transferred, per se, the ownership or control of the resource remains with the RIR operated by the City or County. The deed merely contains the number as an additional piece of addressing data. Street addresses are not property and are not transferable in the sense you are thinking, either. They are, however, used to describe the location of parcels of property and do appear on deeds. >> I already have two ISP's serving my home; cable and DSL both and will >> probably add an EVDO link with a third. In my case, because of the >> incredibly poor physical plant in my area, neither are very reliable. >> >> Try this list, you can validate it with some of the folks working >> community networking: >> - Internet Service Provider >> - Entertainment Service Provider >> - Home Application Service Provider >> - Government Services >> - Communication Service Provider >> - Power Provider >> - Metering Provider >> - EMS (911 and fire alarm) >> - Security Service Provider >> >> None of these will be a simple single IP address either as most will >> have multiple controls or sensors serving your home. > > Would a /64 be sufficient for each, do you think? Especially if > they're not from a single aggregate block, this would be important > to understand. > A /64 per house would probably be fine for some of the things above. For some of them, a 128 per house might be adequate. For some, it will require more than one subnet (somewhere in the /48-/60 continuum, I would guess). >> >> And no your ISP will NOT work as the sole provider of my home IP's! >> I'll personally fight that on capital hill! > > This is the place to fight for that, not Capitol Hill. > If we fail to address it here, however, Capitol Hill will eventually do what they think is right. >> We fought for the right not >> to be forced to switch phone numbers when we move and I'm on >> my 4th (or >> 5th) ISP serving my home in the last ten years. (AT&T, Earthlink, >> Qwest, MSN, Speakeasy, and Comcast, ok 6th) All of which provided me >> with new IP's and email addresses which had no relation to any my >> previous ones so I had to contact everyone I emailed with and >> have them >> update my email address. Bill paying services make this even >> worse! It >> takes months to get them all updated; one-at-a-time. > > Just to make sure I understand your position: > You'd rather have nine provider aggregated addresses (counting networks > above) than one (PI or PA) address? > What I believe he is saying is that he would have 9 PA addresses used by the providers, but, that he wants a PI block in addition to that for his own use because he doesn't want to change his addresses just because his providers changed theirs when he moved. > There are some differences here. Your choice of local phone carriers > has been extremely limited. The local carrier has physical facilities > to your house; now the cable company and power company also have > facilities. An ISP provides a service using those facilities. They > may provide multiple services, including routing (pretty essential, and > requiring aggregatable addressing) and maybe also email, but these are > disjoint: there's no reason your Internet access provider has to be your > email provider. Given the ability to move a phone number from an ILEC/CLEC to a cellular provider, then move that number virtually anywhere in the US (and in some cases the world), the facilities argument about telephone carriers is much less relevant today than it used to be. Bottom line is that LNP as relates to NANP really does provide a good model for what we should at least view as a desirable goal for internet addressing. There will need to be changes to the current routing paradigm in order to facilitate this, but, right now, it seems like there isn't a lot of recognition that this is necessary by many of the parties involved in development. I'm not sure exactly which part of his view of the future he wants or expects either, Lee, but, I think that a future including a mixture of all of them is not that unlikely. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Lee.Howard at stanleyassociates.com Fri Mar 17 10:19:25 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 17 Mar 2006 10:19:25 -0500 Subject: [ppml] a modified proposal 2005-8 Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4018CAA39@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Robert Bonomi > Sent: Thursday, March 16, 2006 5:04 PM > To: ppml at arin.net > Subject: Re: [ppml] a modified proposal 2005-8 > > > Date: Thu, 16 Mar 2006 16:45:01 -0500 > > From: "Howard, W. Lee" > > Subject: Re: [ppml] a modified proposal 2005-8 > > > > > -----Original Message----- > > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > > Behalf Of Davis, Terry L > > > Sent: Wednesday, March 15, 2006 10:29 PM > > > To: Houle, Joseph D (Joe), CMO > > > Cc: ppml at arin.net; bookeym at pachenalight.com > > > Subject: Re: [ppml] a modified proposal 2005-8 > > > > > > Joe > > > > > > Nope, you read it correctly! > > > > > > The power company will require your electrical systems to > be on their > > > PLC networks in order to control your electrical systems; it > > > would make > > > a completely unworkable control and routing system for > the electric > > > company to try to map the homeowners ISP assigned networks to > > > your home load controller. > > > > Why? They have to have a table mapping (IP) address to > (home) address, > > so why does it matter if the IP address is theirs? > > *dynamic* IP addresses assigned by ISPs are subject to change > at any time, without notice. Do you advocate using dynamic assignments in IPv6? > Or, how about an ISP that uses RFC-1918 space internally, w/ > NAT/PAT for > that traffic that goes 'off net' to an external network? Every 'SYN' > packet from your machine may have a _different_ source IP > address at the > destination. *WHICH* address should be in the 'mapping table'. Do you advocate the use of private address space in IPv6? I think an internet draft is needed for that to occur. > If the utility does query/polling of your load controllers, > you're running > *servers*. this complicates ISP network architecture considerably. Servers are hosts. The bandwith may be lopsided a different way, but how much data are you planning to pull? Sorry, that's an engineering question, and not relevant. > The utility has *GOOD* reasons to run a 'private' -- *not* > connected to the > public Internet for power-control functions. Contemplate > what could happen > if a hacker started 'spoofing' directives from the power > company -- whether > it be to 'shut down all equipment immediately', or to 'run > everything at full power'. Security considerations are a good answer. So you expect there to be nine separate networks to each home? > > > You will need to interface to their control center > somehow to set your > > > home systems/load controllers and that could be via any available > > > networks but the actual controls will need to come in over their > > > networks. > > > > I'm trying to understand your position: The power company needs to > > build its own IP network in order to manage power systems at each > > home; their IP address assignments will be from their aggregatable > > block. > > *Yes*, they need their own _isolated_ network. > _NO_, the IP address assignments on that network do not need > to be from a > block assigned for 'public internet' use. They can be from > IPv4 RFC-1918 > space, or an IPv6 equivalent, for example. You will need to submit an internet draft to the appropriate IETF working group. > Or, they _can_ be from a block > of public internet addresses -- but they don't _have_ to be. > Since it _is_ > an *isolated* network, they could even use addresses in > collision with use on the public Internet. What policy are you advocating for or against? I'm not trying to engineer networks, I'm trying to understand what opinions are being expressed. Should each network (service provider?) assign addresses from its own block, or should each residence be assigned addresses from a portable block? Are we talking about a /64 for a home, or some other size, and is that per network, per resident, per device, or what? Lee From Lee.Howard at stanleyassociates.com Fri Mar 17 10:43:50 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 17 Mar 2006 10:43:50 -0500 Subject: [ppml] a modified proposal 2005-8 Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4018CAA64@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: Davis, Terry L [mailto:terry.l.davis at boeing.com] > Sent: Thursday, March 16, 2006 5:56 PM > To: Howard, W. Lee > Cc: ppml at arin.net; bookeym at pachenalight.com > Subject: RE: [ppml] a modified proposal 2005-8 > > Lee > > Responses below. > > (All, apologies for the formatting. My responses are between the ++++ > lines.) That does make it challenging to respond. In my responses below, I'm trying to point out that this is where we set IP address allocation policies, and in order for your participation to be effective, you need to describe what policy you would like to see. > Take care > Terry > > -----Original Message----- > From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] > Sent: Thursday, March 16, 2006 1:45 PM > To: Davis, Terry L > Cc: ppml at arin.net; bookeym at pachenalight.com > Subject: RE: [ppml] a modified proposal 2005-8 > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > Behalf Of Davis, Terry L > > Sent: Wednesday, March 15, 2006 10:29 PM > > To: Houle, Joseph D (Joe), CMO > > Cc: ppml at arin.net; bookeym at pachenalight.com > > Subject: Re: [ppml] a modified proposal 2005-8 > > > > Joe > > > > Nope, you read it correctly! > > > > The power company will require your electrical systems to > be on their > > PLC networks in order to control your electrical systems; it > > would make > > a completely unworkable control and routing system for the electric > > company to try to map the homeowners ISP assigned networks to > > your home load controller. > > Why? They have to have a table mapping (IP) address to > (home) address, > so why does it matter if the IP address is theirs? > ++++++++++++++++++++++++++ > If they don't go directly to the home, they will constantly be: > - Unable to connect due home firewall/network changes > - Have to deal with an IP churn rate per home that will force them to > change approaching 20% of their entries annually because > someone either > moves or change service providers. > - Will have to require their customers ALSO get an ISP to get load > control service. > ++++++++++++++++++++++++++ I understand 1 and 3, but I don't follow your middle point. You suggested government assignment, either to a physical address, in which case there's no churn, or to an owner, in which case the churn would happen anyway due to moves, regardless of whether the address was assigned by utility or government. > > You will need to interface to their control center somehow > to set your > > home systems/load controllers and that could be via any available > > networks but the actual controls will need to come in over their > > networks. > > I'm trying to understand your position: The power company needs to > build its own IP network in order to manage power systems at each > home; their IP address assignments will be from their aggregatable > block. > +++++++++++++++++++++++++ > Correct. > +++++++++++++++++++++++++ > > > Likewise government would like to give each home a permanent > > subnet from > > "its addresses" for their use especially including advanced > > EMS services > > such that they can handle both 911 and direct fire alarms. > I wouldn't > > be surprised if in a couple decades, your home City/County has your > > properties IP address on your deed. > > I would be surprised. IP addresses are not property, and are not > transferable in that sense. > ++++++++++++++++++++++++++ > We will see how it develops. My guess is that EMS will win although > with IP-v6 they could certainly allocate the address portion of the > space themselves to the property permanently and allow the network > portion to change. > ++++++++++++++++++++++++++ EMS will win what? I didn't know there was a contest. IP addresses are not property. They are identifying numbers, which are allocated or assigned based on policies created by the public and administered by the Regional Internet Registries, such as ARIN. They are fungible, and cannot be owned, bought or sold. > > I already have two ISP's serving my home; cable and DSL > both and will > > probably add an EVDO link with a third. In my case, because of the > > incredibly poor physical plant in my area, neither are very > reliable. > > > > Try this list, you can validate it with some of the folks working > > community networking: > > - Internet Service Provider > > - Entertainment Service Provider > > - Home Application Service Provider > > - Government Services > > - Communication Service Provider > > - Power Provider > > - Metering Provider > > - EMS (911 and fire alarm) > > - Security Service Provider > > > > None of these will be a simple single IP address either as most will > > have multiple controls or sensors serving your home. > > Would a /64 be sufficient for each, do you think? Especially if > they're not from a single aggregate block, this would be important > to understand. > +++++++++++++++++++++++++++ > I would certainly think so. > +++++++++++++++++++++++++++ > > > > > And no your ISP will NOT work as the sole provider of my home IP's! > > I'll personally fight that on capital hill! > > This is the place to fight for that, not Capitol Hill. > ++++++++++++++++++++++++++++ > I'd like to think so but history seems to say otherwise. > ++++++++++++++++++++++++++++ Please explain. > > We fought for the right not > > to be forced to switch phone numbers when we move and I'm on > > my 4th (or > > 5th) ISP serving my home in the last ten years. (AT&T, Earthlink, > > Qwest, MSN, Speakeasy, and Comcast, ok 6th) All of which > provided me > > with new IP's and email addresses which had no relation to any my > > previous ones so I had to contact everyone I emailed with and > > have them > > update my email address. Bill paying services make this even > > worse! It > > takes months to get them all updated; one-at-a-time. > > Just to make sure I understand your position: > You'd rather have nine provider aggregated addresses > (counting networks > above) than one (PI or PA) address? > +++++++++++++++++++++++++++++ > I think that is what will happen. Whether I care or not > depends on how > well they can hide the details. Regardless which option > wins, we cannot > expect the average homeowner to be able to deal IP networking > detail at this level. > +++++++++++++++++++++++++++++ What do you want to have happen? Can you explain how one plan or another affects homeowners? > There are some differences here. Your choice of local phone carriers > has been extremely limited. The local carrier has physical facilities > to your house; now the cable company and power company also have > facilities. An ISP provides a service using those facilities. They > may provide multiple services, including routing (pretty > essential, and > requiring aggregatable addressing) and maybe also email, but > these are > disjoint: there's no reason your Internet access provider has > to be your > email provider. > +++++++++++++++++++++++++++++ > Agreed but what we have to do is figure out how to provide > the homeowner > at stable set of logical addresses (email/web/voice/etc) that > map their > physical ones. Otherwise I am certain that local government will win > here. > +++++++++++++++++++++++++++++ Again, win what? Since ARIN only administers IP addresses, can we discuss those separately? Is it necessary for email address, web site, and phone number to be permanently mapped to an IP address? Are no dynamic mappings possible which might make the IP address transparent to the homeowner? > > This is exactly why I would prefer a local government > provided IP that > > was associated with my home address that didn't change > until I moved! > > I must have misunderstood your previous points then. There are a lot > of points to take away from this sentence: > 1. "Local" government meaning city, county, state, federal, or some > kind of regional Internet registry? > +++++++++++++++++++++++++++++++++ > The first four although the fifth could work. > +++++++++++++++++++++++++++++++++ In order to derive a policy, we need more detail. What do you advocate? > 2. You want a government authority to replace the current > system of IP > address allocation? Can you outline the ways in which this > is superior > to the current system? > ++++++++++++++++++++++++++++++++++ > NO, but that is what I will probably get. The reason is simple; they > can provide me with a stable set of logical relationships > that map to my > physical home. A present this is simply not possible for a service > provider to do. > +++++++++++++++++++++++++++++++++++ Then what do you want? > > 3. How would IP addresses be "associated with my home address"? > Do you envision embedding physical address information in the IP > address, like GPS coordinates, or a database owned and operated by the > government? > +++++++++++++++++++++++++++++++++++ > I think that either GPS or a government DB is most likely. > +++++++++++++++++++++++++++++++++++ Is that what you want? Can you provide a way of embedding GPS coordinates into IPv6 addresses? Does it scale? Can you describe such a government database? Maintainer, schema, etc. How would either of these be routed? > > 4. How would routing work? Would every network have to carry a > Separate route for every home? Or do you mean that local governments > should take over all Internet access? > ++++++++++++++++++++++++++++++++++++ > In the scenario I envision occurring, local government just becomes > another "service provider" and each of the home service providers does > their own routing. > ++++++++++++++++++++++++++++++++++++ I'm not quite sure I followed that. The local government becomes the Internet access provider? Or do they provide some other service? If the government assigns an address to be used by all of the other providers, there are significant routing implications. If there's any competition, then addresses cannot be aggregated, and a separate routing entry will have to be maintained for each address. Can you describe how that would scale, given even optimistic technology projections? If there's no competition, then we have nine completely separate networks, which do not overlap anywhere and cannot inter- connect. Also, a different form of government and economy. > > And I certainly don't want to worry that if I change ISP, > 911 or fire > > won't be able to find me. Likewise I want to keep my phone > > number when > > I move and my email even if I have to change service providers. > > > > Sorry but my view of the future world has little to do with today's! > > That's fair to say. I don't quite understand whether you favor > competition, monopolization, or nationalization. I'm hoping you can > clarify how routing might work in your vision. I definitely advise > you to take advantage of one of the many companies providing free > email, so that you don't have to go through the pain of updating your > contacts next time you switch ISPs. Or you can set up your own mail > server, of course. > +++++++++++++++++++++++++++++++++++++ > I'm in favor of a solution that provides the home owner or individual > with a set of "stable" logical relationships. I certainly won't go > through a "free email provider" as I need them to both be > around for the > long term and to be responsible. As an example, I keep paying MSN > monthly even though I have no used them as an ISP for over five years; > this is simply to provide my wife a stable email for a large > non-profit > group she works with. It is that important! > +++++++++++++++++++++++++++++++++++++ If I have correctly interpreted your arguments, you advocate government control of networks and centralized, rigidly hierarchical networks which map exactly to geography. You also want those networks to map exactly to individuals, which seems to be a conflict. Perhaps smooth dynamic mappings between identifiers would require fewer fundamental changes to TCP/IP. Lee From terry.l.davis at boeing.com Fri Mar 17 11:33:23 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Fri, 17 Mar 2006 08:33:23 -0800 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4018CAA64@CL-S-EX-1.stanleyassociates.com> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BD22@XCH-NW-8V1.nw.nos.boeing.com> Lee My main point is that we cannot plan for an IP-v6 world using IP-v4 templates. The key messages: 1) We MUST provider users (individuals/government/business) with logical stability. Getting new IP addresses, DNS names, and email addresses every time we either change providers or move will simply be unacceptable. Without this logical stability, every communication service (voice/email/etc) is unstable, industry-wide initiatives (i.e. like power control) are not possible, and even gains the financial institutions hope to make with EFT systems become limited (i.e. remember the fun of resetting all your automatic billings/payments email addresses last time you changed service providers?). I know this may be more an IETF issue but I'm there next week. 2) Assuming that any users (individuals/government/business) will have a single service provider is completely unrealistic. (Much of point in the chain below) We need to understand impacts of this to IP-v6 network architectures and routing. (I'm already dealing with this reality in the aviation industry as we plan for IP-v6. The aircraft MUST be able to join to many different service provider networks as it moves around the world; we have carriers that fly there aircraft literally around the world in a bit over a day. The aircraft WILL most of the time have simultaneous links to multiple service providers. An aircraft will probably have at least three separate networks onboard: air traffic control, airline or operator, and in-flight passenger services/entertainment.) 3) Besides government, whole industries will want address blocks that they manage as closed network; these may be at the regional, national, or global level. Power, shipping, and aviation are some that will almost certainly require this. 4) We might as well come to terms with the idea that some of these must be essentially irrevocable. Can anyone envision revoking the IP address of an aircraft that is set up in air traffic control systems around the world? I doubt that I can make the ARIN meeting in Montreal but I will try. Take care Terry -----Original Message----- From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] Sent: Friday, March 17, 2006 7:44 AM To: Davis, Terry L Cc: ppml at arin.net Subject: RE: [ppml] a modified proposal 2005-8 > -----Original Message----- > From: Davis, Terry L [mailto:terry.l.davis at boeing.com] > Sent: Thursday, March 16, 2006 5:56 PM > To: Howard, W. Lee > Cc: ppml at arin.net; bookeym at pachenalight.com > Subject: RE: [ppml] a modified proposal 2005-8 > > Lee > > Responses below. > > (All, apologies for the formatting. My responses are between the ++++ > lines.) That does make it challenging to respond. In my responses below, I'm trying to point out that this is where we set IP address allocation policies, and in order for your participation to be effective, you need to describe what policy you would like to see. > Take care > Terry > > -----Original Message----- > From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] > Sent: Thursday, March 16, 2006 1:45 PM > To: Davis, Terry L > Cc: ppml at arin.net; bookeym at pachenalight.com > Subject: RE: [ppml] a modified proposal 2005-8 > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > Behalf Of Davis, Terry L > > Sent: Wednesday, March 15, 2006 10:29 PM > > To: Houle, Joseph D (Joe), CMO > > Cc: ppml at arin.net; bookeym at pachenalight.com > > Subject: Re: [ppml] a modified proposal 2005-8 > > > > Joe > > > > Nope, you read it correctly! > > > > The power company will require your electrical systems to > be on their > > PLC networks in order to control your electrical systems; it > > would make > > a completely unworkable control and routing system for the electric > > company to try to map the homeowners ISP assigned networks to > > your home load controller. > > Why? They have to have a table mapping (IP) address to > (home) address, > so why does it matter if the IP address is theirs? > ++++++++++++++++++++++++++ > If they don't go directly to the home, they will constantly be: > - Unable to connect due home firewall/network changes > - Have to deal with an IP churn rate per home that will force them to > change approaching 20% of their entries annually because > someone either > moves or change service providers. > - Will have to require their customers ALSO get an ISP to get load > control service. > ++++++++++++++++++++++++++ I understand 1 and 3, but I don't follow your middle point. You suggested government assignment, either to a physical address, in which case there's no churn, or to an owner, in which case the churn would happen anyway due to moves, regardless of whether the address was assigned by utility or government. > > You will need to interface to their control center somehow > to set your > > home systems/load controllers and that could be via any available > > networks but the actual controls will need to come in over their > > networks. > > I'm trying to understand your position: The power company needs to > build its own IP network in order to manage power systems at each > home; their IP address assignments will be from their aggregatable > block. > +++++++++++++++++++++++++ > Correct. > +++++++++++++++++++++++++ > > > Likewise government would like to give each home a permanent > > subnet from > > "its addresses" for their use especially including advanced > > EMS services > > such that they can handle both 911 and direct fire alarms. > I wouldn't > > be surprised if in a couple decades, your home City/County has your > > properties IP address on your deed. > > I would be surprised. IP addresses are not property, and are not > transferable in that sense. > ++++++++++++++++++++++++++ > We will see how it develops. My guess is that EMS will win although > with IP-v6 they could certainly allocate the address portion of the > space themselves to the property permanently and allow the network > portion to change. > ++++++++++++++++++++++++++ EMS will win what? I didn't know there was a contest. IP addresses are not property. They are identifying numbers, which are allocated or assigned based on policies created by the public and administered by the Regional Internet Registries, such as ARIN. They are fungible, and cannot be owned, bought or sold. > > I already have two ISP's serving my home; cable and DSL > both and will > > probably add an EVDO link with a third. In my case, because of the > > incredibly poor physical plant in my area, neither are very > reliable. > > > > Try this list, you can validate it with some of the folks working > > community networking: > > - Internet Service Provider > > - Entertainment Service Provider > > - Home Application Service Provider > > - Government Services > > - Communication Service Provider > > - Power Provider > > - Metering Provider > > - EMS (911 and fire alarm) > > - Security Service Provider > > > > None of these will be a simple single IP address either as most will > > have multiple controls or sensors serving your home. > > Would a /64 be sufficient for each, do you think? Especially if > they're not from a single aggregate block, this would be important > to understand. > +++++++++++++++++++++++++++ > I would certainly think so. > +++++++++++++++++++++++++++ > > > > > And no your ISP will NOT work as the sole provider of my home IP's! > > I'll personally fight that on capital hill! > > This is the place to fight for that, not Capitol Hill. > ++++++++++++++++++++++++++++ > I'd like to think so but history seems to say otherwise. > ++++++++++++++++++++++++++++ Please explain. > > We fought for the right not > > to be forced to switch phone numbers when we move and I'm on > > my 4th (or > > 5th) ISP serving my home in the last ten years. (AT&T, Earthlink, > > Qwest, MSN, Speakeasy, and Comcast, ok 6th) All of which > provided me > > with new IP's and email addresses which had no relation to any my > > previous ones so I had to contact everyone I emailed with and > > have them > > update my email address. Bill paying services make this even > > worse! It > > takes months to get them all updated; one-at-a-time. > > Just to make sure I understand your position: > You'd rather have nine provider aggregated addresses > (counting networks > above) than one (PI or PA) address? > +++++++++++++++++++++++++++++ > I think that is what will happen. Whether I care or not > depends on how > well they can hide the details. Regardless which option > wins, we cannot > expect the average homeowner to be able to deal IP networking > detail at this level. > +++++++++++++++++++++++++++++ What do you want to have happen? Can you explain how one plan or another affects homeowners? > There are some differences here. Your choice of local phone carriers > has been extremely limited. The local carrier has physical facilities > to your house; now the cable company and power company also have > facilities. An ISP provides a service using those facilities. They > may provide multiple services, including routing (pretty > essential, and > requiring aggregatable addressing) and maybe also email, but > these are > disjoint: there's no reason your Internet access provider has > to be your > email provider. > +++++++++++++++++++++++++++++ > Agreed but what we have to do is figure out how to provide > the homeowner > at stable set of logical addresses (email/web/voice/etc) that > map their > physical ones. Otherwise I am certain that local government will win > here. > +++++++++++++++++++++++++++++ Again, win what? Since ARIN only administers IP addresses, can we discuss those separately? Is it necessary for email address, web site, and phone number to be permanently mapped to an IP address? Are no dynamic mappings possible which might make the IP address transparent to the homeowner? > > This is exactly why I would prefer a local government > provided IP that > > was associated with my home address that didn't change > until I moved! > > I must have misunderstood your previous points then. There are a lot > of points to take away from this sentence: > 1. "Local" government meaning city, county, state, federal, or some > kind of regional Internet registry? > +++++++++++++++++++++++++++++++++ > The first four although the fifth could work. > +++++++++++++++++++++++++++++++++ In order to derive a policy, we need more detail. What do you advocate? > 2. You want a government authority to replace the current > system of IP > address allocation? Can you outline the ways in which this > is superior > to the current system? > ++++++++++++++++++++++++++++++++++ > NO, but that is what I will probably get. The reason is simple; they > can provide me with a stable set of logical relationships > that map to my > physical home. A present this is simply not possible for a service > provider to do. > +++++++++++++++++++++++++++++++++++ Then what do you want? > > 3. How would IP addresses be "associated with my home address"? > Do you envision embedding physical address information in the IP > address, like GPS coordinates, or a database owned and operated by the > government? > +++++++++++++++++++++++++++++++++++ > I think that either GPS or a government DB is most likely. > +++++++++++++++++++++++++++++++++++ Is that what you want? Can you provide a way of embedding GPS coordinates into IPv6 addresses? Does it scale? Can you describe such a government database? Maintainer, schema, etc. How would either of these be routed? > > 4. How would routing work? Would every network have to carry a > Separate route for every home? Or do you mean that local governments > should take over all Internet access? > ++++++++++++++++++++++++++++++++++++ > In the scenario I envision occurring, local government just becomes > another "service provider" and each of the home service providers does > their own routing. > ++++++++++++++++++++++++++++++++++++ I'm not quite sure I followed that. The local government becomes the Internet access provider? Or do they provide some other service? If the government assigns an address to be used by all of the other providers, there are significant routing implications. If there's any competition, then addresses cannot be aggregated, and a separate routing entry will have to be maintained for each address. Can you describe how that would scale, given even optimistic technology projections? If there's no competition, then we have nine completely separate networks, which do not overlap anywhere and cannot inter- connect. Also, a different form of government and economy. > > And I certainly don't want to worry that if I change ISP, > 911 or fire > > won't be able to find me. Likewise I want to keep my phone > > number when > > I move and my email even if I have to change service providers. > > > > Sorry but my view of the future world has little to do with today's! > > That's fair to say. I don't quite understand whether you favor > competition, monopolization, or nationalization. I'm hoping you can > clarify how routing might work in your vision. I definitely advise > you to take advantage of one of the many companies providing free > email, so that you don't have to go through the pain of updating your > contacts next time you switch ISPs. Or you can set up your own mail > server, of course. > +++++++++++++++++++++++++++++++++++++ > I'm in favor of a solution that provides the home owner or individual > with a set of "stable" logical relationships. I certainly won't go > through a "free email provider" as I need them to both be > around for the > long term and to be responsible. As an example, I keep paying MSN > monthly even though I have no used them as an ISP for over five years; > this is simply to provide my wife a stable email for a large > non-profit > group she works with. It is that important! > +++++++++++++++++++++++++++++++++++++ If I have correctly interpreted your arguments, you advocate government control of networks and centralized, rigidly hierarchical networks which map exactly to geography. You also want those networks to map exactly to individuals, which seems to be a conflict. Perhaps smooth dynamic mappings between identifiers would require fewer fundamental changes to TCP/IP. Lee From tme at multicasttech.com Fri Mar 17 11:45:47 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 17 Mar 2006 11:45:47 -0500 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BD22@XCH-NW-8V1.nw.nos.boeing.com> References: <0D090F1E0F5536449C7E6527AFFA280A21BD22@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: <5937FAAF-2B5F-4C4F-B210-CD01C0761340@multicasttech.com> To extend your example at little, would you envision each Aircraft as being its own Autonomous System ? And, if not, why not ? Regards Marshall On Mar 17, 2006, at 11:33 AM, Davis, Terry L wrote: > Lee > > My main point is that we cannot plan for an IP-v6 world using IP-v4 > templates. The key messages: > > 1) We MUST provider users (individuals/government/business) with > logical > stability. Getting new IP addresses, DNS names, and email addresses > every time we either change providers or move will simply be > unacceptable. Without this logical stability, every communication > service (voice/email/etc) is unstable, industry-wide initiatives (i.e. > like power control) are not possible, and even gains the financial > institutions hope to make with EFT systems become limited (i.e. > remember > the fun of resetting all your automatic billings/payments email > addresses last time you changed service providers?). I know this > may be > more an IETF issue but I'm there next week. > > 2) Assuming that any users (individuals/government/business) will > have a > single service provider is completely unrealistic. (Much of point in > the chain below) We need to understand impacts of this to IP-v6 > network > architectures and routing. > > (I'm already dealing with this reality in the aviation industry as we > plan for IP-v6. The aircraft MUST be able to join to many different > service provider networks as it moves around the world; we have > carriers > that fly there aircraft literally around the world in a bit over a > day. > The aircraft WILL most of the time have simultaneous links to multiple > service providers. An aircraft will probably have at least three > separate networks onboard: air traffic control, airline or > operator, and > in-flight passenger services/entertainment.) > > 3) Besides government, whole industries will want address blocks that > they manage as closed network; these may be at the regional, national, > or global level. Power, shipping, and aviation are some that will > almost certainly require this. > > 4) We might as well come to terms with the idea that some of these > must > be essentially irrevocable. Can anyone envision revoking the IP > address > of an aircraft that is set up in air traffic control systems around > the > world? > > I doubt that I can make the ARIN meeting in Montreal but I will try. > > Take care > Terry > > -----Original Message----- > From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] > Sent: Friday, March 17, 2006 7:44 AM > To: Davis, Terry L > Cc: ppml at arin.net > Subject: RE: [ppml] a modified proposal 2005-8 > >> -----Original Message----- >> From: Davis, Terry L [mailto:terry.l.davis at boeing.com] >> Sent: Thursday, March 16, 2006 5:56 PM >> To: Howard, W. Lee >> Cc: ppml at arin.net; bookeym at pachenalight.com >> Subject: RE: [ppml] a modified proposal 2005-8 >> >> Lee >> >> Responses below. >> >> (All, apologies for the formatting. My responses are between the + >> +++ >> lines.) > > That does make it challenging to respond. In my responses below, > I'm trying to point out that this is where we set IP address > allocation policies, and in order for your participation to be > effective, you need to describe what policy you would like to see. > > > >> Take care >> Terry >> >> -----Original Message----- >> From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] >> Sent: Thursday, March 16, 2006 1:45 PM >> To: Davis, Terry L >> Cc: ppml at arin.net; bookeym at pachenalight.com >> Subject: RE: [ppml] a modified proposal 2005-8 >> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>> Behalf Of Davis, Terry L >>> Sent: Wednesday, March 15, 2006 10:29 PM >>> To: Houle, Joseph D (Joe), CMO >>> Cc: ppml at arin.net; bookeym at pachenalight.com >>> Subject: Re: [ppml] a modified proposal 2005-8 >>> >>> Joe >>> >>> Nope, you read it correctly! >>> >>> The power company will require your electrical systems to >> be on their >>> PLC networks in order to control your electrical systems; it >>> would make >>> a completely unworkable control and routing system for the electric >>> company to try to map the homeowners ISP assigned networks to >>> your home load controller. >> >> Why? They have to have a table mapping (IP) address to >> (home) address, >> so why does it matter if the IP address is theirs? >> ++++++++++++++++++++++++++ >> If they don't go directly to the home, they will constantly be: >> - Unable to connect due home firewall/network changes >> - Have to deal with an IP churn rate per home that will force them to >> change approaching 20% of their entries annually because >> someone either >> moves or change service providers. >> - Will have to require their customers ALSO get an ISP to get load >> control service. >> ++++++++++++++++++++++++++ > > I understand 1 and 3, but I don't follow your middle point. You > suggested government assignment, either to a physical address, in > which case there's no churn, or to an owner, in which case the > churn would happen anyway due to moves, regardless of whether the > address was assigned by utility or government. > > >>> You will need to interface to their control center somehow >> to set your >>> home systems/load controllers and that could be via any available >>> networks but the actual controls will need to come in over their >>> networks. >> >> I'm trying to understand your position: The power company needs to >> build its own IP network in order to manage power systems at each >> home; their IP address assignments will be from their aggregatable >> block. >> +++++++++++++++++++++++++ >> Correct. >> +++++++++++++++++++++++++ >> >>> Likewise government would like to give each home a permanent >>> subnet from >>> "its addresses" for their use especially including advanced >>> EMS services >>> such that they can handle both 911 and direct fire alarms. >> I wouldn't >>> be surprised if in a couple decades, your home City/County has your >>> properties IP address on your deed. >> >> I would be surprised. IP addresses are not property, and are not >> transferable in that sense. >> ++++++++++++++++++++++++++ >> We will see how it develops. My guess is that EMS will win although >> with IP-v6 they could certainly allocate the address portion of the >> space themselves to the property permanently and allow the network >> portion to change. >> ++++++++++++++++++++++++++ > > EMS will win what? I didn't know there was a contest. > > IP addresses are not property. They are identifying numbers, which > are allocated or assigned based on policies created by the public > and administered by the Regional Internet Registries, such as ARIN. > They are fungible, and cannot be owned, bought or sold. > > >>> I already have two ISP's serving my home; cable and DSL >> both and will >>> probably add an EVDO link with a third. In my case, because of the >>> incredibly poor physical plant in my area, neither are very >> reliable. >>> >>> Try this list, you can validate it with some of the folks working >>> community networking: >>> - Internet Service Provider >>> - Entertainment Service Provider >>> - Home Application Service Provider >>> - Government Services >>> - Communication Service Provider >>> - Power Provider >>> - Metering Provider >>> - EMS (911 and fire alarm) >>> - Security Service Provider >>> >>> None of these will be a simple single IP address either as most will >>> have multiple controls or sensors serving your home. >> >> Would a /64 be sufficient for each, do you think? Especially if >> they're not from a single aggregate block, this would be important >> to understand. >> +++++++++++++++++++++++++++ >> I would certainly think so. >> +++++++++++++++++++++++++++ >> >>> >>> And no your ISP will NOT work as the sole provider of my home IP's! >>> I'll personally fight that on capital hill! >> >> This is the place to fight for that, not Capitol Hill. >> ++++++++++++++++++++++++++++ >> I'd like to think so but history seems to say otherwise. >> ++++++++++++++++++++++++++++ > > Please explain. > > > > >>> We fought for the right not >>> to be forced to switch phone numbers when we move and I'm on >>> my 4th (or >>> 5th) ISP serving my home in the last ten years. (AT&T, Earthlink, >>> Qwest, MSN, Speakeasy, and Comcast, ok 6th) All of which >> provided me >>> with new IP's and email addresses which had no relation to any my >>> previous ones so I had to contact everyone I emailed with and >>> have them >>> update my email address. Bill paying services make this even >>> worse! It >>> takes months to get them all updated; one-at-a-time. >> >> Just to make sure I understand your position: >> You'd rather have nine provider aggregated addresses >> (counting networks >> above) than one (PI or PA) address? >> +++++++++++++++++++++++++++++ >> I think that is what will happen. Whether I care or not >> depends on how >> well they can hide the details. Regardless which option >> wins, we cannot >> expect the average homeowner to be able to deal IP networking >> detail at this level. >> +++++++++++++++++++++++++++++ > > What do you want to have happen? > Can you explain how one plan or another affects homeowners? > > >> There are some differences here. Your choice of local phone carriers >> has been extremely limited. The local carrier has physical >> facilities >> to your house; now the cable company and power company also have >> facilities. An ISP provides a service using those facilities. They >> may provide multiple services, including routing (pretty >> essential, and >> requiring aggregatable addressing) and maybe also email, but >> these are >> disjoint: there's no reason your Internet access provider has >> to be your >> email provider. >> +++++++++++++++++++++++++++++ >> Agreed but what we have to do is figure out how to provide >> the homeowner >> at stable set of logical addresses (email/web/voice/etc) that >> map their >> physical ones. Otherwise I am certain that local government will win >> here. >> +++++++++++++++++++++++++++++ > > Again, win what? > Since ARIN only administers IP addresses, can we discuss those > separately? > > Is it necessary for email address, web site, and phone number > to be permanently mapped to an IP address? Are no dynamic > mappings possible which might make the IP address transparent > to the homeowner? > > >>> This is exactly why I would prefer a local government >> provided IP that >>> was associated with my home address that didn't change >> until I moved! >> >> I must have misunderstood your previous points then. There are a lot >> of points to take away from this sentence: >> 1. "Local" government meaning city, county, state, federal, or some >> kind of regional Internet registry? >> +++++++++++++++++++++++++++++++++ >> The first four although the fifth could work. >> +++++++++++++++++++++++++++++++++ > > > In order to derive a policy, we need more detail. What do you > advocate? > > > >> 2. You want a government authority to replace the current >> system of IP >> address allocation? Can you outline the ways in which this >> is superior >> to the current system? >> ++++++++++++++++++++++++++++++++++ >> NO, but that is what I will probably get. The reason is simple; they >> can provide me with a stable set of logical relationships >> that map to my >> physical home. A present this is simply not possible for a service >> provider to do. >> +++++++++++++++++++++++++++++++++++ > > > Then what do you want? > > >> >> 3. How would IP addresses be "associated with my home address"? >> Do you envision embedding physical address information in the IP >> address, like GPS coordinates, or a database owned and operated by >> the >> government? >> +++++++++++++++++++++++++++++++++++ >> I think that either GPS or a government DB is most likely. >> +++++++++++++++++++++++++++++++++++ > > Is that what you want? > Can you provide a way of embedding GPS coordinates into IPv6 > addresses? > Does it scale? > > Can you describe such a government database? Maintainer, schema, > etc. > > How would either of these be routed? > > >> >> 4. How would routing work? Would every network have to carry a >> Separate route for every home? Or do you mean that local >> governments >> should take over all Internet access? >> ++++++++++++++++++++++++++++++++++++ >> In the scenario I envision occurring, local government just becomes >> another "service provider" and each of the home service providers >> does >> their own routing. >> ++++++++++++++++++++++++++++++++++++ > > > I'm not quite sure I followed that. The local government becomes the > Internet access provider? Or do they provide some other service? > > If the government assigns an address to be used by all of the other > providers, there are significant routing implications. If there's > any competition, then addresses cannot be aggregated, and a separate > routing entry will have to be maintained for each address. Can you > describe how that would scale, given even optimistic technology > projections? If there's no competition, then we have nine completely > separate networks, which do not overlap anywhere and cannot inter- > connect. Also, a different form of government and economy. > > >>> And I certainly don't want to worry that if I change ISP, >> 911 or fire >>> won't be able to find me. Likewise I want to keep my phone >>> number when >>> I move and my email even if I have to change service providers. >>> >>> Sorry but my view of the future world has little to do with today's! >> >> That's fair to say. I don't quite understand whether you favor >> competition, monopolization, or nationalization. I'm hoping you can >> clarify how routing might work in your vision. I definitely advise >> you to take advantage of one of the many companies providing free >> email, so that you don't have to go through the pain of updating your >> contacts next time you switch ISPs. Or you can set up your own mail >> server, of course. >> +++++++++++++++++++++++++++++++++++++ >> I'm in favor of a solution that provides the home owner or individual >> with a set of "stable" logical relationships. I certainly won't go >> through a "free email provider" as I need them to both be >> around for the >> long term and to be responsible. As an example, I keep paying MSN >> monthly even though I have no used them as an ISP for over five >> years; >> this is simply to provide my wife a stable email for a large >> non-profit >> group she works with. It is that important! >> +++++++++++++++++++++++++++++++++++++ > > If I have correctly interpreted your arguments, you advocate > government control of networks and centralized, rigidly hierarchical > networks which map exactly to geography. You also want those networks > to map exactly to individuals, which seems to be a conflict. > Perhaps smooth dynamic mappings between identifiers would require > fewer fundamental changes to TCP/IP. > > Lee > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From terry.l.davis at boeing.com Fri Mar 17 11:57:29 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Fri, 17 Mar 2006 08:57:29 -0800 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) In-Reply-To: <5937FAAF-2B5F-4C4F-B210-CD01C0761340@multicasttech.com> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BD24@XCH-NW-8V1.nw.nos.boeing.com> Marshall Possibly but the current mobility schemes don't require that. Being their own Autonomous System would probably help with service provider handoffs; one of our challenges right now is that no one is yet working on how the concepts of "Internet docking" really works for large mobile platforms with one or more complete onboard networks. Take care Terry -----Original Message----- From: Marshall Eubanks [mailto:tme at multicasttech.com] Sent: Friday, March 17, 2006 8:46 AM To: Davis, Terry L Cc: Howard, W. Lee; ppml at arin.net Subject: Re: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) To extend your example at little, would you envision each Aircraft as being its own Autonomous System ? And, if not, why not ? Regards Marshall On Mar 17, 2006, at 11:33 AM, Davis, Terry L wrote: > Lee > > My main point is that we cannot plan for an IP-v6 world using IP-v4 > templates. The key messages: > > 1) We MUST provider users (individuals/government/business) with > logical > stability. Getting new IP addresses, DNS names, and email addresses > every time we either change providers or move will simply be > unacceptable. Without this logical stability, every communication > service (voice/email/etc) is unstable, industry-wide initiatives (i.e. > like power control) are not possible, and even gains the financial > institutions hope to make with EFT systems become limited (i.e. > remember > the fun of resetting all your automatic billings/payments email > addresses last time you changed service providers?). I know this > may be > more an IETF issue but I'm there next week. > > 2) Assuming that any users (individuals/government/business) will > have a > single service provider is completely unrealistic. (Much of point in > the chain below) We need to understand impacts of this to IP-v6 > network > architectures and routing. > > (I'm already dealing with this reality in the aviation industry as we > plan for IP-v6. The aircraft MUST be able to join to many different > service provider networks as it moves around the world; we have > carriers > that fly there aircraft literally around the world in a bit over a > day. > The aircraft WILL most of the time have simultaneous links to multiple > service providers. An aircraft will probably have at least three > separate networks onboard: air traffic control, airline or > operator, and > in-flight passenger services/entertainment.) > > 3) Besides government, whole industries will want address blocks that > they manage as closed network; these may be at the regional, national, > or global level. Power, shipping, and aviation are some that will > almost certainly require this. > > 4) We might as well come to terms with the idea that some of these > must > be essentially irrevocable. Can anyone envision revoking the IP > address > of an aircraft that is set up in air traffic control systems around > the > world? > > I doubt that I can make the ARIN meeting in Montreal but I will try. > > Take care > Terry > > -----Original Message----- > From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] > Sent: Friday, March 17, 2006 7:44 AM > To: Davis, Terry L > Cc: ppml at arin.net > Subject: RE: [ppml] a modified proposal 2005-8 > >> -----Original Message----- >> From: Davis, Terry L [mailto:terry.l.davis at boeing.com] >> Sent: Thursday, March 16, 2006 5:56 PM >> To: Howard, W. Lee >> Cc: ppml at arin.net; bookeym at pachenalight.com >> Subject: RE: [ppml] a modified proposal 2005-8 >> >> Lee >> >> Responses below. >> >> (All, apologies for the formatting. My responses are between the + >> +++ >> lines.) > > That does make it challenging to respond. In my responses below, > I'm trying to point out that this is where we set IP address > allocation policies, and in order for your participation to be > effective, you need to describe what policy you would like to see. > > > >> Take care >> Terry >> >> -----Original Message----- >> From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] >> Sent: Thursday, March 16, 2006 1:45 PM >> To: Davis, Terry L >> Cc: ppml at arin.net; bookeym at pachenalight.com >> Subject: RE: [ppml] a modified proposal 2005-8 >> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>> Behalf Of Davis, Terry L >>> Sent: Wednesday, March 15, 2006 10:29 PM >>> To: Houle, Joseph D (Joe), CMO >>> Cc: ppml at arin.net; bookeym at pachenalight.com >>> Subject: Re: [ppml] a modified proposal 2005-8 >>> >>> Joe >>> >>> Nope, you read it correctly! >>> >>> The power company will require your electrical systems to >> be on their >>> PLC networks in order to control your electrical systems; it >>> would make >>> a completely unworkable control and routing system for the electric >>> company to try to map the homeowners ISP assigned networks to >>> your home load controller. >> >> Why? They have to have a table mapping (IP) address to >> (home) address, >> so why does it matter if the IP address is theirs? >> ++++++++++++++++++++++++++ >> If they don't go directly to the home, they will constantly be: >> - Unable to connect due home firewall/network changes >> - Have to deal with an IP churn rate per home that will force them to >> change approaching 20% of their entries annually because >> someone either >> moves or change service providers. >> - Will have to require their customers ALSO get an ISP to get load >> control service. >> ++++++++++++++++++++++++++ > > I understand 1 and 3, but I don't follow your middle point. You > suggested government assignment, either to a physical address, in > which case there's no churn, or to an owner, in which case the > churn would happen anyway due to moves, regardless of whether the > address was assigned by utility or government. > > >>> You will need to interface to their control center somehow >> to set your >>> home systems/load controllers and that could be via any available >>> networks but the actual controls will need to come in over their >>> networks. >> >> I'm trying to understand your position: The power company needs to >> build its own IP network in order to manage power systems at each >> home; their IP address assignments will be from their aggregatable >> block. >> +++++++++++++++++++++++++ >> Correct. >> +++++++++++++++++++++++++ >> >>> Likewise government would like to give each home a permanent >>> subnet from >>> "its addresses" for their use especially including advanced >>> EMS services >>> such that they can handle both 911 and direct fire alarms. >> I wouldn't >>> be surprised if in a couple decades, your home City/County has your >>> properties IP address on your deed. >> >> I would be surprised. IP addresses are not property, and are not >> transferable in that sense. >> ++++++++++++++++++++++++++ >> We will see how it develops. My guess is that EMS will win although >> with IP-v6 they could certainly allocate the address portion of the >> space themselves to the property permanently and allow the network >> portion to change. >> ++++++++++++++++++++++++++ > > EMS will win what? I didn't know there was a contest. > > IP addresses are not property. They are identifying numbers, which > are allocated or assigned based on policies created by the public > and administered by the Regional Internet Registries, such as ARIN. > They are fungible, and cannot be owned, bought or sold. > > >>> I already have two ISP's serving my home; cable and DSL >> both and will >>> probably add an EVDO link with a third. In my case, because of the >>> incredibly poor physical plant in my area, neither are very >> reliable. >>> >>> Try this list, you can validate it with some of the folks working >>> community networking: >>> - Internet Service Provider >>> - Entertainment Service Provider >>> - Home Application Service Provider >>> - Government Services >>> - Communication Service Provider >>> - Power Provider >>> - Metering Provider >>> - EMS (911 and fire alarm) >>> - Security Service Provider >>> >>> None of these will be a simple single IP address either as most will >>> have multiple controls or sensors serving your home. >> >> Would a /64 be sufficient for each, do you think? Especially if >> they're not from a single aggregate block, this would be important >> to understand. >> +++++++++++++++++++++++++++ >> I would certainly think so. >> +++++++++++++++++++++++++++ >> >>> >>> And no your ISP will NOT work as the sole provider of my home IP's! >>> I'll personally fight that on capital hill! >> >> This is the place to fight for that, not Capitol Hill. >> ++++++++++++++++++++++++++++ >> I'd like to think so but history seems to say otherwise. >> ++++++++++++++++++++++++++++ > > Please explain. > > > > >>> We fought for the right not >>> to be forced to switch phone numbers when we move and I'm on >>> my 4th (or >>> 5th) ISP serving my home in the last ten years. (AT&T, Earthlink, >>> Qwest, MSN, Speakeasy, and Comcast, ok 6th) All of which >> provided me >>> with new IP's and email addresses which had no relation to any my >>> previous ones so I had to contact everyone I emailed with and >>> have them >>> update my email address. Bill paying services make this even >>> worse! It >>> takes months to get them all updated; one-at-a-time. >> >> Just to make sure I understand your position: >> You'd rather have nine provider aggregated addresses >> (counting networks >> above) than one (PI or PA) address? >> +++++++++++++++++++++++++++++ >> I think that is what will happen. Whether I care or not >> depends on how >> well they can hide the details. Regardless which option >> wins, we cannot >> expect the average homeowner to be able to deal IP networking >> detail at this level. >> +++++++++++++++++++++++++++++ > > What do you want to have happen? > Can you explain how one plan or another affects homeowners? > > >> There are some differences here. Your choice of local phone carriers >> has been extremely limited. The local carrier has physical >> facilities >> to your house; now the cable company and power company also have >> facilities. An ISP provides a service using those facilities. They >> may provide multiple services, including routing (pretty >> essential, and >> requiring aggregatable addressing) and maybe also email, but >> these are >> disjoint: there's no reason your Internet access provider has >> to be your >> email provider. >> +++++++++++++++++++++++++++++ >> Agreed but what we have to do is figure out how to provide >> the homeowner >> at stable set of logical addresses (email/web/voice/etc) that >> map their >> physical ones. Otherwise I am certain that local government will win >> here. >> +++++++++++++++++++++++++++++ > > Again, win what? > Since ARIN only administers IP addresses, can we discuss those > separately? > > Is it necessary for email address, web site, and phone number > to be permanently mapped to an IP address? Are no dynamic > mappings possible which might make the IP address transparent > to the homeowner? > > >>> This is exactly why I would prefer a local government >> provided IP that >>> was associated with my home address that didn't change >> until I moved! >> >> I must have misunderstood your previous points then. There are a lot >> of points to take away from this sentence: >> 1. "Local" government meaning city, county, state, federal, or some >> kind of regional Internet registry? >> +++++++++++++++++++++++++++++++++ >> The first four although the fifth could work. >> +++++++++++++++++++++++++++++++++ > > > In order to derive a policy, we need more detail. What do you > advocate? > > > >> 2. You want a government authority to replace the current >> system of IP >> address allocation? Can you outline the ways in which this >> is superior >> to the current system? >> ++++++++++++++++++++++++++++++++++ >> NO, but that is what I will probably get. The reason is simple; they >> can provide me with a stable set of logical relationships >> that map to my >> physical home. A present this is simply not possible for a service >> provider to do. >> +++++++++++++++++++++++++++++++++++ > > > Then what do you want? > > >> >> 3. How would IP addresses be "associated with my home address"? >> Do you envision embedding physical address information in the IP >> address, like GPS coordinates, or a database owned and operated by >> the >> government? >> +++++++++++++++++++++++++++++++++++ >> I think that either GPS or a government DB is most likely. >> +++++++++++++++++++++++++++++++++++ > > Is that what you want? > Can you provide a way of embedding GPS coordinates into IPv6 > addresses? > Does it scale? > > Can you describe such a government database? Maintainer, schema, > etc. > > How would either of these be routed? > > >> >> 4. How would routing work? Would every network have to carry a >> Separate route for every home? Or do you mean that local >> governments >> should take over all Internet access? >> ++++++++++++++++++++++++++++++++++++ >> In the scenario I envision occurring, local government just becomes >> another "service provider" and each of the home service providers >> does >> their own routing. >> ++++++++++++++++++++++++++++++++++++ > > > I'm not quite sure I followed that. The local government becomes the > Internet access provider? Or do they provide some other service? > > If the government assigns an address to be used by all of the other > providers, there are significant routing implications. If there's > any competition, then addresses cannot be aggregated, and a separate > routing entry will have to be maintained for each address. Can you > describe how that would scale, given even optimistic technology > projections? If there's no competition, then we have nine completely > separate networks, which do not overlap anywhere and cannot inter- > connect. Also, a different form of government and economy. > > >>> And I certainly don't want to worry that if I change ISP, >> 911 or fire >>> won't be able to find me. Likewise I want to keep my phone >>> number when >>> I move and my email even if I have to change service providers. >>> >>> Sorry but my view of the future world has little to do with today's! >> >> That's fair to say. I don't quite understand whether you favor >> competition, monopolization, or nationalization. I'm hoping you can >> clarify how routing might work in your vision. I definitely advise >> you to take advantage of one of the many companies providing free >> email, so that you don't have to go through the pain of updating your >> contacts next time you switch ISPs. Or you can set up your own mail >> server, of course. >> +++++++++++++++++++++++++++++++++++++ >> I'm in favor of a solution that provides the home owner or individual >> with a set of "stable" logical relationships. I certainly won't go >> through a "free email provider" as I need them to both be >> around for the >> long term and to be responsible. As an example, I keep paying MSN >> monthly even though I have no used them as an ISP for over five >> years; >> this is simply to provide my wife a stable email for a large >> non-profit >> group she works with. It is that important! >> +++++++++++++++++++++++++++++++++++++ > > If I have correctly interpreted your arguments, you advocate > government control of networks and centralized, rigidly hierarchical > networks which map exactly to geography. You also want those networks > to map exactly to individuals, which seems to be a conflict. > Perhaps smooth dynamic mappings between identifiers would require > fewer fundamental changes to TCP/IP. > > Lee > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From Lee.Howard at stanleyassociates.com Fri Mar 17 12:01:21 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 17 Mar 2006 12:01:21 -0500 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4018CAAE7@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: Davis, Terry L [mailto:terry.l.davis at boeing.com] > Sent: Friday, March 17, 2006 11:33 AM > To: Howard, W. Lee; ppml at arin.net > Cc: Wettling, Fred > Subject: IP-v6 Needs (RE: [ppml] a modified proposal 2005-8) > > Lee > > My main point is that we cannot plan for an IP-v6 world using IP-v4 > templates. The key messages: I think we've accepted that, and we're trying to understand what should be done with IPv6. RFC2119 should. > 1) We MUST provider users (individuals/government/business) > with logical > stability. Getting new IP addresses, DNS names, and email addresses > every time we either change providers or move will simply be > unacceptable. Just because one changes does not mean the others need to change. That's why we have DNS and logical pointers. The stack isn't monolithic. There are several network protocols that can accomodate this requirement, but TCP/IP isn't designed that way. > Without this logical stability, every communication > service (voice/email/etc) is unstable, industry-wide initiatives (i.e. > like power control) are not possible, and even gains the financial > institutions hope to make with EFT systems become limited > (i.e. remember > the fun of resetting all your automatic billings/payments email > addresses last time you changed service providers?). I know > this may be more an IETF issue but I'm there next week. I've changed providers at home four times in the last two years. My personal web site and my personal email address have been unaffected. I reduced my DNS TTLs, made the DNS change, and cranked the TTLs back up. I run my own server, but it would have been as easy if I'd been hosted. We're still talking about residences, right? > 2) Assuming that any users (individuals/government/business) > will have a > single service provider is completely unrealistic. (Much of point in > the chain below) We need to understand impacts of this to > IP-v6 network architectures and routing. Define "service provider." Is it layer 1-3 access, or layer 4-7 function, or both? > (I'm already dealing with this reality in the aviation industry as we > plan for IP-v6. The aircraft MUST be able to join to many different > service provider networks as it moves around the world; we > have carriers > that fly there aircraft literally around the world in a bit > over a day. > The aircraft WILL most of the time have simultaneous links to multiple > service providers. An aircraft will probably have at least three > separate networks onboard: air traffic control, airline or > operator, and in-flight passenger services/entertainment.) Very few homes travel around the world in 24 hours. Separate policies for separate cases are acceptable. Are you asserting that my aircraft must provide email service using the same email address I use at home? Same IP address? Same E-911 address? Do these three networks need one /64, three /64s, or one /62? > 3) Besides government, whole industries will want address blocks that > they manage as closed network; these may be at the regional, national, > or global level. Power, shipping, and aviation are some that will > almost certainly require this. OK. That's allowed under current policy. > 4) We might as well come to terms with the idea that some of > these must > be essentially irrevocable. Can anyone envision revoking the > IP address > of an aircraft that is set up in air traffic control systems > around the world? I don't understand your network, so I can't comment on it. Is an aircraft a network host, or a router? A site? Is the passenger laptop on board supposed to use an aircraft IP address, or its home address? If an aircraft gets an address assignment, /64 or /128 or something else, how do you plan to route it? That's another way of asking how you intend to use it, and if I can't understand it, then I'll have trouble writing a policy to cover it. > I doubt that I can make the ARIN meeting in Montreal but I will try. Remote participation is also an option. Lee From bmanning at vacation.karoshi.com Fri Mar 17 12:04:51 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 17 Mar 2006 17:04:51 +0000 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BD24@XCH-NW-8V1.nw.nos.boeing.com> References: <5937FAAF-2B5F-4C4F-B210-CD01C0761340@multicasttech.com> <0D090F1E0F5536449C7E6527AFFA280A21BD24@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: <20060317170451.GF8997@vacation.karoshi.com.> Terry, actually, there are some folks workiing on this very thing. the IETF has talked abt the issue in the MONET/MANET wgs, and the WIDE project (japan) has explored the idea with its iCAR working group. all in all, an exciting area of research, and yes, it will require some different thinking on how names/ addresses are assigned & how routing is done. One of the current difficulties of the RIR system is that it is designed to be bottom-up, consensus-driven when it comes to address assignment policies. That type of methodology works very well for a well established modality - is very hard to try radical new ideas ... but ARIN seems to be more responsive in this regard than many RIR/LIRs.. perhaps not responsive enough for some. :) --bill On Fri, Mar 17, 2006 at 08:57:29AM -0800, Davis, Terry L wrote: > Marshall > > Possibly but the current mobility schemes don't require that. > > Being their own Autonomous System would probably help with service > provider handoffs; one of our challenges right now is that no one is yet > working on how the concepts of "Internet docking" really works for large > mobile platforms with one or more complete onboard networks. > > Take care > Terry > > -----Original Message----- > From: Marshall Eubanks [mailto:tme at multicasttech.com] > Sent: Friday, March 17, 2006 8:46 AM > To: Davis, Terry L > Cc: Howard, W. Lee; ppml at arin.net > Subject: Re: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) > > To extend your example at little, would you envision each Aircraft as > being its > own Autonomous System ? And, if not, why not ? > > Regards > Marshall > > On Mar 17, 2006, at 11:33 AM, Davis, Terry L wrote: > > > Lee > > > > My main point is that we cannot plan for an IP-v6 world using IP-v4 > > templates. The key messages: > > > > 1) We MUST provider users (individuals/government/business) with > > logical > > stability. Getting new IP addresses, DNS names, and email addresses > > every time we either change providers or move will simply be > > unacceptable. Without this logical stability, every communication > > service (voice/email/etc) is unstable, industry-wide initiatives (i.e. > > like power control) are not possible, and even gains the financial > > institutions hope to make with EFT systems become limited (i.e. > > remember > > the fun of resetting all your automatic billings/payments email > > addresses last time you changed service providers?). I know this > > may be > > more an IETF issue but I'm there next week. > > > > 2) Assuming that any users (individuals/government/business) will > > have a > > single service provider is completely unrealistic. (Much of point in > > the chain below) We need to understand impacts of this to IP-v6 > > network > > architectures and routing. > > > > (I'm already dealing with this reality in the aviation industry as we > > plan for IP-v6. The aircraft MUST be able to join to many different > > service provider networks as it moves around the world; we have > > carriers > > that fly there aircraft literally around the world in a bit over a > > day. > > The aircraft WILL most of the time have simultaneous links to multiple > > service providers. An aircraft will probably have at least three > > separate networks onboard: air traffic control, airline or > > operator, and > > in-flight passenger services/entertainment.) > > > > 3) Besides government, whole industries will want address blocks that > > they manage as closed network; these may be at the regional, national, > > or global level. Power, shipping, and aviation are some that will > > almost certainly require this. > > > > 4) We might as well come to terms with the idea that some of these > > must > > be essentially irrevocable. Can anyone envision revoking the IP > > address > > of an aircraft that is set up in air traffic control systems around > > the > > world? > > > > I doubt that I can make the ARIN meeting in Montreal but I will try. > > > > Take care > > Terry > > > > -----Original Message----- > > From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] > > Sent: Friday, March 17, 2006 7:44 AM > > To: Davis, Terry L > > Cc: ppml at arin.net > > Subject: RE: [ppml] a modified proposal 2005-8 > > > >> -----Original Message----- > >> From: Davis, Terry L [mailto:terry.l.davis at boeing.com] > >> Sent: Thursday, March 16, 2006 5:56 PM > >> To: Howard, W. Lee > >> Cc: ppml at arin.net; bookeym at pachenalight.com > >> Subject: RE: [ppml] a modified proposal 2005-8 > >> > >> Lee > >> > >> Responses below. > >> > >> (All, apologies for the formatting. My responses are between the + > >> +++ > >> lines.) > > > > That does make it challenging to respond. In my responses below, > > I'm trying to point out that this is where we set IP address > > allocation policies, and in order for your participation to be > > effective, you need to describe what policy you would like to see. > > > > > > > >> Take care > >> Terry > >> > >> -----Original Message----- > >> From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] > >> Sent: Thursday, March 16, 2006 1:45 PM > >> To: Davis, Terry L > >> Cc: ppml at arin.net; bookeym at pachenalight.com > >> Subject: RE: [ppml] a modified proposal 2005-8 > >> > >>> -----Original Message----- > >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > >>> Behalf Of Davis, Terry L > >>> Sent: Wednesday, March 15, 2006 10:29 PM > >>> To: Houle, Joseph D (Joe), CMO > >>> Cc: ppml at arin.net; bookeym at pachenalight.com > >>> Subject: Re: [ppml] a modified proposal 2005-8 > >>> > >>> Joe > >>> > >>> Nope, you read it correctly! > >>> > >>> The power company will require your electrical systems to > >> be on their > >>> PLC networks in order to control your electrical systems; it > >>> would make > >>> a completely unworkable control and routing system for the electric > >>> company to try to map the homeowners ISP assigned networks to > >>> your home load controller. > >> > >> Why? They have to have a table mapping (IP) address to > >> (home) address, > >> so why does it matter if the IP address is theirs? > >> ++++++++++++++++++++++++++ > >> If they don't go directly to the home, they will constantly be: > >> - Unable to connect due home firewall/network changes > >> - Have to deal with an IP churn rate per home that will force them to > >> change approaching 20% of their entries annually because > >> someone either > >> moves or change service providers. > >> - Will have to require their customers ALSO get an ISP to get load > >> control service. > >> ++++++++++++++++++++++++++ > > > > I understand 1 and 3, but I don't follow your middle point. You > > suggested government assignment, either to a physical address, in > > which case there's no churn, or to an owner, in which case the > > churn would happen anyway due to moves, regardless of whether the > > address was assigned by utility or government. > > > > > >>> You will need to interface to their control center somehow > >> to set your > >>> home systems/load controllers and that could be via any available > >>> networks but the actual controls will need to come in over their > >>> networks. > >> > >> I'm trying to understand your position: The power company needs to > >> build its own IP network in order to manage power systems at each > >> home; their IP address assignments will be from their aggregatable > >> block. > >> +++++++++++++++++++++++++ > >> Correct. > >> +++++++++++++++++++++++++ > >> > >>> Likewise government would like to give each home a permanent > >>> subnet from > >>> "its addresses" for their use especially including advanced > >>> EMS services > >>> such that they can handle both 911 and direct fire alarms. > >> I wouldn't > >>> be surprised if in a couple decades, your home City/County has your > >>> properties IP address on your deed. > >> > >> I would be surprised. IP addresses are not property, and are not > >> transferable in that sense. > >> ++++++++++++++++++++++++++ > >> We will see how it develops. My guess is that EMS will win although > >> with IP-v6 they could certainly allocate the address portion of the > >> space themselves to the property permanently and allow the network > >> portion to change. > >> ++++++++++++++++++++++++++ > > > > EMS will win what? I didn't know there was a contest. > > > > IP addresses are not property. They are identifying numbers, which > > are allocated or assigned based on policies created by the public > > and administered by the Regional Internet Registries, such as ARIN. > > They are fungible, and cannot be owned, bought or sold. > > > > > >>> I already have two ISP's serving my home; cable and DSL > >> both and will > >>> probably add an EVDO link with a third. In my case, because of the > >>> incredibly poor physical plant in my area, neither are very > >> reliable. > >>> > >>> Try this list, you can validate it with some of the folks working > >>> community networking: > >>> - Internet Service Provider > >>> - Entertainment Service Provider > >>> - Home Application Service Provider > >>> - Government Services > >>> - Communication Service Provider > >>> - Power Provider > >>> - Metering Provider > >>> - EMS (911 and fire alarm) > >>> - Security Service Provider > >>> > >>> None of these will be a simple single IP address either as most will > >>> have multiple controls or sensors serving your home. > >> > >> Would a /64 be sufficient for each, do you think? Especially if > >> they're not from a single aggregate block, this would be important > >> to understand. > >> +++++++++++++++++++++++++++ > >> I would certainly think so. > >> +++++++++++++++++++++++++++ > >> > >>> > >>> And no your ISP will NOT work as the sole provider of my home IP's! > >>> I'll personally fight that on capital hill! > >> > >> This is the place to fight for that, not Capitol Hill. > >> ++++++++++++++++++++++++++++ > >> I'd like to think so but history seems to say otherwise. > >> ++++++++++++++++++++++++++++ > > > > Please explain. > > > > > > > > > >>> We fought for the right not > >>> to be forced to switch phone numbers when we move and I'm on > >>> my 4th (or > >>> 5th) ISP serving my home in the last ten years. (AT&T, Earthlink, > >>> Qwest, MSN, Speakeasy, and Comcast, ok 6th) All of which > >> provided me > >>> with new IP's and email addresses which had no relation to any my > >>> previous ones so I had to contact everyone I emailed with and > >>> have them > >>> update my email address. Bill paying services make this even > >>> worse! It > >>> takes months to get them all updated; one-at-a-time. > >> > >> Just to make sure I understand your position: > >> You'd rather have nine provider aggregated addresses > >> (counting networks > >> above) than one (PI or PA) address? > >> +++++++++++++++++++++++++++++ > >> I think that is what will happen. Whether I care or not > >> depends on how > >> well they can hide the details. Regardless which option > >> wins, we cannot > >> expect the average homeowner to be able to deal IP networking > >> detail at this level. > >> +++++++++++++++++++++++++++++ > > > > What do you want to have happen? > > Can you explain how one plan or another affects homeowners? > > > > > >> There are some differences here. Your choice of local phone carriers > >> has been extremely limited. The local carrier has physical > >> facilities > >> to your house; now the cable company and power company also have > >> facilities. An ISP provides a service using those facilities. They > >> may provide multiple services, including routing (pretty > >> essential, and > >> requiring aggregatable addressing) and maybe also email, but > >> these are > >> disjoint: there's no reason your Internet access provider has > >> to be your > >> email provider. > >> +++++++++++++++++++++++++++++ > >> Agreed but what we have to do is figure out how to provide > >> the homeowner > >> at stable set of logical addresses (email/web/voice/etc) that > >> map their > >> physical ones. Otherwise I am certain that local government will win > >> here. > >> +++++++++++++++++++++++++++++ > > > > Again, win what? > > Since ARIN only administers IP addresses, can we discuss those > > separately? > > > > Is it necessary for email address, web site, and phone number > > to be permanently mapped to an IP address? Are no dynamic > > mappings possible which might make the IP address transparent > > to the homeowner? > > > > > >>> This is exactly why I would prefer a local government > >> provided IP that > >>> was associated with my home address that didn't change > >> until I moved! > >> > >> I must have misunderstood your previous points then. There are a lot > >> of points to take away from this sentence: > >> 1. "Local" government meaning city, county, state, federal, or some > >> kind of regional Internet registry? > >> +++++++++++++++++++++++++++++++++ > >> The first four although the fifth could work. > >> +++++++++++++++++++++++++++++++++ > > > > > > In order to derive a policy, we need more detail. What do you > > advocate? > > > > > > > >> 2. You want a government authority to replace the current > >> system of IP > >> address allocation? Can you outline the ways in which this > >> is superior > >> to the current system? > >> ++++++++++++++++++++++++++++++++++ > >> NO, but that is what I will probably get. The reason is simple; they > >> can provide me with a stable set of logical relationships > >> that map to my > >> physical home. A present this is simply not possible for a service > >> provider to do. > >> +++++++++++++++++++++++++++++++++++ > > > > > > Then what do you want? > > > > > >> > >> 3. How would IP addresses be "associated with my home address"? > >> Do you envision embedding physical address information in the IP > >> address, like GPS coordinates, or a database owned and operated by > >> the > >> government? > >> +++++++++++++++++++++++++++++++++++ > >> I think that either GPS or a government DB is most likely. > >> +++++++++++++++++++++++++++++++++++ > > > > Is that what you want? > > Can you provide a way of embedding GPS coordinates into IPv6 > > addresses? > > Does it scale? > > > > Can you describe such a government database? Maintainer, schema, > > etc. > > > > How would either of these be routed? > > > > > >> > >> 4. How would routing work? Would every network have to carry a > >> Separate route for every home? Or do you mean that local > >> governments > >> should take over all Internet access? > >> ++++++++++++++++++++++++++++++++++++ > >> In the scenario I envision occurring, local government just becomes > >> another "service provider" and each of the home service providers > >> does > >> their own routing. > >> ++++++++++++++++++++++++++++++++++++ > > > > > > I'm not quite sure I followed that. The local government becomes the > > Internet access provider? Or do they provide some other service? > > > > If the government assigns an address to be used by all of the other > > providers, there are significant routing implications. If there's > > any competition, then addresses cannot be aggregated, and a separate > > routing entry will have to be maintained for each address. Can you > > describe how that would scale, given even optimistic technology > > projections? If there's no competition, then we have nine completely > > separate networks, which do not overlap anywhere and cannot inter- > > connect. Also, a different form of government and economy. > > > > > >>> And I certainly don't want to worry that if I change ISP, > >> 911 or fire > >>> won't be able to find me. Likewise I want to keep my phone > >>> number when > >>> I move and my email even if I have to change service providers. > >>> > >>> Sorry but my view of the future world has little to do with today's! > >> > >> That's fair to say. I don't quite understand whether you favor > >> competition, monopolization, or nationalization. I'm hoping you can > >> clarify how routing might work in your vision. I definitely advise > >> you to take advantage of one of the many companies providing free > >> email, so that you don't have to go through the pain of updating your > >> contacts next time you switch ISPs. Or you can set up your own mail > >> server, of course. > >> +++++++++++++++++++++++++++++++++++++ > >> I'm in favor of a solution that provides the home owner or individual > >> with a set of "stable" logical relationships. I certainly won't go > >> through a "free email provider" as I need them to both be > >> around for the > >> long term and to be responsible. As an example, I keep paying MSN > >> monthly even though I have no used them as an ISP for over five > >> years; > >> this is simply to provide my wife a stable email for a large > >> non-profit > >> group she works with. It is that important! > >> +++++++++++++++++++++++++++++++++++++ > > > > If I have correctly interpreted your arguments, you advocate > > government control of networks and centralized, rigidly hierarchical > > networks which map exactly to geography. You also want those networks > > to map exactly to individuals, which seems to be a conflict. > > Perhaps smooth dynamic mappings between identifiers would require > > fewer fundamental changes to TCP/IP. > > > > Lee > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From Michael.Dillon at btradianz.com Fri Mar 17 12:29:13 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 17 Mar 2006 17:29:13 +0000 Subject: [ppml] a modified proposal 2005-8 In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4018CAA64@CL-S-EX-1.stanleyassociates.com> Message-ID: > > 3. How would IP addresses be "associated with my home address"? > > Do you envision embedding physical address information in the IP > > address, like GPS coordinates, or a database owned and operated by the > > government? > > +++++++++++++++++++++++++++++++++++ > > I think that either GPS or a government DB is most likely. > > +++++++++++++++++++++++++++++++++++ > > Is that what you want? > Can you provide a way of embedding GPS coordinates into IPv6 addresses? > Does it scale? >From a policy point of view, we must remember that the IPv6 address space is finite. At the same time it is intended to be very big so that it is very hard to use up all of the space. Any scheme which maps some locator, like GPS coordinates, directly onto the IPv6 address space, is likely to result in large amounts of unusable address space due to the fact that most territory on the earth is covered by ocean or uninhabited wilderness. Therefore, the only politically tenable scheme would be one that uses a database. In fact, this type of scheme is proven to work for interactive applications since this is how phone number portability works. Given that such mapping schemes are almost certain to be based on a database, then there should be no scaling problems. Security issues are another thing. Even if you propose some sort of address translation scheme that maps a homeowner's /64 onto the house's /64, this does not automatically allow either the homeowner or the house to use an arbitrary range. The power company who wishes to monitor and control home electrical systems (presumably in return for a better rate) will want to implement layers of security. One of those layers is a globally unique IPv6 address range. Another layer is a entirely separate physical path from the house for this address range. Inside devices we can expect that the homeowner's /48 will touch the same interfaces as the power company's /64, but the device itself will have some strict routing controls to prevent exchange of packets between the two network. The extent of the mixing is unlikely to go beyond allowing the homeowner some visibility of monitoring data and some ability to override settings (if they will accept loss of their discount during the override period). If all of this sounds too pie in the sky for you, then we have a failure of imagination. This is a bad thing considering how the developers of IPv6 were already talking about an IPv6 address for every lightbulb and light switch over 10 years ago. Not to mention interplanetary networking. How else do you talk to the many satellites and interplanetary probes that we send out every year? Also, it would be bad to implement an IPv6 policy that could not be changed in 10 years or 20 years in order to handle the very real technological changes are in our future. --Michael Dillon From tme at multicasttech.com Fri Mar 17 12:31:34 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 17 Mar 2006 12:31:34 -0500 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BD24@XCH-NW-8V1.nw.nos.boeing.com> References: <0D090F1E0F5536449C7E6527AFFA280A21BD24@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: <86FB20CB-0A86-413D-8F3A-0CF09443FD0E@multicasttech.com> I will probably become unpopular for saying this, but I actually think that a $ 100 million dollar aircraft with hundreds of people and networked devices on board _should_ be an Autonomous system, with its own PI address space to boot. Regards Marshall On Mar 17, 2006, at 11:57 AM, Davis, Terry L wrote: > Marshall > > Possibly but the current mobility schemes don't require that. > > Being their own Autonomous System would probably help with service > provider handoffs; one of our challenges right now is that no one > is yet > working on how the concepts of "Internet docking" really works for > large > mobile platforms with one or more complete onboard networks. > > Take care > Terry > > -----Original Message----- > From: Marshall Eubanks [mailto:tme at multicasttech.com] > Sent: Friday, March 17, 2006 8:46 AM > To: Davis, Terry L > Cc: Howard, W. Lee; ppml at arin.net > Subject: Re: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) > > To extend your example at little, would you envision each Aircraft as > being its > own Autonomous System ? And, if not, why not ? > > Regards > Marshall > > On Mar 17, 2006, at 11:33 AM, Davis, Terry L wrote: > >> Lee >> >> My main point is that we cannot plan for an IP-v6 world using IP-v4 >> templates. The key messages: >> >> 1) We MUST provider users (individuals/government/business) with >> logical >> stability. Getting new IP addresses, DNS names, and email addresses >> every time we either change providers or move will simply be >> unacceptable. Without this logical stability, every communication >> service (voice/email/etc) is unstable, industry-wide initiatives >> (i.e. >> like power control) are not possible, and even gains the financial >> institutions hope to make with EFT systems become limited (i.e. >> remember >> the fun of resetting all your automatic billings/payments email >> addresses last time you changed service providers?). I know this >> may be >> more an IETF issue but I'm there next week. >> >> 2) Assuming that any users (individuals/government/business) will >> have a >> single service provider is completely unrealistic. (Much of point in >> the chain below) We need to understand impacts of this to IP-v6 >> network >> architectures and routing. >> >> (I'm already dealing with this reality in the aviation industry as we >> plan for IP-v6. The aircraft MUST be able to join to many different >> service provider networks as it moves around the world; we have >> carriers >> that fly there aircraft literally around the world in a bit over a >> day. >> The aircraft WILL most of the time have simultaneous links to >> multiple >> service providers. An aircraft will probably have at least three >> separate networks onboard: air traffic control, airline or >> operator, and >> in-flight passenger services/entertainment.) >> >> 3) Besides government, whole industries will want address blocks that >> they manage as closed network; these may be at the regional, >> national, >> or global level. Power, shipping, and aviation are some that will >> almost certainly require this. >> >> 4) We might as well come to terms with the idea that some of these >> must >> be essentially irrevocable. Can anyone envision revoking the IP >> address >> of an aircraft that is set up in air traffic control systems around >> the >> world? >> >> I doubt that I can make the ARIN meeting in Montreal but I will try. >> >> Take care >> Terry >> >> -----Original Message----- >> From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] >> Sent: Friday, March 17, 2006 7:44 AM >> To: Davis, Terry L >> Cc: ppml at arin.net >> Subject: RE: [ppml] a modified proposal 2005-8 >> >>> -----Original Message----- >>> From: Davis, Terry L [mailto:terry.l.davis at boeing.com] >>> Sent: Thursday, March 16, 2006 5:56 PM >>> To: Howard, W. Lee >>> Cc: ppml at arin.net; bookeym at pachenalight.com >>> Subject: RE: [ppml] a modified proposal 2005-8 >>> >>> Lee >>> >>> Responses below. >>> >>> (All, apologies for the formatting. My responses are between the + >>> +++ >>> lines.) >> >> That does make it challenging to respond. In my responses below, >> I'm trying to point out that this is where we set IP address >> allocation policies, and in order for your participation to be >> effective, you need to describe what policy you would like to see. >> >> >> >>> Take care >>> Terry >>> >>> -----Original Message----- >>> From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] >>> Sent: Thursday, March 16, 2006 1:45 PM >>> To: Davis, Terry L >>> Cc: ppml at arin.net; bookeym at pachenalight.com >>> Subject: RE: [ppml] a modified proposal 2005-8 >>> >>>> -----Original Message----- >>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>>> Behalf Of Davis, Terry L >>>> Sent: Wednesday, March 15, 2006 10:29 PM >>>> To: Houle, Joseph D (Joe), CMO >>>> Cc: ppml at arin.net; bookeym at pachenalight.com >>>> Subject: Re: [ppml] a modified proposal 2005-8 >>>> >>>> Joe >>>> >>>> Nope, you read it correctly! >>>> >>>> The power company will require your electrical systems to >>> be on their >>>> PLC networks in order to control your electrical systems; it >>>> would make >>>> a completely unworkable control and routing system for the electric >>>> company to try to map the homeowners ISP assigned networks to >>>> your home load controller. >>> >>> Why? They have to have a table mapping (IP) address to >>> (home) address, >>> so why does it matter if the IP address is theirs? >>> ++++++++++++++++++++++++++ >>> If they don't go directly to the home, they will constantly be: >>> - Unable to connect due home firewall/network changes >>> - Have to deal with an IP churn rate per home that will force >>> them to >>> change approaching 20% of their entries annually because >>> someone either >>> moves or change service providers. >>> - Will have to require their customers ALSO get an ISP to get load >>> control service. >>> ++++++++++++++++++++++++++ >> >> I understand 1 and 3, but I don't follow your middle point. You >> suggested government assignment, either to a physical address, in >> which case there's no churn, or to an owner, in which case the >> churn would happen anyway due to moves, regardless of whether the >> address was assigned by utility or government. >> >> >>>> You will need to interface to their control center somehow >>> to set your >>>> home systems/load controllers and that could be via any available >>>> networks but the actual controls will need to come in over their >>>> networks. >>> >>> I'm trying to understand your position: The power company needs to >>> build its own IP network in order to manage power systems at each >>> home; their IP address assignments will be from their aggregatable >>> block. >>> +++++++++++++++++++++++++ >>> Correct. >>> +++++++++++++++++++++++++ >>> >>>> Likewise government would like to give each home a permanent >>>> subnet from >>>> "its addresses" for their use especially including advanced >>>> EMS services >>>> such that they can handle both 911 and direct fire alarms. >>> I wouldn't >>>> be surprised if in a couple decades, your home City/County has your >>>> properties IP address on your deed. >>> >>> I would be surprised. IP addresses are not property, and are not >>> transferable in that sense. >>> ++++++++++++++++++++++++++ >>> We will see how it develops. My guess is that EMS will win although >>> with IP-v6 they could certainly allocate the address portion of the >>> space themselves to the property permanently and allow the network >>> portion to change. >>> ++++++++++++++++++++++++++ >> >> EMS will win what? I didn't know there was a contest. >> >> IP addresses are not property. They are identifying numbers, which >> are allocated or assigned based on policies created by the public >> and administered by the Regional Internet Registries, such as ARIN. >> They are fungible, and cannot be owned, bought or sold. >> >> >>>> I already have two ISP's serving my home; cable and DSL >>> both and will >>>> probably add an EVDO link with a third. In my case, because of the >>>> incredibly poor physical plant in my area, neither are very >>> reliable. >>>> >>>> Try this list, you can validate it with some of the folks working >>>> community networking: >>>> - Internet Service Provider >>>> - Entertainment Service Provider >>>> - Home Application Service Provider >>>> - Government Services >>>> - Communication Service Provider >>>> - Power Provider >>>> - Metering Provider >>>> - EMS (911 and fire alarm) >>>> - Security Service Provider >>>> >>>> None of these will be a simple single IP address either as most >>>> will >>>> have multiple controls or sensors serving your home. >>> >>> Would a /64 be sufficient for each, do you think? Especially if >>> they're not from a single aggregate block, this would be important >>> to understand. >>> +++++++++++++++++++++++++++ >>> I would certainly think so. >>> +++++++++++++++++++++++++++ >>> >>>> >>>> And no your ISP will NOT work as the sole provider of my home IP's! >>>> I'll personally fight that on capital hill! >>> >>> This is the place to fight for that, not Capitol Hill. >>> ++++++++++++++++++++++++++++ >>> I'd like to think so but history seems to say otherwise. >>> ++++++++++++++++++++++++++++ >> >> Please explain. >> >> >> >> >>>> We fought for the right not >>>> to be forced to switch phone numbers when we move and I'm on >>>> my 4th (or >>>> 5th) ISP serving my home in the last ten years. (AT&T, Earthlink, >>>> Qwest, MSN, Speakeasy, and Comcast, ok 6th) All of which >>> provided me >>>> with new IP's and email addresses which had no relation to any my >>>> previous ones so I had to contact everyone I emailed with and >>>> have them >>>> update my email address. Bill paying services make this even >>>> worse! It >>>> takes months to get them all updated; one-at-a-time. >>> >>> Just to make sure I understand your position: >>> You'd rather have nine provider aggregated addresses >>> (counting networks >>> above) than one (PI or PA) address? >>> +++++++++++++++++++++++++++++ >>> I think that is what will happen. Whether I care or not >>> depends on how >>> well they can hide the details. Regardless which option >>> wins, we cannot >>> expect the average homeowner to be able to deal IP networking >>> detail at this level. >>> +++++++++++++++++++++++++++++ >> >> What do you want to have happen? >> Can you explain how one plan or another affects homeowners? >> >> >>> There are some differences here. Your choice of local phone >>> carriers >>> has been extremely limited. The local carrier has physical >>> facilities >>> to your house; now the cable company and power company also have >>> facilities. An ISP provides a service using those facilities. They >>> may provide multiple services, including routing (pretty >>> essential, and >>> requiring aggregatable addressing) and maybe also email, but >>> these are >>> disjoint: there's no reason your Internet access provider has >>> to be your >>> email provider. >>> +++++++++++++++++++++++++++++ >>> Agreed but what we have to do is figure out how to provide >>> the homeowner >>> at stable set of logical addresses (email/web/voice/etc) that >>> map their >>> physical ones. Otherwise I am certain that local government will >>> win >>> here. >>> +++++++++++++++++++++++++++++ >> >> Again, win what? >> Since ARIN only administers IP addresses, can we discuss those >> separately? >> >> Is it necessary for email address, web site, and phone number >> to be permanently mapped to an IP address? Are no dynamic >> mappings possible which might make the IP address transparent >> to the homeowner? >> >> >>>> This is exactly why I would prefer a local government >>> provided IP that >>>> was associated with my home address that didn't change >>> until I moved! >>> >>> I must have misunderstood your previous points then. There are a >>> lot >>> of points to take away from this sentence: >>> 1. "Local" government meaning city, county, state, federal, or some >>> kind of regional Internet registry? >>> +++++++++++++++++++++++++++++++++ >>> The first four although the fifth could work. >>> +++++++++++++++++++++++++++++++++ >> >> >> In order to derive a policy, we need more detail. What do you >> advocate? >> >> >> >>> 2. You want a government authority to replace the current >>> system of IP >>> address allocation? Can you outline the ways in which this >>> is superior >>> to the current system? >>> ++++++++++++++++++++++++++++++++++ >>> NO, but that is what I will probably get. The reason is simple; >>> they >>> can provide me with a stable set of logical relationships >>> that map to my >>> physical home. A present this is simply not possible for a service >>> provider to do. >>> +++++++++++++++++++++++++++++++++++ >> >> >> Then what do you want? >> >> >>> >>> 3. How would IP addresses be "associated with my home address"? >>> Do you envision embedding physical address information in the IP >>> address, like GPS coordinates, or a database owned and operated by >>> the >>> government? >>> +++++++++++++++++++++++++++++++++++ >>> I think that either GPS or a government DB is most likely. >>> +++++++++++++++++++++++++++++++++++ >> >> Is that what you want? >> Can you provide a way of embedding GPS coordinates into IPv6 >> addresses? >> Does it scale? >> >> Can you describe such a government database? Maintainer, schema, >> etc. >> >> How would either of these be routed? >> >> >>> >>> 4. How would routing work? Would every network have to carry a >>> Separate route for every home? Or do you mean that local >>> governments >>> should take over all Internet access? >>> ++++++++++++++++++++++++++++++++++++ >>> In the scenario I envision occurring, local government just becomes >>> another "service provider" and each of the home service providers >>> does >>> their own routing. >>> ++++++++++++++++++++++++++++++++++++ >> >> >> I'm not quite sure I followed that. The local government becomes the >> Internet access provider? Or do they provide some other service? >> >> If the government assigns an address to be used by all of the other >> providers, there are significant routing implications. If there's >> any competition, then addresses cannot be aggregated, and a separate >> routing entry will have to be maintained for each address. Can you >> describe how that would scale, given even optimistic technology >> projections? If there's no competition, then we have nine completely >> separate networks, which do not overlap anywhere and cannot inter- >> connect. Also, a different form of government and economy. >> >> >>>> And I certainly don't want to worry that if I change ISP, >>> 911 or fire >>>> won't be able to find me. Likewise I want to keep my phone >>>> number when >>>> I move and my email even if I have to change service providers. >>>> >>>> Sorry but my view of the future world has little to do with >>>> today's! >>> >>> That's fair to say. I don't quite understand whether you favor >>> competition, monopolization, or nationalization. I'm hoping you can >>> clarify how routing might work in your vision. I definitely advise >>> you to take advantage of one of the many companies providing free >>> email, so that you don't have to go through the pain of updating >>> your >>> contacts next time you switch ISPs. Or you can set up your own mail >>> server, of course. >>> +++++++++++++++++++++++++++++++++++++ >>> I'm in favor of a solution that provides the home owner or >>> individual >>> with a set of "stable" logical relationships. I certainly won't go >>> through a "free email provider" as I need them to both be >>> around for the >>> long term and to be responsible. As an example, I keep paying MSN >>> monthly even though I have no used them as an ISP for over five >>> years; >>> this is simply to provide my wife a stable email for a large >>> non-profit >>> group she works with. It is that important! >>> +++++++++++++++++++++++++++++++++++++ >> >> If I have correctly interpreted your arguments, you advocate >> government control of networks and centralized, rigidly hierarchical >> networks which map exactly to geography. You also want those >> networks >> to map exactly to individuals, which seems to be a conflict. >> Perhaps smooth dynamic mappings between identifiers would require >> fewer fundamental changes to TCP/IP. >> >> Lee >> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml > From tli at tropos.com Fri Mar 17 12:31:55 2006 From: tli at tropos.com (Tony Li) Date: Fri, 17 Mar 2006 09:31:55 -0800 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BD22@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: <002a01c649e8$afb67b10$9901a8c0@tropos.com> > 1) We MUST provider users (individuals/government/business) > with logical > stability. Getting new IP addresses, DNS names, and email addresses > every time we either change providers or move will simply be > unacceptable. Without this logical stability, every communication > service (voice/email/etc) is unstable, industry-wide initiatives (i.e. > like power control) are not possible, and even gains the financial > institutions hope to make with EFT systems become limited > (i.e. remember > the fun of resetting all your automatic billings/payments email > addresses last time you changed service providers?). I know > this may be > more an IETF issue but I'm there next week. Any ideas on how to do this in a scalable fashion? If I interpret you literally, you seem to be advocating putting a /128 on each and every laptop, cell phone, and IP-capable toaster and then carrying all prefixes. Regards, Tony From Michael.Dillon at btradianz.com Fri Mar 17 12:41:25 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 17 Mar 2006 17:41:25 +0000 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BD22@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: > The aircraft MUST be able to join to many different > service provider networks as it moves around the world; we have carriers > that fly there aircraft literally around the world in a bit over a day. > The aircraft WILL most of the time have simultaneous links to multiple > service providers. An aircraft will probably have at least three > separate networks onboard: air traffic control, airline or operator, and > in-flight passenger services/entertainment.) This is the reason for giving EVERY end-site a /48. No matter which network you connect to, you can get a /48 for your connection and maintain the same internal subnet topology. The same issue arises with shipping containers, buses, travelling salesmen, freight companies, and others. Conservation of addresses should be at the very bottom of the priority list with IPv6. Maybe there is a case for making one small tweak by going to a /56 for single family dwellings, but that should be the end of it. We can't retrofit IPv4 scarcity-based policy into IPv6. > 4) We might as well come to terms with the idea that some of these must > be essentially irrevocable. Can anyone envision revoking the IP address > of an aircraft that is set up in air traffic control systems around the > world? I don't think irrevocability is an issue. If an address block is used, then you can keep on using it. If an address block is not used at all, then there should still be a process for revoking the allocation and recovering the address block. That process should require some sort of publication of notice like we do with bankruptcies, etc. --Michael Dillon From terry.l.davis at boeing.com Fri Mar 17 12:41:21 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Fri, 17 Mar 2006 09:41:21 -0800 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) In-Reply-To: <002a01c649e8$afb67b10$9901a8c0@tropos.com> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BD2D@XCH-NW-8V1.nw.nos.boeing.com> Tony Not at all! I do think that we have to often reasonable IP address stability (i.e. I don't think that services like local government, EMS, power, etc should ever change IP addresses for a physical location.) We need to come up with some stable personal and residential DNS and email schemes as develop v6. USPS, UPS, FEDEX, etc all deliver to my home address s0 why can't my current ISP deliver to a stable email/DNS name that is either personal or residential based? Take care Terry -----Original Message----- From: Tony Li [mailto:tli at tropos.com] Sent: Friday, March 17, 2006 9:32 AM To: Davis, Terry L; 'Howard, W. Lee'; ppml at arin.net Subject: RE: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) > 1) We MUST provider users (individuals/government/business) > with logical > stability. Getting new IP addresses, DNS names, and email addresses > every time we either change providers or move will simply be > unacceptable. Without this logical stability, every communication > service (voice/email/etc) is unstable, industry-wide initiatives (i.e. > like power control) are not possible, and even gains the financial > institutions hope to make with EFT systems become limited > (i.e. remember > the fun of resetting all your automatic billings/payments email > addresses last time you changed service providers?). I know > this may be > more an IETF issue but I'm there next week. Any ideas on how to do this in a scalable fashion? If I interpret you literally, you seem to be advocating putting a /128 on each and every laptop, cell phone, and IP-capable toaster and then carrying all prefixes. Regards, Tony From randy at psg.com Fri Mar 17 13:27:27 2006 From: randy at psg.com (Randy Bush) Date: Fri, 17 Mar 2006 10:27:27 -0800 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) References: <0D090F1E0F5536449C7E6527AFFA280A21BD24@XCH-NW-8V1.nw.nos.boeing.com> <86FB20CB-0A86-413D-8F3A-0CF09443FD0E@multicasttech.com> Message-ID: <17434.65423.548469.662842@roam.psg.com> > I actually think that a $ 100 million dollar aircraft with hundreds of > people and networked devices on board _should_ be an Autonomous system, > with its own PI address space to boot. 1930 talked about different routing policy, not how much the real estate costs or how many people were in it. randy From kloch at hotnic.net Fri Mar 17 14:12:11 2006 From: kloch at hotnic.net (Kevin Loch) Date: Fri, 17 Mar 2006 14:12:11 -0500 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) In-Reply-To: References: Message-ID: <441B0A0B.4060907@hotnic.net> Michael.Dillon at btradianz.com wrote: >>The aircraft MUST be able to join to many different >>service provider networks as it moves around the world; we have carriers >>that fly there aircraft literally around the world in a bit over a day. >>The aircraft WILL most of the time have simultaneous links to multiple >>service providers. An aircraft will probably have at least three >>separate networks onboard: air traffic control, airline or operator, and >>in-flight passenger services/entertainment.) > > > This is the reason for giving EVERY end-site a /48. No matter > which network you connect to, you can get a /48 for your connection > and maintain the same internal subnet topology. The same issue > arises with shipping containers, buses, travelling salesmen, > freight companies, and others. If the space assigned to an end site is based upon what they need and their needs don't change while switching providers, then there should be no problem getting the same size prefix from each provider. Why does it have to be a /48? - Kevin From Lee.Howard at stanleyassociates.com Fri Mar 17 14:14:44 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 17 Mar 2006 14:14:44 -0500 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4018CAB48@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Michael.Dillon at btradianz.com > Sent: Friday, March 17, 2006 12:41 PM > To: ppml at arin.net > Subject: Re: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) > > > The aircraft MUST be able to join to many different > > service provider networks as it moves around the world; we > have carriers > > that fly there aircraft literally around the world in a bit > over a day. > > The aircraft WILL most of the time have simultaneous links > to multiple > > service providers. An aircraft will probably have at least three > > separate networks onboard: air traffic control, airline or > operator, and > > in-flight passenger services/entertainment.) > > This is the reason for giving EVERY end-site a /48. No matter > which network you connect to, you can get a /48 for your connection > and maintain the same internal subnet topology. The same issue > arises with shipping containers, buses, travelling salesmen, > freight companies, and others. I'm not disagreeing, but what is the definition of "end site" here? The aircraft has a single /48? Or each user on the aircraft has a single /48? Or each network (air traffic control, air carrier, and passenger)? Are you also saying that each /48 be provider independent? Or are you saying it should be provider aggregatable, but the same prefix length so the internal topology doesn't have to change when you change access providers? Buses, trains or train cars, ships, tandem bicycles. Be specific. > --Michael Dillon Lee From alh-ietf at tndh.net Fri Mar 17 14:47:42 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 17 Mar 2006 11:47:42 -0800 Subject: [ppml] a modified proposal 2005-8 In-Reply-To: Message-ID: <15a701c649fb$a7da5340$a291150a@tndh.net> (Howard, W. Lee & bmanning below) Michael.Dillon wrote: > > >From a policy point of view, we must remember that the > IPv6 address space is finite. At the same time it is intended > to be very big so that it is very hard to use up all of the > space. Any scheme which maps some locator, like GPS coordinates, > directly onto the IPv6 address space, is likely to result in > large amounts of unusable address space due to the fact that > most territory on the earth is covered by ocean or uninhabited > wilderness. Therefore, the only politically tenable scheme > would be one that uses a database. This presumption is still open for political debate. Yes there will be some waste. The question becomes 'is that waste worth the value it returns in terms of simplicity and isolation from long term political squabbles?'. If you choose a strict database model you are presuming that there is still some organization that has rights and authority to decide who gets how much. At the same time the implication is that the organization remains as it is today. An alternate outcome might be that the RIR community casts the 'control' model followed by a take over by the UN/ITU who could then say 'we didn't define it'. > In fact, this type of > scheme is proven to work for interactive applications since > this is how phone number portability works. While that model works for service provider controlled applications, it would be more effort to implement for P2P application models. The timeliness of global database updates would have to be better than dns, and there is always the 'trust' issue about who has access and rights to make the change. The problem of crossing the trust boundary should not be minimized. > > Given that such mapping schemes are almost certain to > be based on a database, then there should be no scaling > problems. Then why does it take so long for simple dns changes to propagate globally? Wouldn't that be due to an operational requirement specifically implemented to deal with scale? After all DNS is a distributed database. Or are you assuming that this is a central database which has scaling issues in another dimension? There are always scaling problems; it is just a matter of finding the lowest cost trade-off. > > Security issues are another thing. Even if you propose > some sort of address translation scheme that maps a homeowner's > /64 onto the house's /64, this does not automatically allow > either the homeowner or the house to use an arbitrary range. > The power company who wishes to monitor and control home electrical > systems (presumably in return for a better rate) will want to > implement layers of security. One of those layers is a globally > unique IPv6 address range. Another layer is a entirely separate > physical path from the house for this address range. Inside > devices we can expect that the homeowner's /48 will touch the > same interfaces as the power company's /64, but the device itself > will have some strict routing controls to prevent exchange of > packets between the two network. The extent of the mixing is > unlikely to go beyond allowing the homeowner some visibility of > monitoring data and some ability to override settings (if they > will accept loss of their discount during the override period). There are many opportunities for different models than are currently in use. Presuming that isolation or uniqueness are required is based on current practice rather than what might make technical sense in any specific deployment. MIPv6 with IPsec/AES protection on the data would provide the logical isolation necessary for the utility provider, while at the same time allowing a 4193 based address to be routed via the home network public range. A different model would be a fixed firewall configuration only allowing inbound connections from pre-defined addresses to specific appliances. Both or neither might be considered 'secure' depending on who is defining the meaning of 'security'. The bottom line though is that presuming the world will continue with a PA-only for the home model 'just because the service provider wants it that way' is likely to lead to revolt and political requirements to fix the problem. > > If all of this sounds too pie in the sky for you, then we > have a failure of imagination. This is a bad thing considering > how the developers of IPv6 were already talking about an IPv6 > address for every lightbulb and light switch over 10 years ago. For reference look at: http://panasonic.co.jp/corp/news/official.data/data.dir/en060105-2/en060105- 2.html This is not just imagination, appliance vendors will be network enabling a vast array of non-traditional devices. Howard, W. Lee wrote: > Just because one changes does not mean the others need to change. > That's why we have DNS and logical pointers. The stack isn't > monolithic. There are several network protocols that can > accomodate this requirement, but TCP/IP isn't designed that way. It isn't -operated- that way. The only requirement for IP addresses to change comes from the desire to minimize cost in the routers. In any case, Terry's point is that the same kinds of 'technical' arguments were made before LNP was mandated. Note the politicians didn't care and required the technical community to get over it. If you put a hard stake in the ground about PA for consumers it is likely the same result will occur. If you appear to be working toward a middle ground that provides a level of stability to the home user without the scaling problems inherent in a database model, then the politicians will likely back off and give you a chance. > I've changed providers at home four times in the last two years. > My personal web site and my personal email address have been > unaffected. I reduced my DNS TTLs, made the DNS change, and cranked > the TTLs back up. I run my own server, but it would have been as > easy if I'd been hosted. Obviously you run with static addresses. While there are ddns services out there, it is still not trivial for the average consumer to make this work. As long as DNS as a system is built and operated in 'guru's only' mode, there is no hope that it can be used to mask over the mandatory change you advocate by PA-only. > We're still talking about residences, right? ... > Do these three networks need one /64, three /64s, or one /62? I know the context changed in the original note, but it applies to both the home and plane cases. The answer is that it depends on the goals of the end network operator, and the mix of technologies in use. Multi-media bridging is just a broken concept and history is full of failed attempts. Unless you restrict all future networks to use today's link-layer 'ethernet' technology then the answer has to be they always need more than a single /64. If you want to do 'simple' reverse dns delegation and management then nibble boundaries are called for. Finally if the operator of the network wants isolation then more subnets are required. Why should ARIN or a service provider get to decide if their 'want' justifies more than a single /64, or /60? The IPv4 space was limited and needed oversight. In IPv6 a degree of oversight is appropriate, but there are diminishing returns to consider. It would be very easy to waste the majority of the IPv6 space by refusing to let people have as much as they would use thereby driving them to find a replacement sooner than they will otherwise. When it never gets used due to replacement it is just as wasted as if it gets handed out in too large a block and remains idle. > ... > Is the passenger laptop on board supposed to use an aircraft IP > address, or its home address? The answer is yes, depending on the specific application. If the app is onboard entertainment it should use an address from the aircraft. If the application is VoIP then it should use its home address so inbound calls can find it. Fortunately IPv6 allows for both to exist at once. The alternative would be a single address & ddns system that was globally responsive enough to deal with the update rate, not to mention one that actually trusted the endpoint to make changes as it moved around. > Remote participation is also an option. Doesn't always work well. bmanning wrote: > One of the > current difficulties of the RIR system is that it is designed > to be bottom-up, consensus-driven when it comes to address > assignment policies. That type of methodology works very well > for a well established modality - is very hard to try radical > new ideas ... but ARIN seems to be more responsive in this regard > than many RIR/LIRs.. perhaps not responsive enough for some. :) This actually hits the mark dead on. To a first order the RIR community needs to get over the fact that we will waste IPv6 space. This is directly counter to their stated goals as stewards, but is a reality no matter how well the space is managed. Even with current policies we will see a replacement due to other technology changes long before the 500 years that the proposed HD ratio change will provide (assuming we have defined a protocol to last for all time is just a bit arrogant). The balance is that the goal needs to be 'make it possible to run several hundred years', rather than 'make sure we don't waste any along the way'. We can define geo models for stable PI that will have different waste characteristics. The 'control' minded will prefer city-code or rir/area approaches where they can maintain a level of power. The fixed-allocation approach will have a clearly identifiable waste in space (at least for today's perception of habitability), while it removes the continuous 'wasted energy' of political control/pushback. The current PA-biased policy favors control, while the end sites are wasting energy pushing back to demand independence through PI. The 'give a little but reserve the right to refuse' middle ground is just looking for a point where power is retained while only acquiescing to the equally powerful end sites. The open question is how one defines waste? Tony From owen at delong.com Fri Mar 17 18:21:11 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Mar 2006 15:21:11 -0800 Subject: [ppml] a modified proposal 2005-8 In-Reply-To: <15a701c649fb$a7da5340$a291150a@tndh.net> References: <15a701c649fb$a7da5340$a291150a@tndh.net> Message-ID: <52BF6EBAA247BCC5B62A5F28@imac-en0.delong.sj.ca.us> --On March 17, 2006 11:47:42 AM -0800 Tony Hain wrote: > (Howard, W. Lee & bmanning below) > Michael.Dillon wrote: >> >> > From a policy point of view, we must remember that the >> IPv6 address space is finite. At the same time it is intended >> to be very big so that it is very hard to use up all of the >> space. Any scheme which maps some locator, like GPS coordinates, >> directly onto the IPv6 address space, is likely to result in >> large amounts of unusable address space due to the fact that >> most territory on the earth is covered by ocean or uninhabited >> wilderness. Therefore, the only politically tenable scheme >> would be one that uses a database. > > This presumption is still open for political debate. Yes there will be > some waste. The question becomes 'is that waste worth the value it > returns in terms of simplicity and isolation from long term political > squabbles?'. If you choose a strict database model you are presuming that > there is still some organization that has rights and authority to decide > who gets how much. At the same time the implication is that the > organization remains as it is today. An alternate outcome might be that > the RIR community casts the 'control' model followed by a take over by > the UN/ITU who could then say 'we didn't define it'. > And if you go with a strictly positional model, then, you assume that all population density is equal. The idea of a /128 per square foot sounds great until you consider the possibility of a 100 story office building with 10 floors of high-density colocation (45 1U servers per cabinet) and 90 floors of moderate to high density office. >> In fact, this type of >> scheme is proven to work for interactive applications since >> this is how phone number portability works. > > While that model works for service provider controlled applications, it > would be more effort to implement for P2P application models. The > timeliness of global database updates would have to be better than dns, > and there is always the 'trust' issue about who has access and rights to > make the change. The problem of crossing the trust boundary should not be > minimized. > The timeliness of global updates only needs to be better than DNS if the churn rate is higher. If instead of changing the addresses, we change indirect the addresses to one or more routing locators through the same database, then, the routing locator updates don't actually need to be all that timely since they will not change often (where often is defined as a given record changing more than once every 5 minutes or so). >> >> Given that such mapping schemes are almost certain to >> be based on a database, then there should be no scaling >> problems. > > Then why does it take so long for simple dns changes to propagate > globally? Wouldn't that be due to an operational requirement specifically > implemented to deal with scale? After all DNS is a distributed database. > Or are you assuming that this is a central database which has scaling > issues in another dimension? There are always scaling problems; it is > just a matter of finding the lowest cost trade-off. > DNS changes with short TTLs propogate quite rapidly. If I sent the TTL on my DNS record to 60, then, generally speaking, (other than buggy clients), I can depend on everyone getting the new version within 120 seconds. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Lee.Howard at stanleyassociates.com Fri Mar 17 18:34:38 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 17 Mar 2006 18:34:38 -0500 Subject: [ppml] a modified proposal 2005-8 Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4018CAC61@CL-S-EX-1.stanleyassociates.com> > Howard, W. Lee wrote: > > > Just because one changes does not mean the others need to change. > > That's why we have DNS and logical pointers. The stack isn't > > monolithic. There are several network protocols that can > > accomodate this requirement, but TCP/IP isn't designed that way. > > It isn't -operated- that way. The only requirement for IP addresses to > change comes from the desire to minimize cost in the routers. That's a couple of logical steps from my statement, but I see how you get there. I would still say that layer 3 changes don't necessarily require layer 7 changes, which is why we have a layered model. > If you appear to be working toward a middle ground that > provides a level of > stability to the home user without the scaling problems inherent in a > database model, then the politicians will likely back off and > give you a chance. I've heard two home users say they don't like having to change IP addresses when they change ISPs. One of them said they didn't like it because they had to change email addresses and web addresses, and I'm not convinced those are all related. Should ARIN conduct a poll of random homeowners to see if IP address portability is a common concern? > > I've changed providers at home four times in the last two years. > > My personal web site and my personal email address have been > > unaffected. I reduced my DNS TTLs, made the DNS change, and cranked > > the TTLs back up. I run my own server, but it would have been as > > easy if I'd been hosted. > > Obviously you run with static addresses. While there are ddns > services out > there, it is still not trivial for the average consumer to > make this work. > As long as DNS as a system is built and operated in 'guru's > only' mode, > there is no hope that it can be used to mask over the > mandatory change you advocate by PA-only. I think you passed my point. Yes, this works with static addresses. If you have dynamic addresses, you can either do dDNS magic, or have your services hosted by someone other than your access provider. There are multiple ways to skin this cat, and permanent assignment of provider-independent is one. Is it the best one? To evaluate "best," it's important to understand the implications. I've backed off my PA-only stance. As a board member, I try not to advocate for or against policy, but I do try to make sure I understand what other people are advocating for or against. > > We're still talking about residences, right? > ... > > Do these three networks need one /64, three /64s, or one /62? > > I know the context changed in the original note, but it > applies to both the > home and plane cases. The answer is that it depends on the > goals of the end > network operator, and the mix of technologies in use. > Multi-media bridging > is just a broken concept and history is full of failed > attempts. I don't know what that means. Is that bridging as I understand it in the Ethernet world, applied to multiple layer 2 protocols? You offer three sets of policy spaces: 1. > Unless you restrict all future networks to use today's link-layer > 'ethernet' technology > then the answer has to be they always need more than a single > /64. 2. > If you > want to do 'simple' reverse dns delegation and management then nibble > boundaries are called for. 3. > Finally if the operator of the network wants > isolation then more subnets are required. With #1 and #2, should the home be assigned a /62? /48? Then each network gets a separate /64 slice? I'm having trouble understanding the routing, unless it's a separate route entry for every house /64. Or /48. Or does each network assign its own /64? This is the current policy. > Why should ARIN or a service > provider get to decide if their 'want' justifies more than a > single /64, or /60? The IPv4 space was limited and needed oversight. In IPv6 > a degree of > oversight is appropriate, but there are diminishing returns > to consider. What level of oversight do you suggest? On what grounds would it be appropriate to deny a request for additional IPv6 address space? > It > would be very easy to waste the majority of the IPv6 space by > refusing to > let people have as much as they would use thereby driving > them to find a > replacement sooner than they will otherwise. When it never > gets used due to > replacement it is just as wasted as if it gets handed out in > too large a block and remains idle. Well said. > > ... > > Is the passenger laptop on board supposed to use an aircraft IP > > address, or its home address? > > The answer is yes, depending on the specific application. If > the app is > onboard entertainment it should use an address from the > aircraft. If the > application is VoIP then it should use its home address so > inbound calls can > find it. Fortunately IPv6 allows for both to exist at once. > The alternative > would be a single address & ddns system that was globally > responsive enough > to deal with the update rate, not to mention one that > actually trusted the > endpoint to make changes as it moved around. How does that phone call find you, if you're still using your home prefix? We're still in that endpoint-network identifier spin. I don't say it can't, I'm asking for education. > > Remote participation is also an option. > > Doesn't always work well. I agree it's not as good as being there, but it's participation, and it's an option. > The open question is how one defines waste? Goals: IPv6 for a hundred years or so. Do not outpace routing. Lee > Tony From alh-ietf at tndh.net Fri Mar 17 18:54:31 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 17 Mar 2006 15:54:31 -0800 Subject: [ppml] a modified proposal 2005-8 In-Reply-To: <52BF6EBAA247BCC5B62A5F28@imac-en0.delong.sj.ca.us> Message-ID: <15e601c64a1e$22c2e4b0$a291150a@tndh.net> Owen DeLong wrote: > ... > And if you go with a strictly positional model, then, you assume that > all population density is equal. The idea of a /128 per square foot > sounds great until you consider the possibility of a 100 story > office building with 10 floors of high-density colocation (45 > 1U servers per cabinet) and 90 floors of moderate to high density > office. draft-hain-ipv6-pi-addr shows how to map a /48 per sq meter (equatorial approximation). There is a discussion about altitude because people kept insisting it needed one, but it is currently broken as it doesn't account for surface variations. In any case, high rise buildings are not mounted on a pinnacle foundation, so there are a large number of /48 prefixes available to work with. > > >> In fact, this type of > >> scheme is proven to work for interactive applications since > >> this is how phone number portability works. > > > > While that model works for service provider controlled applications, it > > would be more effort to implement for P2P application models. The > > timeliness of global database updates would have to be better than dns, > > and there is always the 'trust' issue about who has access and rights to > > make the change. The problem of crossing the trust boundary should not > be > > minimized. > > > The timeliness of global updates only needs to be better than DNS if > the churn rate is higher. If instead of changing the addresses, > we change indirect the addresses to one or more routing locators > through the same database, then, the routing locator updates don't > actually need to be all that timely since they will not change > often (where often is defined as a given record changing more > than once every 5 minutes or so). No matter how you do it some part of a distributed database will need timely updates. Shell games claiming to make the problem go away by moving them somewhere else don't actually solve the problem. This is why the double nat locator replacement approaches fail. You can always know enough locally to do the front end part, but getting that propagated to the system that will have to translate back (and even knowing where that is) will be a non-trivial problem. > > > >> > >> Given that such mapping schemes are almost certain to > >> be based on a database, then there should be no scaling > >> problems. > > > > Then why does it take so long for simple dns changes to propagate > > globally? Wouldn't that be due to an operational requirement > specifically > > implemented to deal with scale? After all DNS is a distributed database. > > Or are you assuming that this is a central database which has scaling > > issues in another dimension? There are always scaling problems; it is > > just a matter of finding the lowest cost trade-off. > > > DNS changes with short TTLs propogate quite rapidly. If I sent the > TTL on my DNS record to 60, then, generally speaking, (other than > buggy clients), I can depend on everyone getting the new version > within 120 seconds. And the reason that all records are not set with short ttl's is that the resulting query rate would cause the global system to roll over. The trick is knowing at least the current ttl's setting in advance that you will need to move so you can set it short soon enough to affect the move in a timely manner; then setting it back to a long value after the move to reduce query rates. 'Just set the ttl' is an easy generalization to make when it has sufficient advanced notice. It also requires someone with the technical understanding to know what to change and when. Tony From terry.l.davis at boeing.com Fri Mar 17 19:00:16 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Fri, 17 Mar 2006 16:00:16 -0800 Subject: [ppml] a modified proposal 2005-8 In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4018CAC61@CL-S-EX-1.stanleyassociates.com> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BD3C@XCH-NW-8V1.nw.nos.boeing.com> Tony/Lee Thanks for the input. I'll try to catch up then I have get off for the weekend (otherwise I'll have more problems to deal with as we are re-modeling and my half thinks I have priorities misplaced!). - We still need to figure out a working routing protocol that will scale. I agree with Randy here but I think we will have to be "forced" to fix it just like with v4. - In thinking about the homeowner, I consider my relatives. Basically outside of myself and one other member, those older than 40 have a real problem understanding all these issues. The solution has to be simple like the current phone system; in my opinion we are not even close to having something the average homeowner can use really well. - Yes there are lots of ways to skin the "logical stability" issue. It is up to US (the technical community) to figure this out and not to try pass off the problem. If we don't , either the USPS or the UN will win the debate, I'm not sure I like either of those options. - In reality, there is NO need for the individual networks a user (individual or business) has on their facility/property to route between each other. Keep in mind that with IP-v6, any system I have can be on multiple networks with one adapter. And they do NOT have to route between each other; mostly they probably should not. (Microsoft has allowed this for years on IP-v4) - For IP-v6 inbound calls to an aircraft, nope you do NOT get to make them until the "aircraft" initiates a secure tunneled link to the ground. And then if you are in right place and PERMITTED (i.e. a voice provider) then phones registered on that aircraft could receive incoming calls. In general, do not expect to get direct access from the Internet to an aircraft in any case; the developing standards will prohibit that. The aircraft will open to a gateway with limited access. Hope this helps. Take care Terry PS: Howard if you are going to be in Dallas for the IETF, please email me. -----Original Message----- From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] Sent: Friday, March 17, 2006 3:35 PM To: Tony Hain; ppml at arin.net Subject: Re: [ppml] a modified proposal 2005-8 > Howard, W. Lee wrote: > > > Just because one changes does not mean the others need to change. > > That's why we have DNS and logical pointers. The stack isn't > > monolithic. There are several network protocols that can > > accomodate this requirement, but TCP/IP isn't designed that way. > > It isn't -operated- that way. The only requirement for IP addresses to > change comes from the desire to minimize cost in the routers. That's a couple of logical steps from my statement, but I see how you get there. I would still say that layer 3 changes don't necessarily require layer 7 changes, which is why we have a layered model. > If you appear to be working toward a middle ground that > provides a level of > stability to the home user without the scaling problems inherent in a > database model, then the politicians will likely back off and > give you a chance. I've heard two home users say they don't like having to change IP addresses when they change ISPs. One of them said they didn't like it because they had to change email addresses and web addresses, and I'm not convinced those are all related. Should ARIN conduct a poll of random homeowners to see if IP address portability is a common concern? > > I've changed providers at home four times in the last two years. > > My personal web site and my personal email address have been > > unaffected. I reduced my DNS TTLs, made the DNS change, and cranked > > the TTLs back up. I run my own server, but it would have been as > > easy if I'd been hosted. > > Obviously you run with static addresses. While there are ddns > services out > there, it is still not trivial for the average consumer to > make this work. > As long as DNS as a system is built and operated in 'guru's > only' mode, > there is no hope that it can be used to mask over the > mandatory change you advocate by PA-only. I think you passed my point. Yes, this works with static addresses. If you have dynamic addresses, you can either do dDNS magic, or have your services hosted by someone other than your access provider. There are multiple ways to skin this cat, and permanent assignment of provider-independent is one. Is it the best one? To evaluate "best," it's important to understand the implications. I've backed off my PA-only stance. As a board member, I try not to advocate for or against policy, but I do try to make sure I understand what other people are advocating for or against. > > We're still talking about residences, right? > ... > > Do these three networks need one /64, three /64s, or one /62? > > I know the context changed in the original note, but it > applies to both the > home and plane cases. The answer is that it depends on the > goals of the end > network operator, and the mix of technologies in use. > Multi-media bridging > is just a broken concept and history is full of failed > attempts. I don't know what that means. Is that bridging as I understand it in the Ethernet world, applied to multiple layer 2 protocols? You offer three sets of policy spaces: 1. > Unless you restrict all future networks to use today's link-layer > 'ethernet' technology > then the answer has to be they always need more than a single > /64. 2. > If you > want to do 'simple' reverse dns delegation and management then nibble > boundaries are called for. 3. > Finally if the operator of the network wants > isolation then more subnets are required. With #1 and #2, should the home be assigned a /62? /48? Then each network gets a separate /64 slice? I'm having trouble understanding the routing, unless it's a separate route entry for every house /64. Or /48. Or does each network assign its own /64? This is the current policy. > Why should ARIN or a service > provider get to decide if their 'want' justifies more than a > single /64, or /60? The IPv4 space was limited and needed oversight. In IPv6 > a degree of > oversight is appropriate, but there are diminishing returns > to consider. What level of oversight do you suggest? On what grounds would it be appropriate to deny a request for additional IPv6 address space? > It > would be very easy to waste the majority of the IPv6 space by > refusing to > let people have as much as they would use thereby driving > them to find a > replacement sooner than they will otherwise. When it never > gets used due to > replacement it is just as wasted as if it gets handed out in > too large a block and remains idle. Well said. > > ... > > Is the passenger laptop on board supposed to use an aircraft IP > > address, or its home address? > > The answer is yes, depending on the specific application. If > the app is > onboard entertainment it should use an address from the > aircraft. If the > application is VoIP then it should use its home address so > inbound calls can > find it. Fortunately IPv6 allows for both to exist at once. > The alternative > would be a single address & ddns system that was globally > responsive enough > to deal with the update rate, not to mention one that > actually trusted the > endpoint to make changes as it moved around. How does that phone call find you, if you're still using your home prefix? We're still in that endpoint-network identifier spin. I don't say it can't, I'm asking for education. > > Remote participation is also an option. > > Doesn't always work well. I agree it's not as good as being there, but it's participation, and it's an option. > The open question is how one defines waste? Goals: IPv6 for a hundred years or so. Do not outpace routing. Lee > Tony _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From alh-ietf at tndh.net Sat Mar 18 15:57:45 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Sat, 18 Mar 2006 12:57:45 -0800 Subject: [ppml] a modified proposal 2005-8 In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4018CAC61@CL-S-EX-1.stanleyassociates.com> Message-ID: <162b01c64ace$9b7dd030$a291150a@tndh.net> Howard, W. Lee wrote: > ... > > It isn't -operated- that way. The only requirement for IP addresses to > > change comes from the desire to minimize cost in the routers. > > That's a couple of logical steps from my statement, but I see how you > get there. I would still say that layer 3 changes don't necessarily > require layer 7 changes, which is why we have a layered model. The layering design means it is not 'necessary' for upper layers to know the details below, but for a variety of reasons application programmers believe they need to violate the layers. > > > If you appear to be working toward a middle ground that > > provides a level of > > stability to the home user without the scaling problems inherent in a > > database model, then the politicians will likely back off and > > give you a chance. > > I've heard two home users say they don't like having to change IP > addresses when they change ISPs. One of them said they didn't like > it because they had to change email addresses and web addresses, and > I'm not convinced those are all related. Should ARIN conduct a poll > of random homeowners to see if IP address portability is a common > concern? A survey would not hurt, but it might not help much either. Most politicians are less clueful than their constituents and would equate IP address changes with phone number changes because they are represented in numerical form. You can argue all day that the name string solves the problem, but to the non-technical a number is a number. > ... > There are multiple ways to skin this cat, and permanent assignment > of provider-independent is one. Is it the best one? To evaluate > "best," it's important to understand the implications. Yes, and it is important to realize that 'best' is relative to ones viewpoint. PA pushes the costs to the edge. Clearly best for the core operators, but no so for the edge operators. PI does the inverse. In IPv4 you were effectively forced to choose one or the other. Multi-homed sites essentially required, and end users had a bias toward PI because they did not want to deal with renumbering when changing providers. In the IPv6 design multiple simultaneous prefixes were added to help mitigate the renumbering and some of the multi-homing issues. For some organizations the multiple prefix approach is still insufficient to deal with their multi-homing cases, so we still need to provide PI. Defining PI in a way that avoids overwhelming routing and minimizes the need for justification/detailed-analysis is the current challenge. > > I've backed off my PA-only stance. As a board member, I try not to > advocate for or against policy, but I do try to make sure I > understand what other people are advocating for or against. I am not keeping tabs on who is taking what stance. If I appeared to be making a case that you were personally taking a position I apologize because I didn't mean to. I was trying to stay aware and avoid the use of the collective use of the word 'you' because it could be misinterpreted as a directed personal sense, but it appears I screwed up in the discussion about finding a middle ground. > > > > > We're still talking about residences, right? > > ... > > > Do these three networks need one /64, three /64s, or one /62? > > > > I know the context changed in the original note, but it > > applies to both the > > home and plane cases. The answer is that it depends on the > > goals of the end > > network operator, and the mix of technologies in use. > > Multi-media bridging > > is just a broken concept and history is full of failed > > attempts. > > I don't know what that means. Is that bridging as I understand > it in the Ethernet world, applied to multiple layer 2 protocols? Yes. While it appears to be a simple design to strip off one L2 header and replace it with another, the actual semantics of differing media types make the resulting frames non-compliant in some way or another. There has been a fairly long running convergence on 'ethernet' as a framing technology, simply to deal with this problem. Unfortunately media semantics have suffered as a result (ie: 802.11 is less than optimal for what they might have had with a clean slate for design). We are rapidly approaching the point where the cost of maintaining compatibility will outweigh the risk of starting fresh, as the overhead and limitations at 10G already show. There will be new media types in the home over the life of IPv6. IP over 1394 may not have done much, but something in the space of consumer media will come up with an optimization that has non-ethernet framing, and will need IPv6 to work over it. This is where the layering design provides value. > > You offer three sets of policy spaces: > 1. > > Unless you restrict all future networks to use today's link-layer > > 'ethernet' technology > > then the answer has to be they always need more than a single > > /64. > > 2. > > If you > > want to do 'simple' reverse dns delegation and management then nibble > > boundaries are called for. > > 3. > > Finally if the operator of the network wants > > isolation then more subnets are required. > > With #1 and #2, should the home be assigned a /62? /48? 2 argues that it should be /44, /48, /52, /56, or /60. > Then each network gets a separate /64 slice? Each media type, or other reason for a separate subnet would get a /64 from that list. > I'm having trouble > understanding the routing, unless it's a separate route entry for every > house /64. Or /48. > Or does each network assign its own /64? This is the current policy. In the PA case there is a protocol called DHCP-PD which is designed to allow the provider to allocate a prefix block to the customer. Assuming the assigned block is shorter than a /64 the customer then uses whatever method locally to manage the set of /64's in the block. The service provider has a single route to the assigned block, but that route should be from an aggregate assigned to the pop so the explicit routes for a collection of homes is only known where they attach. If the customer is multi-homed to that provider, with the appropriate agreements the customer might announce back more specifics along with the aggregate from each attachment point. The world outside that provider should only need to know the aggregating prefix though. In the PI case the prefix lengths would be the same to minimize managing subnet design, but the route would not aggregate under the provider pop. A totally random (sequential first-come) assignment scheme assures there will never be aggregation of those PI prefixes. A regional assignment scheme starts to allow the thought of aggregation, but requires sufficient foresight to draw the boundaries in line with future demands. City based schemes go further in terms of optimizing aggregates with current need, but will be challenged by population shifts over time. The approach I have been looking at is flexible about where aggregates are applied, vs. where they are not worth the effort, so it can evolve to meet current need at any point. Any of the aggregation schemes will require different business models than the current free-for-all approach. The carriers know how to do structured interconnection in the PSTN space; to know how and where to route the detail below the aggregates. That structure will need to be developed before the uptake of any aggregating PI approach finds widespread use. > > > Why should ARIN or a service > > provider get to decide if their 'want' justifies more than a > > single /64, or /60? The IPv4 space was limited and needed oversight. > In IPv6 > > a degree of > > oversight is appropriate, but there are diminishing returns > > to consider. > > What level of oversight do you suggest? The IAB recommendation at /48 was partially intended to minimize any oversight to only the vary rare cases where that could be clearly shown to be insufficient. A /56 default would keep most SOHO users at bay, but might end up with a lot of work for the medium and large businesses. > On what grounds would it be appropriate to deny a request for additional > > IPv6 address space? This is the hard question, because there is a subtle difference between stewardship and a policing action (fairness vs. power). Clearly one needs to be able to say no, or everyone will fall into the ego driven 'mine is bigger' mode until it is all gone. At the same time there is a cost to evaluating requests, both in developing and reviewing, so blanket requirements for review impedes utility while it increases the staffing demands of the reviewer. As Manning pointed out, the case-by-case evaluation in the context of today's norm makes it hard to deal with new ideas. Larger than currently necessary defaults allows for new deployment concepts without strict oversight that might prematurely cut them off. The thing is that none of this actually answers your question about what defines a valid reason to say no. I have gone around on this point a few times and every time it strengthens my bias toward approaches that minimize the need to even consider the question. This logically leads to 'give everyone PI, no questions asked'. While that is a fine thing to say, it leads to 'how much', and 'what about routing'? 'How much' should be dealt with in a way that doesn't required detailed evaluation; equal amounts aligned with something existing, non-controversial, and trivial to measure. Dealing with routing requires the ability to abstract out the pockets where uptake is causing a table size problem and the remote network doesn't perceive a difference anyway. Once you get to this point it is just a matter of which optimization makes the most economic sense. I happen to prefer an optimization that precludes any political influence, and is insulated from population shifts over time. It has a well documented 'waste of space' in terms of today's population distribution. No approach will be perfect, as they will be the result of engineering/policy trade-offs (the 'designed by committee' problem). Whatever we do will be perceived to be the least cost/risk path at the time, and will be questioned a generation down the road when all the issues are long forgotten. > > > It > > would be very easy to waste the majority of the IPv6 space by > > refusing to > > let people have as much as they would use thereby driving > > them to find a > > replacement sooner than they will otherwise. When it never > > gets used due to > > replacement it is just as wasted as if it gets handed out in > > too large a block and remains idle. > > Well said. > > > > > ... > > > Is the passenger laptop on board supposed to use an aircraft IP > > > address, or its home address? > > > > The answer is yes, depending on the specific application. If > > the app is > > onboard entertainment it should use an address from the > > aircraft. If the > > application is VoIP then it should use its home address so > > inbound calls can > > find it. Fortunately IPv6 allows for both to exist at once. > > The alternative > > would be a single address & ddns system that was globally > > responsive enough > > to deal with the update rate, not to mention one that > > actually trusted the > > endpoint to make changes as it moved around. > > How does that phone call find you, if you're still using your home > prefix? We're still in that endpoint-network identifier spin. I > don't say it can't, I'm asking for education. Mipv6 would be a dynamic way to handle the problem, while a vpn would be a more nailed up approach. Both would use the aircraft address for bit delivery, but the application would be working in terms of the home address. Layer violation? Yes. Requirement to satisfy app developers? Also yes. > > > > Remote participation is also an option. > > > > Doesn't always work well. > > I agree it's not as good as being there, but it's participation, > and it's an option. > > > The open question is how one defines waste? > > Goals: > IPv6 for a hundred years or so. > Do not outpace routing. Don't forget, allows for new concepts to move beyond past limitations. Tony From owen at delong.com Sun Mar 19 06:17:28 2006 From: owen at delong.com (Owen DeLong) Date: Sun, 19 Mar 2006 03:17:28 -0800 Subject: [ppml] a modified proposal 2005-8 In-Reply-To: <15e601c64a1e$22c2e4b0$a291150a@tndh.net> References: <15e601c64a1e$22c2e4b0$a291150a@tndh.net> Message-ID: <1BC4CA09BED59C8A4B6158D7@imac-en0.delong.sj.ca.us> >> The timeliness of global updates only needs to be better than DNS if >> the churn rate is higher. If instead of changing the addresses, >> we change indirect the addresses to one or more routing locators >> through the same database, then, the routing locator updates don't >> actually need to be all that timely since they will not change >> often (where often is defined as a given record changing more >> than once every 5 minutes or so). > > No matter how you do it some part of a distributed database will need > timely updates. Shell games claiming to make the problem go away by > moving them somewhere else don't actually solve the problem. This is why > the double nat locator replacement approaches fail. You can always know > enough locally to do the front end part, but getting that propagated to > the system that will have to translate back (and even knowing where that > is) will be a non-trivial problem. > Which is why I propose not doing the back end part. My proposal is that the first DFZ capable router in the path traversed by the packet would perform a lookup to map IP->ASN(s). Then, from that lookup, it would insert the ASN into a type 53 extension header. Subsequent DFZ routers would forward towards the tagged ASN ignoring the unaltered prefix address in the destination field until the packet arrived at the tagged ASN. It would then be prefix routed based on the original destination prefix still contained in the packet. Thus, the only distributed updates required are: 1. IP->ASN mappings (which only change when a prefix moves from one ASN to another, not a particularly rapid process) 2. AS Path data (which is a subset of what BGP currently distributes). > And the reason that all records are not set with short ttl's is that the > resulting query rate would cause the global system to roll over. The trick > is knowing at least the current ttl's setting in advance that you will > need to move so you can set it short soon enough to affect the move in a > timely manner; then setting it back to a long value after the move to > reduce query rates. 'Just set the ttl' is an easy generalization to make > when it has sufficient advanced notice. It also requires someone with the > technical understanding to know what to change and when. > As a general rule, people don't move their prefix from one ASN to another without some advanced notice. Very few DNS records have more than an 86400 TTL. If you have more than a day's advanced notice, you're good to go. A lot of people today use 900 seconds on records they expect to update somewhat regularly (and the resulting query rat hasn't killed the system yet). Is 15 minutes really that long to wait if you failed to plan your network move? Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Sun Mar 19 06:47:41 2006 From: owen at delong.com (Owen DeLong) Date: Sun, 19 Mar 2006 03:47:41 -0800 Subject: [ppml] a modified proposal 2005-8 In-Reply-To: <162b01c64ace$9b7dd030$a291150a@tndh.net> References: <162b01c64ace$9b7dd030$a291150a@tndh.net> Message-ID: >> I've heard two home users say they don't like having to change IP >> addresses when they change ISPs. One of them said they didn't like >> it because they had to change email addresses and web addresses, and >> I'm not convinced those are all related. Should ARIN conduct a poll >> of random homeowners to see if IP address portability is a common >> concern? > > A survey would not hurt, but it might not help much either. Most > politicians are less clueful than their constituents and would equate IP > address changes with phone number changes because they are represented in > numerical form. You can argue all day that the name string solves the > problem, but to the non-technical a number is a number. > While I would agree that name-based abstraction is a solution in some contexts, I have to say that it is not a valid assertion for all contexts of internet usage. I don't consider myself to be clueless or non-technical about this stuff. Doubtless, at least someone on this list will disagree with my self assessment, but, I think most would agree. Do you know of anyone who implements VPN terminations or ACLs based on names and not addresses? >> ... >> There are multiple ways to skin this cat, and permanent assignment >> of provider-independent is one. Is it the best one? To evaluate >> "best," it's important to understand the implications. > > Yes, and it is important to realize that 'best' is relative to ones > viewpoint. PA pushes the costs to the edge. Clearly best for the core > operators, but no so for the edge operators. PI does the inverse. In IPv4 > you were effectively forced to choose one or the other. Multi-homed sites > essentially required, and end users had a bias toward PI because they did > not want to deal with renumbering when changing providers. In the IPv6 > design multiple simultaneous prefixes were added to help mitigate the > renumbering and some of the multi-homing issues. For some organizations > the multiple prefix approach is still insufficient to deal with their > multi-homing cases, so we still need to provide PI. Defining PI in a way > that avoids overwhelming routing and minimizes the need for > justification/detailed-analysis is the current challenge. > This is why I believe we need to find a way to do core routing based on numbers that represent topological aggregations, and, leave the end sites with end system identifiers that are independent of the topological numbers. In other words, I think that AS-based routing at the core with prefix-based routing at the edge and portable prefixes is the better long term solution. The only catch is finding a way to either distribute or resolve the IP->AS(s) mapping in a timely manner. I think there are existing technologies that can do this. Sure, SS7 doesn't quite fit the internet model, but, there are lessons to be learned from it. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at btradianz.com Sun Mar 19 18:17:10 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Sun, 19 Mar 2006 23:17:10 +0000 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) In-Reply-To: <441B0A0B.4060907@hotnic.net> Message-ID: > > This is the reason for giving EVERY end-site a /48. No matter > > which network you connect to, you can get a /48 for your connection > > and maintain the same internal subnet topology. The same issue > > arises with shipping containers, buses, travelling salesmen, > > freight companies, and others. > > If the space assigned to an end site is based upon what they need > and their needs don't change while switching providers, then there > should be no problem getting the same size prefix from each provider. > Why does it have to be a /48? First of all, it is not based on their needs in the same way that IPv4 addressing is based on needs. Needs based thinking is scarcity based thinking, and while it is very appropriate for IPv4, it is not at all appropriate for IPv6. If providers were constantly allocating and reallocating variable sized blocks then it would be a planning and tracking nightmare. In a world where all customer allocations are /48, it becomes much easier to plan and track. A certain address block can be used by a shipping container today, an airplane tomorrow, and the mayor's election campaign office, the day after that. One size fits all. This is related to the thinking behind flat-rate Internet pricing versus usage-based schemes like 1980's long distance phone calls. The flat-rate schemes seem to be unfair in economic terms at first glance. But when you factor in the overall reduced rates caused by greatly reduced accounting overhead, along with the ease of planning outgoing bills from the customer side, flat-rate turns out to be economically beneficial all-round. We cannot afford to force the IPv6 networking world into the mental strait-jackets of the IPv4 Internet any more than we could afford to force the IPv4 Internet into the mental strait-jackets of the telephony world. IPv6 really is different and it is not just that which we currently know as "the Internet". --Michael Dillon From Michael.Dillon at btradianz.com Sun Mar 19 18:27:04 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Sun, 19 Mar 2006 23:27:04 +0000 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4018CAB48@CL-S-EX-1.stanleyassociates.com> Message-ID: > I'm not disagreeing, but what is the definition of "end site" here? > The aircraft has a single /48? Yes, the aircraft is the subscriber. Of course many aircraft will be owned and operated by a single company, but not all of them. > Are you also saying that each /48 be provider independent? No. The design of IPv6 says that the end-site uses /64 subnets within it's own network topology. Those /64 subnets allow each subnet to use provider independent addressing for the host-portion of the address, for instance they could use Ethernet MAC addresses as the stable portion of the address. For this to work, they need a fixed and predictable number of bits for working space, first for the host addressing and then for the subnetting in their own topology design. This subnetting is also intended to have space to evolve so that most organizations only need one allocation from either and RIR or a provider, during their lifetime. > Buses, trains or train cars, ships, tandem bicycles. Be > specific. I think that being specific is contrary to the goal of coming up with a general policy that is not unnecessarily restrictive. It doesn't matter how the networks move around and what physical objects they are attached to. If the discussion gets to specific it always leads to corner cases which don't work. I don't believe it is possible to have a policy without corner cases where the policy doesn't work. In the past our policies have had issues, and over time, people either live with these issues or they come up with workable new policy proposals that improve the policy. This is a good thing. --Michael Dillon From louie at equinix.com Mon Mar 20 17:40:24 2006 From: louie at equinix.com (Louis Lee) Date: Mon, 20 Mar 2006 14:40:24 -0800 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure In-Reply-To: <43F6247A.8040406@arin.net> References: <43F6247A.8040406@arin.net> Message-ID: <20060320224024.GD19592@nemo.corp.equinix.com> Comments inline. I support this policy proposal with the following modifications.... By the way, I withdraw my comments about allocations vs. assignments. In my experience of requesting micro-allocations, whether a small block is allocated or assigned (in the strict sense) was based more on whether my organization is an end-site or an ISP. On Fri, Feb 17, 2006 at 02:31:06PM -0500, Member Services wrote: > > Policy Proposal 2006-2: Micro-allocations for Internal > Infrastructure > > Author: Jason Schiller, Chris Morrow, Heather Skanks, Greg > Stilwell, Beth Vu > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > To replace section 6.10 > > 6.10 Micro-allocation > > ARIN will make micro-allocations for critical infrastructure, > and the RIRs and IANA as defined in the sub-sections > below. There is no reference to RIRs & IANA in the sub-sections. Since the idea for this policy proposal seems to be to add internal infrastructure for justification without removing the current justification guidelines, perhaps another sub-section should added to the 3 that are proposed. Might I suggest 6.10.4? Jason, I know when we last spoke, I was going to add RIRs & IANA to the 6.10.2 sub-section. I now think that the justification is sufficiently different enough that it should be a separate sub-section. However, I am still offering alternate wording for the second paragraph of 6.10.2 for consistency. (See below.) So if we one of Randy's two wishes come true about setting aside specific blocks for DNS, a whole sub-section can be removed without modifying text. :) > These allocations will be no longer (more specific) than a > IPv6 /48. Multiple allocations may be granted in certain > situations. Micro-allocations MUST be provided from a specific > range of addresses. ARIN will make a list of these blocks > publicly available. ISPs and other organizations receiving > these micro-allocations will be charged under the ISP fee > schedule, while end-users will be charged under the fee > schedule for end-users. This policy does not preclude > organizations from requesting address space under other > policies. > > 6.10.1 Micro-allocation for public exchange points > > Public Internet exchange point operators must provide > justification for the micro-allocation, including: connection > policy, location, other participants (minimum of two total), > ASN, and contact information. > > Exchange point allocations MUST be allocated from specific > blocks reserved only for this purpose. > > 6.10.2 Micro-allocation for core DNS service providers > > Core DNS service providers (e.g. ICANN-sanctioned root, gTLD, > and ccTLD operators) must provide justification for the > micro-allocation, including: name of core DNS server, location, > ASN, and contact information. > > Core DNS server allocations MUST be allocated from the > micro-allocation block. This block must be separate from > the exchange point micro-allocation block and the internal > infrastructure micro-allocation block. I suggest this text for the second paragraph of 6.10.2: Core DNS server allocations MUST be allocated from specific blocks reserved only for this purpose. The originally proposed text is unnecessarily cumbersome to read through and implement. It was already stated earlier that "Micro-allocations MUST be provided from a specific range of addresses". Since the subsections within 6.10 are meant to cover all cases for v6 micro-allocation, there would not be a case where an assignment for something else is made out of the DNS IP allocation block. Now, I'm curious if there are actually any network operators who have configured route filters or IP filters based specifically on DNS server IP blocks. It is understood that learning an IX micro-allocation prefix from your eBGP peer will usually cause routing problems. The same issue doesn't exist for the DNS IP blocks. But since I didn't participant in the discussion for the same justification for IPv4, I can't say that there weren't any non-technical (e.g. political) reasons for root servers to be in PI space. > 6.10.3 Micro-allocation for internal infrastructure > > Organizations that currently hold IPv6 allocations may > apply for a micro-allocation for internal infrastructure. > Applicant must provide justification indicating why a separate > non-routed block is required. Justification must include why a > sub-allocation of currently held IP space cannot be utilized. > > Internal infrastructure allocations MUST NOT be routed on > global Internet. For now, this sentence saying that "Internal infrastructure allocations MUST NOT be routed on global Internet" should be removed. I fully understand the reason for it to be there. But for its inclusion, we should change the stance that ARIN would not address routability. (Policy text that mention NAT and RFC1918 space is on the edge of that stance.) > Internal infrastructure allocations MUST be allocated from > specific blocks reserved only for this purpose. How about the following text for 6.10.4? I don't know that we have to provide any strict guidelines. There is no indication or evidence of abuse, so I'm refraining from imposing restrictions. (Is there a compelling reason to document the reason for the new micro-allocation.) 6.10.4 Micro-allocation for RIRs and IANA RIRs and IANA may be allocated a micro-allocation upon request. Allocations to RIRs and IANA MUST be allocated from specific blocks reserved only for this purpose. Just some additional thoughts.... ARIN already documents the micro-allocations as lists: http://www.arin.net/reference/micro_allocations.html That being the case, is it really necessary to have specific blocks reserved for each of the 3 (or 4) categories (times 2: one set for v4 and another set for v6)? I'd imagine that operators may find it convenient to configure route filters and IP filters so they can treat each block differently. But is that happening today? And would someone with a crystal ball tell me if these filters will be built based on these blocks in the future? ;) Best regards, Louie -- Louis Lee Sr. Network Architect New Service Development Equinix, Inc. louie at equinix.com desk: 408/360-5253 main: 650/513-7000 From Lee.Howard at stanleyassociates.com Mon Mar 20 17:40:54 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 20 Mar 2006 17:40:54 -0500 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40198881C@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Michael.Dillon at btradianz.com > Sent: Sunday, March 19, 2006 6:27 PM > To: ppml at arin.net > Subject: Re: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) > > > Are you also saying that each /48 be provider independent? > > No. The design of IPv6 says that the end-site uses /64 subnets > within it's own network topology. Those /64 subnets allow each > subnet to use provider independent addressing for the host-portion > of the address, for instance they could use Ethernet MAC addresses > as the stable portion of the address. For this to work, they need > a fixed and predictable number of bits for working space, first > for the host addressing and then for the subnetting in their > own topology design. This subnetting is also intended to have > space to evolve so that most organizations only need one allocation > from either and RIR or a provider, during their lifetime. I appreciate your patience with me on this. Flight 1234 gets a /48. Out of that /48, the air traffic control network has one /64, the air carrier network has another /64, and the entertainment network has a third? So each of those networks has a /64 in its table, in addition to the aggregate /32? Still assuming that the network carrier is the same as the service provider, but I haven't heard anyone object to that assumption. > > Buses, trains or train cars, ships, tandem bicycles. Be > > specific. > > I think that being specific is contrary to the goal of > coming up with a general policy that is not unnecessarily > restrictive. It doesn't matter how the networks move around > and what physical objects they are attached to. If the discussion > gets to specific it always leads to corner cases which don't > work. I don't believe it is possible to have a policy without > corner cases where the policy doesn't work. In the past our > policies have had issues, and over time, people either live > with these issues or they come up with workable new policy > proposals that improve the policy. This is a good thing. Well said. > --Michael Dillon Lee From sleibrand at internap.com Mon Mar 20 23:30:29 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 20 Mar 2006 23:30:29 -0500 (EST) Subject: [ppml] Oxymorons (was: Geo PI) In-Reply-To: <20060216230431.GB17258@vaf-lnx1.cisco.com> References: <20060216230431.GB17258@vaf-lnx1.cisco.com> Message-ID: Vince, I enjoyed your talk at GROW (IETF's Global Routing Operations WG) today. I was going back through my many as-yet-unread mailing list messages, and thought I'd respond to some of your points here. Further comments inline... On 02/16/06 at 3:04pm -0800, Vince Fuller wrote: > These messages attempt to explain why "geo-topo addresses" and "provider- > independent addresses" make no sense if the goal is a scalable Internet > routing system built on the (flawed) ipv6 routing architecture (fatally > flawed in the sense that it confuses the concept of transport identifier > and routing locator into a single "address"). First off, I'm not opposed to ID/locator splits, either full (requiring some degree of IPv6 redesign) or partial (aka shim6). However, I'm from an operational background, and my first instinct is to see if we can make something work from the tools we have... > Those who propose "geo-topological" addressing, an oxymoron if ever there > were one, are effectively dictating how the network topology is to be > organized, with rather profound implications for provider business models. > If addresses are assigned in this manner, then service providers whose > networks span multiple address assignment domains (connect to more than > one city or however the geographic areas are split up) must: > > a) connect to all designated interconnection facilities associated with > the address assignment authorities in the geographic areas they wish > to serve IMO "designated interconnection facilities" are unnecessary. RIRs have managed to stay out of the routability game thus far, and I think they should and can continue to do so. > and > > 1) carry all more-specific routes for all providers in all of the cities > that they serve (which eliminates aggregation) It only eliminates aggregation *for that city*. For the rest of the Internet, the providers routers will see only aggregated routes. There is still a much higher degree of aggregation compared to the current IPv4 PI swamp. > or > > 2) provide free transit service for any customer of a competitor in a > geographic area whose addresses are aggregated IMO generally undesirable, but it is indeed one option... > or > > 3) enter into a settlement agreement (which implies a regulatory regime > unprecedented in the Internet business) with all other providers in > geographic areas which they serve And IMO this would only happen if we completely fail to solve the problem ourselves and "let" Congress "solve" it for us. > > Forcing people to join an unnecessary IX is not the way > > to solve the problem of regional aggregation of routes. > > This is a purely technical problem which can be solved > > by the RIR practices in allocating IPv6 addresses. If they > > would allocate addresses in a geo-topological manner then > > end users and ISPs would be free to aggregate routes > > outside of their region without any involvement of governments > > or any requirement to join consortia or IXes. It does > > require the users of such geo-topological addresses to > > ensure that in THEIR region, there is sufficient > > interconnectivity (physical and policy) between ISPs for > > the addressing to work. But that does not need to be determined > > or managed centrally. I agree wholeheartedly with Michael here... > In the interests of demonstrating why "geo-topo" addressing can't possibly > work without radical changes to the business and regulatory models of the > Internet, consider the simple example of a provider who has connections > to two popular "geo-topo" addressing domains, say the Bay Area and the > DC area. Let's say that 10.0.0.0/8 is the "geo-topo" address block in the > Bay Area and 172.16.0.0/12 is the "geo-topo" block in the DC area. This > provider has four customers in the Bay Area: > > 10.1.1.0/24 > 10.10.4.0/22 > 10.100.8.0/21 > 10.200.0.0/16 > > How is the provider supposed to make use of the 10.0.0.0/8 aggregate? Does > he advertise it to other providers in the DC area or anywhere else where > he offers service (Asia, Europe, etc.)? By doing so, he is stating that he > can provide connectivity to all hosts which are numbered in that address > range. But he only provides transit service to the address ranges associated > with his customers. IMO the provider should not advertise the 10.0.0.0/8 aggregate to anyone but his own transit customers. The obvious next question is, how does the provider deal with peers? IMO, there are a few different options: 1) Only provide local routes to peers. This means telling peers who don't have a global presence of their own that they must also buy transit connectivity to someone who can carry their traffic to the Bay Area. Obviously, they could have both local peering and non-local transit to the same peer/provider. 2) For peers where only providing local routes is not an option, set up a multihop or tunneled BGP session from a Bay Area router to the peer's nearest routers. > For him to provide connectivity to all the address range, he must > > a) have full routing connectivity to all other providers that have > addresses in the same range; this implies that he connects to all IXs > within the region and maintains a full-mesh of routing information > (today, BGP sessions) to all of these providers This is already the case for all transit-free networks (on a global basis, not necessarily regionally). Every transit-free network peers (somehow, either at IXs or privately) with every other transit-free network. So I would restate your requirement as: a) have full routing connectivity to all other transit-free providers that have addresses in the same range; this implies sufficient peering density to provide at least one (and probably two) IX or private peering sessions in each aggregated region. It *does not* require connectivity to all IXs: private peering is still sufficient, and peering with a transit-buying network's transit provider is just as good (for reachability) as peering with that network at an IX. > and > > b) must be willing to provide connectivity to all sites within the region > to any place that he advertises the prefix 10.0.0.0/8 through routing > exchanges; if he advertises this prefix to non-customers, it implies > that he is will provide free transit to his competitors' customers > which are numbered out of this block True. As stated above, I suspect providers will only advertise aggregated routes to their transit customers in most cases. > Both of these requirements defy business sense, After my modifications above, I don't believe either requirement is unreasonable. One central theme that I think people miss is that not everyone has to aggregate at the same level to ensure reachability. If a provider has insufficient peering density to aggregate at a metro level, they should be able to aggregate at a regional or continental level. As long as we assign the PI blocks sensibly, this should be perfectly feasible. (Now I recognize that different levels of aggregation will have TE implications, but I believe those implications are manageable within the existing TE toolkit, and much more manageable than attempting to reproduce your TE with something like shim6.) > I'm not sure how I can make this much more clear. It seems appropriate to > re-state Dave's quote Yakov: > > "Addressing can follow topology or topology can follow addressing. > Choose one." > > and I'd offer a corollary: > > Transit relationships (i.e money) must follow topological relationships > (and thus addressing); the alternative is some combination of inefficient > or non-scalable routing, black holes, settlements, regulation, or other > undesirable things. So I guess in my case my alternative is "other undesirable things", which I maintain are more desirable than non-scalable routing (allowing an IPv6 PI swamp) and significantly easier to implement than yet another IP re-design (though if we can achieve some degree of ID/locator split incrementally, great). The "undesirable things" I see in geographically based PI aggregation are (to summarize): - In order to reach networks that have been geographically aggregated, the remote network must either peer within the aggregated region, buy transit from someone who does, or set up multihop or tunneled eBGP peers with a router in the aggregated region. - Networks wishing to begin aggregating a region's routes must ensure that they have sufficient peering density within that region (or must make alternate arrangements) to ensure their peers meet the above requirement, or must decide on a case-by-case basis if providing free transit is a superior alternative. They must ensure that the benefits of aggregation outweigh the costs of the peering changes required to maintain full reachability. - Networks whose peers begin aggregating must consider the implications of a possible switch from hot-potato to cold-potato routing, whereby they carry the traffic to the destination region before handing it off to the destination network. This may actually drive networks to aggregate in order to keep up with or get ahead of their peers and minimize the fraction of traffic they must carry to/from the region. - Multihomed transit customers whose transit providers have different aggregation policies will need to consider those policies when setting up TE policies. However, the benefits of this approach are considerable: - Not much must change in the near term. The only requirement up front is that RIRs who decide to allocate PI space do so in a manner amenable to later aggregation. - Network operators can make their own decision whether to aggregate. If, to take Jason's example, an NSP with 150k internal prefixes decides they want to aggregate sooner, another NSP with 50k internal prefixes and a more aggressive hardware refresh cycle might decide not to aggregate at all, or to do so later on. - Operators need only aggregate when the scaling issues of carrying PI space start to manifest themselves. When they do, it becomes a business decision for each operator how to deal with the scaling issues, either by upgrading hardware or aggregating or both. This ensures that operators will make the decision based on the economics in place at the time, which may be *much* different than they are now. - End-user networks can maintain provider independence and use traditional TE tools to influence inbound traffic, even after their providers start aggregating. (The precise metrics may need to change, but the overall methods needn't.) If an end-user network needs/wants to use their PI space somewhere far from the location it was mapped to on assignment, they can still do so, it just won't get aggregated. So in conclusion, I would say that we (particularly the RIR community) should seriously consider in the near future whether to tweak our IPv6 PI assignment policy to choose the specific prefix to allocate based on the geographic location of the applicant. Making such a simple change will have absolutely no negative impact on the recipients of the PI netblocks, and will set us up with the ability to aggregate as needed in the future to deal with the scalability issues that will inevitably arise in any system based on the current routing paradigm. -Scott From jdhoule at att.com Wed Mar 22 12:56:48 2006 From: jdhoule at att.com (Houle, Joseph D (Joe), CMO) Date: Wed, 22 Mar 2006 11:56:48 -0600 Subject: [ppml] What's in a name? An address allocation would smell as sweet In-Reply-To: Message-ID: Folks: To Paraphrase a classic: What's in a name? That which we call PI allocation By any other name (LIR allocation) would smell as sweet; What is the operational difference between? 1) Introducing the concept of Provider Independent addresses with strict criteria to qualify. 2) Redefining/relaxing the definition of what an LIR is? Joe Houle From owen at delong.com Wed Mar 22 15:48:41 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 22 Mar 2006 12:48:41 -0800 Subject: [ppml] What's in a name? An address allocation would smell as sweet In-Reply-To: References: Message-ID: --On March 22, 2006 11:56:48 AM -0600 "Houle, Joseph D (Joe), CMO" wrote: > Folks: > > What is the operational difference between? > 1) Introducing the concept of Provider Independent addresses with > strict criteria to qualify. > 2) Redefining/relaxing the definition of what an LIR is? > The difference would depend almost entirely on what criteria were used to relax/redefine the LIR and which version of which PI proposal you were comparing it to. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at btradianz.com Thu Mar 23 04:57:37 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 23 Mar 2006 09:57:37 +0000 Subject: [ppml] What's in a name? An address allocation would smell as sweet In-Reply-To: Message-ID: > What's in a name? That which we call PI allocation > By any other name (LIR allocation) would smell as sweet; > 2) Redefining/relaxing the definition of what an LIR is? An LIR is essentially the same as an ISP. Some people in Europe invented the term LIR because they thought that ISP was too commercial at a time when the majority of the Internet was composed of academic or research networks. The essential characteristic of an LIR or an ISP is that they are charged with operating a network. That is job number one for their organization. The PI allocation policy is targetted at organizations for whom some other activity is job one, such as car manufacturing, airplane operation, food distribution, etc. These organizations all operate networks as a support activity, not a primary activity. Now, if they spin off the network operations into a separate entity, that entity is an LIR and can qualify for its own /32. For an example of this in Europe, go to http://www.mgi.de and click on "English" on the grey bar along the top, 3rd from the left. If you go to http://www.ripe.net and do a whois search for 2001:4d20::/32 you will see their IPv6 PA allocation. Playing with the definition of an LIR can only make it easier for other companies to do what MGI has done. I think the intent of the PI proposal before us is to tailor a policy to the needs of companies for whom networking is a secondary support activity. This type of company could go to an ISP and get a /48 for each of their locations. But if they change ISPs then they must renumber each site. And they cannot effectively multihome any of their sites between two ISPs. A good PI policy will give them a /48 for each location directly from the RIR, and will ENABLE multihoming with two ISPs. --Michael Dillon --Michael Dillon From narten at us.ibm.com Thu Mar 23 12:18:32 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 23 Mar 2006 11:18:32 -0600 Subject: [ppml] real data on PI assignments to end sites? Message-ID: <200603231718.k2NHIWZ8016144@cichlid.raleigh.ibm.com> Geoff (or anyone else who can help), In trying to better understand the impacts of various PI-for-end-sites proposals, it would be helpful to me to understand how many PI assignments have been made to end sites in IPv4 today. That is, using IPv4 as a guide, is there data to help us understand the implications of setting the bar for how "large" an end site should be in order to be eligible for a PI assignment? Is it only in the thousands? Tens of thousands? Also, are there any trend lines that can help us understand where things are heading today? Is such data available, or are there ways to estimate this? Thomas From jeroen at unfix.org Thu Mar 23 12:42:27 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 23 Mar 2006 18:42:27 +0100 Subject: [ppml] real data on PI assignments to end sites? In-Reply-To: <200603231718.k2NHIWZ8016144@cichlid.raleigh.ibm.com> References: <200603231718.k2NHIWZ8016144@cichlid.raleigh.ibm.com> Message-ID: <1143135747.21685.6.camel@firenze.zurich.ibm.com> On Thu, 2006-03-23 at 11:18 -0600, Thomas Narten wrote: > Geoff (or anyone else who can help), > > In trying to better understand the impacts of various PI-for-end-sites > proposals, it would be helpful to me to understand how many PI > assignments have been made to end sites in IPv4 today. That is, using > IPv4 as a guide, is there data to help us understand the implications > of setting the bar for how "large" an end site should be in order to > be eligible for a PI assignment? Is it only in the thousands? Tens of > thousands? Taking that every business would want to not have the burden of renumbering, every business would in effect want to have PI in the long run. With IPv4 they can resort to NAT to avoid renumbering in some cases where there is no inbound traffic, or simply do 1:1 NAT so that even servers can be in the old address space (ignoring updating firewalls/dns/etc at remote places and a lot of other issues). These sites will thus not be really visible as having "PI" but they do have a form of it and actually would really love to have it. Counting them thus becomes quite impossible, but one could estimate that a large portion of the global businesses would want to have it. > Also, are there any trend lines that can help us understand where > things are heading today? > > Is such data available, or are there ways to estimate this? The big trouble is, as you most likely know, that many sites are behind NAT's, which would actually very much like to have a globally unique PI address space but could not get it for various reasons. Thus even if one would take RIR data, there is most likely a large number of sites that is not registered at all in the various RIR registries because they are hiding behind a NAT. Next to that various places don't want to be registered in a RIR database to avoid competition being able to estimate their address space size and thus being able to guess how much they have connected and other privacy and obscurity reasons. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 315 bytes Desc: This is a digitally signed message part URL: From terry.l.davis at boeing.com Thu Mar 23 14:52:43 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Thu, 23 Mar 2006 11:52:43 -0800 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) In-Reply-To: <002a01c649e8$afb67b10$9901a8c0@tropos.com> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BD8A@XCH-NW-8V1.nw.nos.boeing.com> Tony This isn't solely an IP address problem and I certainly was not proposing a /128 for everything at all. As I said when I responded last week: "Not at all! I do think that we have to offer reasonable IP address stability (i.e. I don't think that services like local government, EMS, power, etc should ever change IP addresses for a physical location.) We need to come up with some stable personal and residential DNS and email schemes as we develop v6. USPS, UPS, FEDEX, etc all deliver to my home address so why can't my current ISP deliver to a stable email/DNS name that is either personal or residential based?" And as I said also in some of the previous posts, a large corporation will simply not accept "provider furnished addressing" for business reasons (and possibly legal reasons). Likewise I do not see government being able to sign "perpetual contracts" with any vendor in order maintain their IP addressing. Take care Terry PS: Nor I do ever want to consider the risks that would be inherent in re-addressing aircraft because the manufacturer, government air traffic control service, or airline changed ISP's. > -----Original Message----- > From: Tony Li [mailto:tli at tropos.com] > Sent: Friday, March 17, 2006 9:32 AM > To: Davis, Terry L; 'Howard, W. Lee'; ppml at arin.net > Subject: RE: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) > > > > > 1) We MUST provider users (individuals/government/business) > > with logical > > stability. Getting new IP addresses, DNS names, and email addresses > > every time we either change providers or move will simply be > > unacceptable. Without this logical stability, every communication > > service (voice/email/etc) is unstable, industry-wide initiatives (i.e. > > like power control) are not possible, and even gains the financial > > institutions hope to make with EFT systems become limited > > (i.e. remember > > the fun of resetting all your automatic billings/payments email > > addresses last time you changed service providers?). I know > > this may be > > more an IETF issue but I'm there next week. > > > Any ideas on how to do this in a scalable fashion? If I interpret you > literally, you seem to be advocating putting a /128 on each and every > laptop, cell phone, and IP-capable toaster and then carrying all > prefixes. > > Regards, > Tony > From tli at tropos.com Thu Mar 23 15:22:21 2006 From: tli at tropos.com (Tony Li) Date: Thu, 23 Mar 2006 12:22:21 -0800 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BD8A@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: <004701c64eb7$86566b30$b301a8c0@tropos.com> Terry, > And as I said also in some of the previous posts, a large corporation > will simply not accept "provider furnished addressing" for business > reasons (and possibly legal reasons). Likewise I do not see > government > being able to sign "perpetual contracts" with any vendor in order > maintain their IP addressing. > > PS: Nor I do ever want to consider the risks that would be inherent in > re-addressing aircraft because the manufacturer, government > air traffic > control service, or airline changed ISP's. This is a fine perspective if you accept the original CIDR address allocation scheme as gospel. However, I submit that it's nothing more than a sacred cow. With a new architecture that provides true identifier/locator separation and includes an architecturally (and practically) efficient and smooth mechanism for locator change, there is no difficulty in being multi-homed or mobile. The fact of the matter is that this is not possible in the IPv6 architecture today, and unless we make some very drastic changes in an awful hurry, it never will be. At the same time, we know that long term widespread use of PI addressing will lead to the eventual overload of the routing subsystem and the ensuing operational insanity. We can pay now, or we can pay more later. You seem to be voting 'more later'. Regards, Tony From memsvcs at arin.net Thu Mar 23 16:00:27 2006 From: memsvcs at arin.net (Member Services) Date: Thu, 23 Mar 2006 16:00:27 -0500 Subject: [ppml] real data on PI assignments to end sites? Message-ID: <44230C6B.3010403@arin.net> Hello Thomas, You can use the ftp stats at: ftp://ftp.arin.net/pub/stats/arin/delegated-arin-latest to see how many end user assignments there are. They are the ones that are designated as "assigned" vice those designated as "allocated". Of course, there are caveats about the ftp stats: it is a snapshot, not a time series so does not represent any trends or rates. Also, as you may deduce, this does not take into account persons who use RFC 1918 space in lieu of using unique address space obtained from ARIN. Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN) From owen at delong.com Thu Mar 23 16:14:40 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 23 Mar 2006 13:14:40 -0800 Subject: [ppml] real data on PI assignments to end sites? In-Reply-To: <200603231718.k2NHIWZ8016144@cichlid.raleigh.ibm.com> References: <200603231718.k2NHIWZ8016144@cichlid.raleigh.ibm.com> Message-ID: <24859905D184FF7F657488E8@imac-en0.delong.sj.ca.us> If you look at the ARIN IP allocation stats pages you can see that there was not a significant increase in IPv4 issuances after the adoption of 2002-3 which brought the bar from /20 to /22. Similarly, there was not an appreciable change from /19 to /20. These graphs are on the ARIN web site. Owen --On March 23, 2006 11:18:32 AM -0600 Thomas Narten wrote: > Geoff (or anyone else who can help), > > In trying to better understand the impacts of various PI-for-end-sites > proposals, it would be helpful to me to understand how many PI > assignments have been made to end sites in IPv4 today. That is, using > IPv4 as a guide, is there data to help us understand the implications > of setting the bar for how "large" an end site should be in order to > be eligible for a PI assignment? Is it only in the thousands? Tens of > thousands? > > Also, are there any trend lines that can help us understand where > things are heading today? > > Is such data available, or are there ways to estimate this? > > Thomas > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Thu Mar 23 17:02:59 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 23 Mar 2006 14:02:59 -0800 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BD8A@XCH-NW-8V1.nw.nos.boeing.com> References: <0D090F1E0F5536449C7E6527AFFA280A21BD8A@XCH-NW-8V1.nw.nos.boeing .com> Message-ID: Not to delve too far into this, but, there are significant differences in the addressing you refer to... UPS/USPS/FedEX do not deliver to you. They deliver to your household. They deliver to a physical location, regardless of who is present at said physical location. That's what your home address represents. IP delivers to a specific host address, regardless of the system which posesses that address at the moment or who is currently using that system. EMAIL delivers to a specific mailbox, which, usually represents a specific user, regardless of which system(s) the mailbox is hosted or read on. Trying to make one of these addresses stable in terms of the others is, in many cases counter-productive. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Thu Mar 23 17:06:06 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 23 Mar 2006 14:06:06 -0800 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) In-Reply-To: <004701c64eb7$86566b30$b301a8c0@tropos.com> References: <004701c64eb7$86566b30$b301a8c0@tropos.com> Message-ID: > This is a fine perspective if you accept the original CIDR address > allocation scheme as gospel. > > However, I submit that it's nothing more than a sacred cow. With a new > architecture that provides true identifier/locator separation and > includes an architecturally (and practically) efficient and smooth > mechanism for locator change, there is no difficulty in being > multi-homed or mobile. > On this, we completely agree. > The fact of the matter is that this is not possible in the IPv6 > architecture today, and unless we make some very drastic changes in an > awful hurry, it never will be. At the same time, we know that long term > widespread use of PI addressing will lead to the eventual overload of > the routing subsystem and the ensuing operational insanity. > On this, I'm not so sure. I think the changes don't need to be all that radical, and, I don't think we need to split LOC/ID except in the interdomain context. I don't think prefix-based routing within an autonomous system is all that unwieldy. > We can pay now, or we can pay more later. You seem to be voting 'more > later'. > On that, we agree. Personally, I vote now. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jdhoule at att.com Thu Mar 23 17:30:20 2006 From: jdhoule at att.com (Houle, Joseph D (Joe), CMO) Date: Thu, 23 Mar 2006 16:30:20 -0600 Subject: [ppml] What's in a name? An address allocation would smell as sweet In-Reply-To: Message-ID: Mike et al: Thanks for the clarification. So I guess the counter-proposal to PI addresses, is to consider organizations inside larger organizations that, if separate, would qualify as an LIR. These folks maybe should be considered LIRs from ARIN. Two other points you bring up. With IPv6 still not quite ready-for-primetime it may be difficult for us to see this but... The IPv6 vision is to turn concerns like: "But if they change ISPs then they must renumber each site", Into benefits like: "If they connect to multiple ISPs they have additional address allocations to use". One last thought... These PI proposals (one more than the other) are not only proposals for PI addresses, but also proposals to perpetuate the fragmented address space, as suffered today by IPv4, where each "site" shows up as an entry in the global routing table. Are we in North America that ready to abandon the IPv6 visions of aggregated routing tables and multi-addressing as a multi-homing mechanism? Joe Houle -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Michael.Dillon at btradianz.com Sent: Thursday, March 23, 2006 4:58 AM To: ppml at arin.net Subject: Re: [ppml] What's in a name? An address allocation would smell assweet > What's in a name? That which we call PI allocation > By any other name (LIR allocation) would smell as sweet; > 2) Redefining/relaxing the definition of what an LIR is? An LIR is essentially the same as an ISP. Some people in Europe invented the term LIR because they thought that ISP was too commercial at a time when the majority of the Internet was composed of academic or research networks. The essential characteristic of an LIR or an ISP is that they are charged with operating a network. That is job number one for their organization. The PI allocation policy is targetted at organizations for whom some other activity is job one, such as car manufacturing, airplane operation, food distribution, etc. These organizations all operate networks as a support activity, not a primary activity. Now, if they spin off the network operations into a separate entity, that entity is an LIR and can qualify for its own /32. For an example of this in Europe, go to http://www.mgi.de and click on "English" on the grey bar along the top, 3rd from the left. If you go to http://www.ripe.net and do a whois search for 2001:4d20::/32 you will see their IPv6 PA allocation. Playing with the definition of an LIR can only make it easier for other companies to do what MGI has done. I think the intent of the PI proposal before us is to tailor a policy to the needs of companies for whom networking is a secondary support activity. This type of company could go to an ISP and get a /48 for each of their locations. But if they change ISPs then they must renumber each site. And they cannot effectively multihome any of their sites between two ISPs. A good PI policy will give them a /48 for each location directly from the RIR, and will ENABLE multihoming with two ISPs. --Michael Dillon --Michael Dillon _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From bmalm at idngh.com Fri Mar 24 04:16:04 2006 From: bmalm at idngh.com (bmalm at idngh.com) Date: Fri, 24 Mar 2006 09:16:04 +0000 Subject: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) Message-ID: <20060324091604.ilp69r5aw4c0cckw@mail.idngh.com> Good point there, Owen. We need to appreciate the fact that the world is moving from the physical to the virtual and logical, which aids mobility and ubiquity without necessarily sacrificing flexibility. This aids the global village concept and any attempt to tie what is virtual to anything physical defeats the very purpose of the internet, and makes its administration unnecessarily difficult. Bernard Malm IDN, Ghana ----- Message from owen at delong.com --------- Date: Thu, 23 Mar 2006 14:02:59 -0800 From: Owen DeLong Reply-To: Owen DeLong Subject: Re: [ppml] IP-v6 Needs (RE: a modified proposal 2005-8) To: "Davis, Terry L" , tony.li at tony.li, "Howard, W. Lee" , ppml at arin.net > Not to delve too far into this, but, there are significant differences > in the addressing you refer to... > > UPS/USPS/FedEX do not deliver to you. They deliver to your household. > They deliver to a physical location, regardless of who is present at > said physical location. That's what your home address represents. > > IP delivers to a specific host address, regardless of the system which > posesses that address at the moment or who is currently using that system. > > EMAIL delivers to a specific mailbox, which, usually represents a specific > user, regardless of which system(s) the mailbox is hosted or read on. > > Trying to make one of these addresses stable in terms of the others is, > in many cases counter-productive. > > Owen > ----- End message from owen at delong.com ----- Bernard Malm IDN ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owen at delong.com Fri Mar 24 04:22:47 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 24 Mar 2006 01:22:47 -0800 Subject: [ppml] What's in a name? An address allocation would smell as sweet In-Reply-To: References: Message-ID: --On March 23, 2006 4:30:20 PM -0600 "Houle, Joseph D (Joe), CMO" wrote: > Mike et al: > Thanks for the clarification. > So I guess the counter-proposal to PI addresses, is to consider > organizations inside larger organizations that, if separate, would > qualify as an LIR. These folks maybe should be considered LIRs from > ARIN. > > Two other points you bring up. > With IPv6 still not quite ready-for-primetime it may be difficult for > us to see this but... The IPv6 vision is to turn concerns like: > "But if they change ISPs then they must renumber each site", > Into benefits like: > "If they connect to multiple ISPs they have additional address > allocations to use". > Having to use multiple addresses on a machine to source connections through a variety of ISPs is _NOT_ a good thing. It might be what we have to do if we follow some of the current proposals, but, that doesn't make it the best thing from a user or site administrator perspective. There are serious limitations and complications involved in such an implementation, and, the proposals to make them workable are still vaporware. Saying it has a strong aroma does not mean it doesn't stink, no matter how much the fertilizer salesman would like to convnice us that is the case. > One last thought... These PI proposals (one more than the other) are > not only proposals for PI addresses, but also proposals to perpetuate > the fragmented address space, as suffered today by IPv4, where each > "site" shows up as an entry in the global routing table. > Yes. To some extent that's true. However, the alternative of saying "We didn't fix the major problems with V4 in V6, so, we want to treat a larger subset of the population as second class users in order to accommodate this issue" doesn't fly either. > Are we in North America that ready to abandon the IPv6 visions of > aggregated routing tables and multi-addressing as a multi-homing > mechanism? > Since that vision is still nothing but vaporware, and, people are trying to get us to deploy v6, yes. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From mpetach at netflight.com Sat Mar 25 17:11:24 2006 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 25 Mar 2006 14:11:24 -0800 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure In-Reply-To: <20060320224024.GD19592@nemo.corp.equinix.com> References: <43F6247A.8040406@arin.net> <20060320224024.GD19592@nemo.corp.equinix.com> Message-ID: <63ac96a50603251411j5a992800t259aed5cbe259b68@mail.gmail.com> First off, I'd like to also add my voice in support of this proposal for the record. On 3/20/06, Louis Lee wrote: > > [...] > Just some additional thoughts.... > > ARIN already documents the micro-allocations as lists: > http://www.arin.net/reference/micro_allocations.html > > That being the case, is it really necessary to have specific > blocks reserved for each of the 3 (or 4) categories (times 2: one > set for v4 and another set for v6)? I'd imagine that operators > may find it convenient to configure route filters and IP filters > so they can treat each block differently. But is that happening > today? And would someone with a crystal ball tell me if these > filters will be built based on these blocks in the future? ;) The filters do exist today, but they're painful to keep updated because in v4 space the allocations are done as individual /24s, so each time a new IX comes online, it means adding yet another line to the filter. 206.223 seemed like a step in the right direction, I was hoping that we'd get to the point of just being able to filter 206.223/16 and not have to keep updating filters--but existing exchange points never went back and re-numbered off their old 198.32 space, and now there's new IXs being numbered out of 206.197 (personally, my favorite from the ARIN list at the link above is 206.197.310.0/24 -- I still haven't managed to get my router to accept that in the filter. Good thing I'm not planning to connect to that IX any time soon!). Yes, I know that's a typo--but that's one consequence of assigning the microallocations in the current fashion. Let's not use 'this is how we do it today' be a reason for not doing it better in the future. So--yes, let's set aside 4 microallocation blocks in v6 for the categories listed; all such allocations will come from the associated microallocation block, and those of us operating large networks will then be able to use our filters without the current headache of updating them on such a regular basis. Thanks! Matt (putting his crystal ball away until next time) Best regards, > Louie > -- > Louis Lee > Sr. Network Architect > New Service Development > Equinix, Inc. > louie at equinix.com > desk: 408/360-5253 > main: 650/513-7000 > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From memsvcs at arin.net Mon Mar 27 10:56:09 2006 From: memsvcs at arin.net (Member Services) Date: Mon, 27 Mar 2006 10:56:09 -0500 Subject: [ppml] ARIN XVII - Open Policy Hour Message-ID: <44280B19.6070405@arin.net> SOME QUESTIONS ABOUT THE POLICY PROCESS 1. Do you want to know what policy proposals will be discussed at the upcoming ARIN Public Policy Meeting? 2. Do you want a better understanding about what they are about? 3. Do you want to know what has been said about them so far? 4. Do you have an idea about how ARIN should manage Internet Number Resources? 5. Do you think that a current policy should be enhanced or changed, or even retired? 6. Are you hesitant about making a formal proposal on the Public Policy Mail List (PPML)? 7. Are you new to the Policy Development Process? IF THE ANSWER TO ANY OF THESE QUESTIONS IS YES, THEN YOU SHOULD ATTEND THE OPEN POLICY HOUR! What is THE OPEN POLICY HOUR? Quite simply, it is your opportunity to get a better understanding of what is going to be discussed at the upcoming Public Policy Meeting or for you to discuss your ideas in an open, informal forum and receive feedback or both! The OPEN POLICY HOUR consists of two parts. Part One is the P2B2 or the Policy Proposal Background Briefing. ARIN staff will provide summary information regarding the policy proposals that will be discussed at the meeting. Members of the ARIN Advisory Council will be present to answer general questions about the policy proposals. There will be no discussion of the proposals, just the information that you need to help you understand the nature of the proposals and what has been said so far about them. Part Two is the P2B or the Policy Proposal BOF. This is where you get a chance to "test drive" a policy idea. How can you participate? Bring your ideas and questions. If you have a policy suggestion for which you would like to receive feedback prior to submitting it to the community on the PPML, here is your opportunity. If you have a short (3-minute) presentation prepared you will be given the first opportunity to present it. To sign up to give a presentation please send an e-mail to policy at arin.net by April 5, 2006 with your name, organization, and a brief description of your policy subject. Come join your colleagues in this informal setting. THE OPEN POLICY HOUR for ARIN XVII will be held on Sunday, April 9, from 4:30 - 5:30 PM. Registration for ARIN XVII is simple. Registration and hotel details are at: http://www.arin.net/ARIN-XVII/ Agenda information is at: http://www.arin.net/ARIN-XVII/agenda.html Contact Member Services at memsvcs at arin.net if you have any questions. Regards, Member Services Department American Registry for Internet Numbers From andrew.dul at quark.net Fri Mar 31 12:38:27 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Fri, 31 Mar 2006 17:38:27 +0000 Subject: [ppml] proposed updates to 2006-4 Message-ID: <20060331173827.7987.qmail@hoster908.com> Hello, As I've discussed this policy, a couple of parts of the existing text may need to be revised. 1. We should reserve a larger block than a /44. Reserving larger blocks at this point can likely only benefit us in the future as networks grow. I've proposed updating 2006-4 to a /40 reserved block, but I'm open to discussing larger blocks if people think that is needed. 2. Some people have raised concerns, that the original proposed text would restrict very large networks to only a single /48. The updated text allows a organization to be assigned at least 1 /48 per assigned ASN. If you have comments on these two changes, I'd certainly appreciate them. A copy of the proposed updated text is below. Thanks, Andrew ======================= 6.5.8. Direct assignments to end sites 6.5.8.1. To qualify for a direct end site assignment, an organization must: 1. not be an LIR; 2. be an end site; 3. be currently multihomed using IPv4; 4. have a direct assignment from ARIN of at least a IPv4 /19 and can show the current utilization of 80% of an IPv4 /19 equivalent. 6.5.8.2. Direct assignment size to end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment of /48 out of a reserved /40. Organizations with multiple ASNs may be assigned a prefix large enough to permit a /48 to be assigned to each ASN. Direct Assignments shall be allocated from a separate super-block to allow for LIRs to filter based upon assignment size. 6.5.8.3. Subsequent direct assignments to end sites Organizations assignment size may be increased by 1 bit (to a maximum of /40) when they demonstrate the active usage of 50% of the assigned /64 subnets or are actively using at least 50% of their /48 per ASN assignments. Organizations which can demonstrate active usage of more than 50% of /64 networks from a /40 assignment may apply for an additional allocation as an LIR. Only one direct assignment may be made to an end site organization under Section 6.5.8. From stephen at sprunk.org Fri Mar 31 13:15:47 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 31 Mar 2006 12:15:47 -0600 Subject: [ppml] proposed updates to 2006-4 References: <20060331173827.7987.qmail@hoster908.com> Message-ID: <023d01c654ef$2278b210$473816ac@ssprunk> Thus spake "Andrew Dul" > As I've discussed this policy, a couple of parts of the existing text may > need to be revised. > > 1. We should reserve a larger block than a /44. Reserving larger blocks > at this point can likely only benefit us in the future as networks grow. > I've proposed updating 2006-4 to a /40 reserved block, but I'm open to > discussing larger blocks if people think that is needed. /44 was 1,048,576 subnets; do we have any reason to believe a single end-user org will ever need to exceed that? If so, why do we think 16,777,216 subnets will be enough? This change is either unnecessary or insufficient. What it does mean is that ARIN will need to reserve 16 times as much space for each org, most of whom will never come close to needing a full /48. This goes from minimum 93.8% waste to minimum 99.6% waste. Is that a good thing? Perhaps if networks change significantly in the future we can revise this, but I'd much rather stick with /44 (or even just /48) and let the very few folks who need more become a LIR. Looking at it another way, if every AS in the NA region got a reserved /40, that would chew up nearly an entire /26, all to number what will most likely be 11,000 /48s (and probably 100k /64s). I know we have a lot of address space, but do we need to go out of our way to consume it? > 2. Some people have raised concerns, that the original proposed text would > restrict very large networks to only a single /48. The updated text > allows a organization to be assigned at least 1 /48 per assigned ASN. Seems reasonable. > If you have comments on these two changes, I'd certainly appreciate them. > > A copy of the proposed updated text is below. ... > Organizations assignment size may be increased by 1 bit (to a maximum of > /40) when they demonstrate the active usage of 50% of the assigned /64 > subnets or are actively using at least 50% of their /48 per ASN > assignments. I can't parse this new wording. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From jdhoule at att.com Fri Mar 31 13:27:46 2006 From: jdhoule at att.com (Houle, Joseph D (Joe), CMO) Date: Fri, 31 Mar 2006 12:27:46 -0600 Subject: [ppml] proposed updates to 2006-4 In-Reply-To: <20060331173827.7987.qmail@hoster908.com> Message-ID: Andrew: You sparked a thought... This "reserve" concept is a little orthogonal to ARINs standard Mode of Operating, isn't it? Isn't ARINs normal model something like: "We'll allocate you this block, now go away until you've demonstrated good usage?" We're likely talking about fairly big corporate IT organizations here right? These organizations are likely going to have multiple "sites"? (Whatever a site ends up really being.) Why doesn't ARIN just allocate a large enough block in the aggregate to the corporation. Block size should be large enough that most (95% maybe) corporations will never need to come back to the ARIN trough. I don't know if a /40 or a /44 or whatever is that size. Keeping ARIN allocations above the "site-level size" keeps open the opportunity for maintaining some level of aggregation in the IPv6 global routing tables. Also, allocating the whole block should have a significant lower administrative cost on ARIN than managing the reserve concept and responding to each /48-sized request. We shouldn't be overly wasteful here, but the trade-off between address conservation and simplicity should be somewhat different here in IPv6 than it was in IPv4. Joe Houle -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Andrew Dul Sent: Friday, March 31, 2006 12:38 PM To: ppml at arin.net Subject: [ppml] proposed updates to 2006-4 Hello, As I've discussed this policy, a couple of parts of the existing text may need to be revised. 1. We should reserve a larger block than a /44. Reserving larger blocks at this point can likely only benefit us in the future as networks grow. I've proposed updating 2006-4 to a /40 reserved block, but I'm open to discussing larger blocks if people think that is needed. 2. Some people have raised concerns, that the original proposed text would restrict very large networks to only a single /48. The updated text allows a organization to be assigned at least 1 /48 per assigned ASN. If you have comments on these two changes, I'd certainly appreciate them. A copy of the proposed updated text is below. Thanks, Andrew ======================= 6.5.8. Direct assignments to end sites 6.5.8.1. To qualify for a direct end site assignment, an organization must: 1. not be an LIR; 2. be an end site; 3. be currently multihomed using IPv4; 4. have a direct assignment from ARIN of at least a IPv4 /19 and can show the current utilization of 80% of an IPv4 /19 equivalent. 6.5.8.2. Direct assignment size to end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment of /48 out of a reserved /40. Organizations with multiple ASNs may be assigned a prefix large enough to permit a /48 to be assigned to each ASN. Direct Assignments shall be allocated from a separate super-block to allow for LIRs to filter based upon assignment size. 6.5.8.3. Subsequent direct assignments to end sites Organizations assignment size may be increased by 1 bit (to a maximum of /40) when they demonstrate the active usage of 50% of the assigned /64 subnets or are actively using at least 50% of their /48 per ASN assignments. Organizations which can demonstrate active usage of more than 50% of /64 networks from a /40 assignment may apply for an additional allocation as an LIR. Only one direct assignment may be made to an end site organization under Section 6.5.8. _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From andrew.dul at quark.net Fri Mar 31 13:32:57 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Fri, 31 Mar 2006 18:32:57 +0000 Subject: [ppml] proposed updates to 2006-4 Message-ID: <20060331183257.536.qmail@hoster908.com> > -------Original Message------- > From: Stephen Sprunk > Subject: Re: [ppml] proposed updates to 2006-4 > Sent: 31 Mar '06 10:15 > > Thus spake "Andrew Dul" > > As I've discussed this policy, a couple of parts of the existing text may > > need to be revised. > > > > 1. We should reserve a larger block than a /44. Reserving larger blocks > > at this point can likely only benefit us in the future as networks grow. > > I've proposed updating 2006-4 to a /40 reserved block, but I'm open to > > discussing larger blocks if people think that is needed. > > /44 was 1,048,576 subnets; do we have any reason to believe a single > end-user org will ever need to exceed that? If so, why do we think > 16,777,216 subnets will be enough? This change is either unnecessary or > insufficient. > We have to draw a line somewhere.../44 was too small for some, and too larger for others. We just need to find some common ground based on what we know today and then being mindful that this could change in the future. The reasoning descibed to me for the larger than /48 per org, would be if an org wanted to subnet each of their major facilities a /56 level. If you can assign a /56 to every home, then it seemed reasonable to me to assign a /56 to larger facilities within a large org. Andrew From andrew.dul at quark.net Fri Mar 31 13:49:04 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Fri, 31 Mar 2006 18:49:04 +0000 Subject: [ppml] proposed updates to 2006-4 Message-ID: <20060331184904.17527.qmail@hoster908.com> > -------Original Message------- > From: Houle, Joseph D (Joe), CMO > Subject: RE: [ppml] proposed updates to 2006-4 > Sent: 31 Mar '06 10:27 > > Andrew: > You sparked a thought... > This "reserve" concept is a little orthogonal to ARINs standard Mode > of Operating, isn't it? Yes & no...the IPv4 practice used to be if you were assigned a /19 ARIN reserved a /18 for about 1-2 years. (I don't know if that is current practice.) If you came back to ARIN within the reserve window you then were assigned the larger block which would be aggregatable. > Why doesn't ARIN just allocate a large enough block in the aggregate > to the corporation. Block size should be large enough that most (95% > maybe) corporations will never need to come back to the ARIN trough. I > don't know if a /40 or a /44 or whatever is that size. If I understand you correctly you are suggesting a minimum assignment size of /40 or /44 for every PI assignment? > Keeping ARIN allocations above the "site-level size" keeps open the > opportunity for maintaining some level of aggregation in the IPv6 global > routing tables. Others would likely argue that providing larger assignments opens up the possibility for more de-aggregation. My attempt with the 2006-4 policy was to try and limit the number of prefixes assigned per ORG/ASN to one. Andrew From jdhoule at att.com Fri Mar 31 14:09:47 2006 From: jdhoule at att.com (Houle, Joseph D (Joe), CMO) Date: Fri, 31 Mar 2006 13:09:47 -0600 Subject: [ppml] proposed updates to 2006-4 In-Reply-To: <20060331184904.17527.qmail@hoster908.com> Message-ID: ... If I understand you correctly you are suggesting a minimum assignment size of /40 or /44 for every PI assignment? [jdh] Yes... kinda makes PI for large corporations a mini-LIR, huh... is that so bad? > Keeping ARIN allocations above the "site-level size" keeps open the > opportunity for maintaining some level of aggregation in the IPv6 global > routing tables. Others would likely argue that providing larger assignments opens up the possibility for more de-aggregation. [jdh] ARIN's position is that it doesn't control what gets advertised in the Global Routing Table. That's true up to a point. When ARIN allocates a block, there is some expectation that that block will be announcable. Once ARIN is in the business of allocating site-sized blocks, that raises expectation that blocks, or sub-blocks down to site-size will be anounceable. This is one slope I would hope we can avoid sliding down in IPv6. My attempt with the 2006-4 policy was to try and limit the number of prefixes assigned per ORG/ASN to one. [jdh] I agree with that goal 100% Andrew _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From sleibrand at internap.com Fri Mar 31 14:13:59 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 31 Mar 2006 14:13:59 -0500 (EST) Subject: [ppml] proposed updates to 2006-4 In-Reply-To: <20060331184904.17527.qmail@hoster908.com> References: <20060331184904.17527.qmail@hoster908.com> Message-ID: On 03/31/06 at 6:49pm -0000, Andrew Dul wrote: > > -------Original Message------- > > From: Houle, Joseph D (Joe), CMO > > > > This "reserve" concept is a little orthogonal to ARINs standard Mode > > of Operating, isn't it? > > Yes & no...the IPv4 practice used to be if you were assigned a /19 ARIN reserved a /18 for about 1-2 years. (I don't know if that is current practice.) If you came back to ARIN within the reserve window you then were assigned the larger block which would be aggregatable. AFAICT this is still ARIN practice. Our last two ARIN IPv4 allocations were aggregatable. To address the concern expressed earlier on this thread that larger reservations use up more space, I would maintain that one advantage to having a large reserved block for future growth is that if down the road needs change ARIN can start allocating from the unused "holes" created by the sparse allocation. But if they don't need to, then you reduce the chance of an org having to deaggregate because they were given different non-aggregatable blocks at different points in their growth curve. -Scott