From Woeber at CC.UniVie.ac.at Fri Aug 3 17:45:38 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 03 Aug 2007 15:45:38 +0000 Subject: [address-policy-wg] 2007-06: New Policy Proposal (Global Policy for the Allocationof the Remaining IPv4 Address Space) In-Reply-To: <46ADE7FD.5080303@firstpr.com.au> References: <46ADE7FD.5080303@firstpr.com.au> Message-ID: <46B34DA2.5040208@CC.UniVie.ac.at> Robin Whittle wrote: > I believe that a substantial amount of the remaining IPv4 space > should be put aside to be used with whichever new architecture is > developed to deal with the routing and addressing problems > discussed last year in the IAB RAWS workshop. What are the (expected) architectural limitations that (will most likely) prevent deployment of those superiour mechanisms in address space that is in use already? Or the other way 'round, why do we need to set address space aside? > That new architecture will be able to apply address space much > more efficiently in terms of number of end-users, the proportion > of IP addresses actually used, and the usefulness of the address > space in terms of multihoming and portability without burdening > the BGP routing system. Again, I do not grok why unused address space has to be reserved for that regime. > This reservation - and perhaps operation of the new system - might > best be done by the RIRs. I want to suggest this as part of a > debate about how to make best use of the remaining fresh IPv4 space. Wilfried. From gert at space.net Mon Aug 6 16:21:40 2007 From: gert at space.net (Gert Doering) Date: Mon, 6 Aug 2007 16:21:40 +0200 Subject: [address-policy-wg] 1st DRAFT agenda for RIPE 55 APWG meeting Message-ID: <20070806142140.GY69215@Space.Net> Dear RIPE address policy WG members, here's a proposal for the APWG meeting agenda for the upcoming RIPE meeting (in October in Amsterdam). This time we're early, so there is time to shuffle things around, etc... - please send your suggestions. ----------------------------- snip -------------------------------- Wednesday, October 24, 11:00-12:30: - formal stuff - overview of concluded proposals (whatever those are, in October) - enough time for generic discussion on PI (IPv4, IPv6, contracts, maybe also covering AS numbers) - Leo Vegoda: a proposal for restructuring of the IPv6 policy Thursday, October 25, 09:00-10:30: - discussion of all other currently-open proposals - new proposals that are not yet in the PDP - AOB ----------------------------- snip -------------------------------- Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From bgp2 at linuxadmin.org Wed Aug 8 05:36:06 2007 From: bgp2 at linuxadmin.org (Greg L.) Date: Tue, 07 Aug 2007 20:36:06 -0700 Subject: [address-policy-wg] PI for Not-DNS Anycast. Message-ID: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> I think that the PI /24 block should be assigned only to UDP related services as RFC suggests, however, I have yet to see the successful implementation of TCP data, state... replication in case one router withdraws BGP announcement of the /24 prefix. IPv4 anycast is a perfect way to distribute load and hopefully with lowest latency (not always true) for the following UDP related services: -syslog -dns -ddos mitigation The PI /24 anycast block should be assigned only when the applicant can demonstrate: at least 5 physically disperse locations (verification done by traceroute and checking the hop before the last hop in the traceroute). Traceroute's can be performed from open traceroute gateways (over the web etc - there are hundreds) or public ISP BGP route servers. to manage the server you will need a non anycast address(es), however, customers may keep this info secret if they do not want it to be public.... all anycast nodes must speak BGP to the upstream and in case the server goes down, the BGP router withdraws the BGP anycast /24 route Ps. If Ripe will allow anycast /24 PI allocation for syslog and ddos, and other UDP based services, then expect all free /24 blocks taken in a year or less for sure ;) My $0.02 cents... Greg http://www.LinuxAdmin.org From gert at space.net Wed Aug 8 09:28:49 2007 From: gert at space.net (Gert Doering) Date: Wed, 8 Aug 2007 09:28:49 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> Message-ID: <20070808072849.GN69215@Space.Net> Hi, On Tue, Aug 07, 2007 at 08:36:06PM -0700, Greg L. wrote: > Ps. If Ripe will allow anycast /24 PI allocation for syslog and ddos, and > other UDP based services, then expect all free /24 blocks taken in a year > or less for sure ;) So what's your message? Do you support handing out /24 PI for "these" applications, or do you oppose it, due to address space / routing table slots usage? Your e-mail was a bit unclear in that respect... Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From bgp2 at linuxadmin.org Wed Aug 8 21:38:44 2007 From: bgp2 at linuxadmin.org (Greg L.) Date: Wed, 08 Aug 2007 12:38:44 -0700 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <20070808072849.GN69215@Space.Net> References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <20070808072849.GN69215@Space.Net> Message-ID: <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> I would say IPv4 anycast /24 PI must be allocated for anycasting DNS service only. You simply can't add more nameservers if you hit the max limit... The rules for IPv6 anycast allocations must be not that strict in the future... why? The address space will be more than enough, the router HW will be more powerful to handle large routing tables ... Sincerely, Greg L. >On Tue, Aug 07, 2007 at 08:36:06PM -0700, Greg L. wrote: > > Ps. If Ripe will allow anycast /24 PI allocation for syslog and ddos, and > > other UDP based services, then expect all free /24 blocks taken in a year > > or less for sure ;) > >So what's your message? Do you support handing out /24 PI for "these" >applications, or do you oppose it, due to address space / routing table >slots usage? > >Your e-mail was a bit unclear in that respect... > >Gert Doering > -- APWG chair >-- >Total number of prefixes smaller than registry allocations: 113403 > >SpaceNet AG Vorstand: Sebastian v. Bomhard >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >D-80807 Muenchen HRB: 136055 (AG Muenchen) >Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From jorgen at hovland.cx Wed Aug 8 12:56:42 2007 From: jorgen at hovland.cx (=?utf-8?Q?J=C3=B8rgen_Hovland?=) Date: Wed, 8 Aug 2007 12:56:42 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <20070808072849.GN69215@Space.Net> <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> Message-ID: Hi Greg, > I would say IPv4 anycast /24 PI must be allocated for anycasting DNS > service only. You simply can't add more nameservers if you hit the max limit... That is an incorrect assumption no matter how you look at it. To me, the biggest problem seems to be that people either doesn't know better or actually don't want to know better regarding this topic. I have probably written this before, and some people have probably answered, but: You can add as many anycast nameservers as you want without any prefix at all. They obviously have to be in the same asn/ip-network if you want to anycast without using your own prefix in dfz. You can also use other similar techniques than ancyast, for example network load balancing. The NS limit in a response is what, 13 entries? If you need more than 13 nameservers spread around 13 different networks, and they are all anycasted for each network, then you really need to start thinking about running some other nameserver software because it is obviously not designed to scale anyway. If you actually have 13 NS entries and 10 anycast servers per entry, you should be able to handle more than 7 billion requests per second with cheap hardware. DDoS is not a problem with decent hardware. With 7 billion requests per second I am sure you can afford it. j -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Greg L. Sent: 8. august 2007 21:39 To: Gert Doering Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] PI for Not-DNS Anycast. I would say IPv4 anycast /24 PI must be allocated for anycasting DNS service only. You simply can't add more nameservers if you hit the max limit... The rules for IPv6 anycast allocations must be not that strict in the future... why? The address space will be more than enough, the router HW will be more powerful to handle large routing tables ... Sincerely, Greg L. >On Tue, Aug 07, 2007 at 08:36:06PM -0700, Greg L. wrote: > > Ps. If Ripe will allow anycast /24 PI allocation for syslog and ddos, and > > other UDP based services, then expect all free /24 blocks taken in a year > > or less for sure ;) > >So what's your message? Do you support handing out /24 PI for "these" >applications, or do you oppose it, due to address space / routing table >slots usage? > >Your e-mail was a bit unclear in that respect... > >Gert Doering > -- APWG chair >-- >Total number of prefixes smaller than registry allocations: 113403 > >SpaceNet AG Vorstand: Sebastian v. Bomhard >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >D-80807 Muenchen HRB: 136055 (AG Muenchen) >Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From bgp2 at linuxadmin.org Wed Aug 8 23:15:15 2007 From: bgp2 at linuxadmin.org (Greg L.) Date: Wed, 08 Aug 2007 14:15:15 -0700 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <20070808072849.GN69215@Space.Net> <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> Message-ID: <6.1.2.0.2.20070808141053.04a80198@www.linuxadmin.org> > > > I would say IPv4 anycast /24 PI must be allocated for anycasting DNS > > service only. You simply can't add more nameservers if you hit the max > limit... > >That is an incorrect assumption no matter how you look at it. >To me, the biggest problem seems to be that people either doesn't know >better or actually don't want to know better regarding this topic. > >I have probably written this before, and some people have probably >answered, but: >You can add as many anycast nameservers as you want without any prefix at >all. They obviously have to be in the same asn/ip-network if you want to >anycast without using your own prefix in dfz. >You can also use other similar techniques than ancyast, for example >network load balancing. Thanks for your response. Who needs a new /24 PI if you are only going to implement DNS anycast in your own network? I was speaking about global DNS anycast /24 PI allocation with min. ~5 disperse locations / networks, verified later by running traceroutes to see ASN, data path etc... Thanks Greg From jgutauer at cw.net Wed Aug 8 13:26:01 2007 From: jgutauer at cw.net (Johann Gutauer) Date: Wed, 08 Aug 2007 13:26:01 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <6.1.2.0.2.20070808141053.04a80198@www.linuxadmin.org> References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <20070808072849.GN69215@Space.Net> <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> <6.1.2.0.2.20070808141053.04a80198@www.linuxadmin.org> Message-ID: <46B9A849.8020601@cw.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg L. wrote: [...] > Who needs a new /24 PI if you are only going to implement DNS anycast in > your own network? > I was speaking about global DNS anycast /24 PI allocation with min. ~5 > disperse locations / networks, verified later by running traceroutes to > see ASN, data path etc... [...] ... and it shouldn't be linked to running ccTLD-Servers. Neither in IPv4 nor in IPv6. Cheers, Johann - -- Johann Gutauer, jgutauer at cw.net Sen. Netw. Engineer DNS Cable&Wireless Telecommunication Services GmbH Tel: +49 89 92699 499 Landsberger Str.155 D-80687 M?nchen Deutschland Fax: +49 89 92699 810 Gesch?ftsf?hrer Chris Connors, Jonathan Walters, Richard Pennal http://www.cw.com/de Amtsgericht M?nchen HRB 146 617 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGuahJQ7r8ZjAASRARAq2tAJ9XOcayzz5iJx8Q++hpn3Hkl1ZmvgCfULoE 7gXlzADTJATTUX7zAfhlfRk= =aEeE -----END PGP SIGNATURE----- From jorgen at hovland.cx Wed Aug 8 13:36:59 2007 From: jorgen at hovland.cx (=?utf-8?Q?J=C3=B8rgen_Hovland?=) Date: Wed, 8 Aug 2007 13:36:59 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <6.1.2.0.2.20070808141053.04a80198@www.linuxadmin.org> References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <20070808072849.GN69215@Space.Net> <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> <6.1.2.0.2.20070808141053.04a80198@www.linuxadmin.org> Message-ID: <225F1235E5F64F868D40987868F322F0@tungemaskin> -----Original Message----- From: Greg L. [mailto:bgp2 at linuxadmin.org] >Thanks for your response. >Who needs a new /24 PI if you are only going to implement DNS anycast in your own network? Why do you need anycast DNS? Suggestions: * To scale (and keep 100% uptime) * DDoS prevention/reduction of weaknesses The scaling problem has already been solved in my previous email. To take down all of your nameservers, the best way would probably be to generate a lot of DNS queries. But then we are back at the scaling problem which has already been solved. So what is the real problem? Cheers, j From bgp2 at linuxadmin.org Wed Aug 8 23:50:58 2007 From: bgp2 at linuxadmin.org (Greg L.) Date: Wed, 08 Aug 2007 14:50:58 -0700 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <46B9A849.8020601@cw.net> References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <20070808072849.GN69215@Space.Net> <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> <6.1.2.0.2.20070808141053.04a80198@www.linuxadmin.org> <46B9A849.8020601@cw.net> Message-ID: <6.1.2.0.2.20070808144716.04a68fe0@www.linuxadmin.org> > > > Who needs a new /24 PI if you are only going to implement DNS anycast in > > your own network? > > I was speaking about global DNS anycast /24 PI allocation with min. ~5 > > disperse locations / networks, verified later by running traceroutes to > > see ASN, data path etc... >[...] >... and it shouldn't be linked to running ccTLD-Servers. Neither in IPv4 >nor in IPv6. Sure it shouldn't. ccTLD DNS hosting requirement for /24 PI anycast assignment already forces small companies into unfair competence with LIR members and big guys. Sincerely, Greg LinuxAdmin.org From bgp2 at linuxadmin.org Wed Aug 8 23:55:18 2007 From: bgp2 at linuxadmin.org (Greg L.) Date: Wed, 08 Aug 2007 14:55:18 -0700 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <56D28A2B-4287-41FA-8501-73B996CC1764@icann.org> References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <20070808072849.GN69215@Space.Net> <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> <6.1.2.0.2.20070808141053.04a80198@www.linuxadmin.org> <56D28A2B-4287-41FA-8501-73B996CC1764@icann.org> Message-ID: <6.1.2.0.2.20070808145156.04a68c08@www.linuxadmin.org> Leo: >>I was speaking about global DNS anycast /24 PI allocation with >>min. ~5 disperse locations / networks, verified later by running >>traceroutes to see ASN, data path etc... > >What is the reasoning behind the minimum of five locations? Why would >four be too few? No problem, it was just a suggestion. I remember reading email in the list with 8+ disperse location requirement. Greg From Woeber at CC.UniVie.ac.at Wed Aug 8 14:05:31 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 08 Aug 2007 12:05:31 +0000 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <6.1.2.0.2.20070808145156.04a68c08@www.linuxadmin.org> References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <20070808072849.GN69215@Space.Net> <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> <6.1.2.0.2.20070808141053.04a80198@www.linuxadmin.org> <56D28A2B-4287-41FA-8501-73B996CC1764@icann.org> <6.1.2.0.2.20070808145156.04a68c08@www.linuxadmin.org> Message-ID: <46B9B18B.9010306@CC.UniVie.ac.at> Greg L. wrote: > > > Leo: > > >>> I was speaking about global DNS anycast /24 PI allocation with >>> min. ~5 disperse locations / networks, verified later by running >>> traceroutes to see ASN, data path etc... >> >> >> What is the reasoning behind the minimum of five locations? Why would >> four be too few? > > > No problem, it was just a suggestion. I remember reading email in the > list with 8+ disperse location requirement. So, we are rolling the dice again to come up with another "magic", arbitrarily chosen figure which is supposed to discriminate between those who "qualify" and those which don't? > Greg > IIRC, we spent a lot f effort recently to get rid of one of those magic numbers in one policy... IMHO, anycast becomes anycast, as opposed to unicast, as soon as you've got more than one, i.e. 2 (two) - or more. Right? Wilfried. From leo.vegoda at icann.org Wed Aug 8 13:33:32 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 8 Aug 2007 13:33:32 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <6.1.2.0.2.20070808141053.04a80198@www.linuxadmin.org> References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <20070808072849.GN69215@Space.Net> <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> <6.1.2.0.2.20070808141053.04a80198@www.linuxadmin.org> Message-ID: <56D28A2B-4287-41FA-8501-73B996CC1764@icann.org> Hi Greg, On 8 Aug 2007, at 23:15, Greg L. wrote: [...] > I was speaking about global DNS anycast /24 PI allocation with > min. ~5 disperse locations / networks, verified later by running > traceroutes to see ASN, data path etc... What is the reasoning behind the minimum of five locations? Why would four be too few? Regards, Leo Vegoda From bgp2 at linuxadmin.org Thu Aug 9 00:16:51 2007 From: bgp2 at linuxadmin.org (Greg L.) Date: Wed, 08 Aug 2007 15:16:51 -0700 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <225F1235E5F64F868D40987868F322F0@tungemaskin> References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <20070808072849.GN69215@Space.Net> <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> <6.1.2.0.2.20070808141053.04a80198@www.linuxadmin.org> <225F1235E5F64F868D40987868F322F0@tungemaskin> Message-ID: <6.1.2.0.2.20070808145558.04a68fe0@www.linuxadmin.org> At 04:36 2007.08.08.?, J??rgen Hovland wrote: >-----Original Message----- >From: Greg L. [mailto:bgp2 at linuxadmin.org] > > > >Thanks for your response. > >Who needs a new /24 PI if you are only going to implement DNS anycast in >your own network? > >Why do you need anycast DNS? >Suggestions: > >* To scale (and keep 100% uptime) >* DDoS prevention/reduction of weaknesses > > >The scaling problem has already been solved in my previous email. > >To take down all of your nameservers, the best way would probably be to >generate a lot of DNS queries. But then we are back at the scaling problem >which has already been solved. So what is the real problem? To speed up DNS queries for their customers and clients. If I was running DNS hosting service I would prefer to have Australian visitors querying DNS boxes in Australia. Clients from Germany querying anycast node in Germany. And if I was in Romania, all local clients to "hit" DNS anycast IP in Romania. Why should only ccTLD's and some large LIR's allowed to lower the service query latency for DNS traffic and sometimes cut the bandwidth bills? ccTLD service should be NOT the only exception to get /24 PI for anycast DNS, the policy should be open for any business entity that can demonstrate the need for /24 PI DNS anycast allocation and 2+ disperse locations where this prefix is announced. Greg From nick at inex.ie Wed Aug 8 14:19:03 2007 From: nick at inex.ie (Nick Hilliard) Date: Wed, 08 Aug 2007 13:19:03 +0100 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <56D28A2B-4287-41FA-8501-73B996CC1764@icann.org> References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <20070808072849.GN69215@Space.Net> <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> <6.1.2.0.2.20070808141053.04a80198@www.linuxadmin.org> <56D28A2B-4287-41FA-8501-73B996CC1764@icann.org> Message-ID: <46B9B4B7.3000501@inex.ie> Leo Vegoda wrote: > What is the reasoning behind the minimum of five locations? Why would > four be too few? This is the great thing about magic numbers. They offer a thin veneer of authority and the possibility of enabling easy policing. In many respects, it a real pity that rules based on numbers pulled out of the air like this have such a completely arbitrary basis. Life would be much easier. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From gert at space.net Wed Aug 8 14:31:54 2007 From: gert at space.net (Gert Doering) Date: Wed, 8 Aug 2007 14:31:54 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <6.1.2.0.2.20070808145558.04a68fe0@www.linuxadmin.org> References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <20070808072849.GN69215@Space.Net> <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> <6.1.2.0.2.20070808141053.04a80198@www.linuxadmin.org> <225F1235E5F64F868D40987868F322F0@tungemaskin> <6.1.2.0.2.20070808145558.04a68fe0@www.linuxadmin.org> Message-ID: <20070808123154.GZ69215@Space.Net> Hi, just to point something out: On Wed, Aug 08, 2007 at 03:16:51PM -0700, Greg L. wrote: > ccTLD service should be NOT the only exception to get /24 PI for anycast > DNS, the policy should be open for any business entity that can demonstrate > the need for /24 PI DNS anycast allocation and 2+ disperse locations where > this prefix is announced. So far, I have seen *one* entity speak up and say "we want to do DNS anycast, and we're not a ccTLD operator". So there's certainly not overwhelming demand (yet?). Argueing on behalf of not-so-well defined others isn't too helpful in policy development... Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From jorgen at hovland.cx Wed Aug 8 15:12:52 2007 From: jorgen at hovland.cx (=?utf-8?Q?J=C3=B8rgen_Hovland?=) Date: Wed, 8 Aug 2007 15:12:52 +0200 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <6.1.2.0.2.20070808145558.04a68fe0@www.linuxadmin.org> References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <20070808072849.GN69215@Space.Net> <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> <6.1.2.0.2.20070808141053.04a80198@www.linuxadmin.org> <225F1235E5F64F868D40987868F322F0@tungemaskin> <6.1.2.0.2.20070808145558.04a68fe0@www.linuxadmin.org> Message-ID: -----Original Message----- From: Greg L. [mailto:bgp2 at linuxadmin.org] > To speed up DNS queries for their customers and clients. If I was running DNS hosting service I would prefer to have Australian visitors querying DNS boxes in Australia. ... I can't get myself to agree with you on that, but I understand the problem. If you actually have customers in Australia, TTL will take care of that for you. If you only have a few customers it cannot possibly be that important to have slightly lower latency for your domain at the first query. (FYI we are a medium size dns hosting company) > If I was running DNS hosting service I would prefer to have Australian visitors querying DNS boxes in Australia. Clients from Germany querying anycast node in Germany. And if I was in Romania, all local clients to "hit" DNS anycast IP in Romania. Sure thing, but you probably mean the closest DNS box network wise/AS-hop/latency, not by country. > Why should only ccTLD's They shouldn't. > and some large LIR's Large LIRs probably have a decent network and can do what they want within their own network. Do you disagree that they should have that advantage? >..allowed to lower the service query latency for DNS traffic and sometimes cut the bandwidth bills? Cheers, j From david.conrad at icann.org Wed Aug 8 16:04:06 2007 From: david.conrad at icann.org (David Conrad) Date: Wed, 8 Aug 2007 07:04:06 -0700 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <20070808072849.GN69215@Space.Net> <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> Message-ID: Hi, On Aug 8, 2007, at 12:38 PM, Greg L. wrote: > I would say IPv4 anycast /24 PI must be allocated for anycasting > DNS service only. You simply can't add more nameservers if you hit > the max limit... The term "overkill" comes to mind. How many name servers does one actually need (anycast or not), particularly given the concept of caching? > The rules for IPv6 anycast allocations must be not that strict in > the future... why? The address space will be more than enough, the > router HW will be more powerful to handle large routing tables ... While router hardware will undoubtedly be more powerful, the question of whether or not BGP will be able to converge with everybody and their great aunt having PI space is still open. Then there is the question of whether or not people will be happy with the O(10) ISPs capable of affording the hardware/power/cooling of the future DFZ routers (have you priced top-end routers recently?). This proposal seems a bit on the extreme side to me. Rgds, -drc From bgp2 at linuxadmin.org Wed Aug 8 16:07:36 2007 From: bgp2 at linuxadmin.org (Greg L.) Date: Wed, 08 Aug 2007 17:07:36 +0300 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <20070808072849.GN69215@Space.Net> <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> <6.1.2.0.2.20070808141053.04a80198@www.linuxadmin.org> <225F1235E5F64F868D40987868F322F0@tungemaskin> <6.1.2.0.2.20070808145558.04a68fe0@www.linuxadmin.org> Message-ID: <6.1.2.0.2.20070808165511.04b0d018@www.linuxadmin.org> > > > and some large LIR's > >Large LIRs probably have a decent network and can do what they want within >their own network. Do you disagree that they should have that advantage? > > Sure it's their advantage... However, I cannot understand .. there are some companies that offer global anycast dns service in USA or ARIN has different rules (they didn't approve /24 for dns anycast back in 2005 I believe)? How these companies can meet 25% initial and 50% utilization in one year for that /24 allocation? Sincerely, Greg From swmike at swm.pp.se Wed Aug 8 16:11:40 2007 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 8 Aug 2007 16:11:40 +0200 (CEST) Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> Message-ID: On Tue, 7 Aug 2007, Greg L. wrote: > I think that the PI /24 block should be assigned only to UDP related services > as RFC suggests, however, I have yet to see the successful implementation of > TCP data, state... replication in case one router withdraws BGP announcement > of the /24 prefix. As I have stated before, there are TCP based services (IRC) that already today use /24 PIs for anycast. No, they do not handle state. -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Wed Aug 8 16:33:35 2007 From: randy at psg.com (Randy Bush) Date: Wed, 08 Aug 2007 04:33:35 -1000 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> Message-ID: <46B9D43F.9030801@psg.com> > As I have stated before, there are TCP based services (IRC) that already > today use /24 PIs for anycast. No, they do not handle state. and this statement was true ten years ago randy From bgp2 at linuxadmin.org Tue Aug 7 19:02:23 2007 From: bgp2 at linuxadmin.org (Greg L.) Date: Tue, 07 Aug 2007 20:02:23 +0300 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <20070808072849.GN69215@Space.Net> <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> Message-ID: <6.1.2.0.2.20070808193130.04ae9c50@www.linuxadmin.org> Disperse located servers powered by anycast bgp will be much more resilient to attacks and local node can take the direct hit. Other anycast based locations will function as usual, unless the attack brings down the box and /24 route is withdrawn.... More and more Internet based services take advantages of lower TTL (many ISPs ignore it but still...) and if both dns servers for the particular domain are attacked with UDP flood and there is no cache record on your ISP's recursive DNS server - the service will be down. In anycast situation, a fraction of the clients will be affected... I still think /24 block anycast PI policy should be more open towards other business entities, not only for ccTLD's. Actually not that many ccTLDs use BGP anycast anyway.... I wish our company had monopoly for some Internet services or even monopoly for ccTLD registration - we would not care and spend $$ for set-up and additional monthly expenses by running anycast based DNS service either. ;) Unfortunately, we need to compete in business.... Sincerely, Greg At 17:04 2007.08.08.?, David Conrad wrote: >Hi, > >On Aug 8, 2007, at 12:38 PM, Greg L. wrote: >>I would say IPv4 anycast /24 PI must be allocated for anycasting >>DNS service only. You simply can't add more nameservers if you hit >>the max limit... > >The term "overkill" comes to mind. How many name servers does one >actually need (anycast or not), particularly given the concept of >caching? > >>The rules for IPv6 anycast allocations must be not that strict in >>the future... why? The address space will be more than enough, the >>router HW will be more powerful to handle large routing tables ... > >While router hardware will undoubtedly be more powerful, the question >of whether or not BGP will be able to converge with everybody and >their great aunt having PI space is still open. Then there is the >question of whether or not people will be happy with the O(10) ISPs >capable of affording the hardware/power/cooling of the future DFZ >routers (have you priced top-end routers recently?). > >This proposal seems a bit on the extreme side to me. > >Rgds, >-drc > From rogerj at jorgensen.no Wed Aug 8 19:06:44 2007 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Wed, 8 Aug 2007 19:06:44 +0200 (CEST) Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <46B9D43F.9030801@psg.com> References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <46B9D43F.9030801@psg.com> Message-ID: On Wed, 8 Aug 2007, Randy Bush wrote: >> As I have stated before, there are TCP based services (IRC) that already >> today use /24 PIs for anycast. No, they do not handle state. > > and this statement was true ten years ago why isn't it true anymore? Afaik those irc-services mention above are still operative. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From randy at psg.com Wed Aug 8 19:59:09 2007 From: randy at psg.com (Randy Bush) Date: Wed, 08 Aug 2007 07:59:09 -1000 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <46B9D43F.9030801@psg.com> Message-ID: <46BA046D.9010100@psg.com> >>> As I have stated before, there are TCP based services (IRC) that already >>> today use /24 PIs for anycast. No, they do not handle state. >> and this statement was true ten years ago > why isn't it true anymore? Afaik those irc-services mention above are > still operative. i did not mean to imply it was not still true. merely wishing to point out this is old old old; well, maybe only two olds. randy From president at ukraine.su Sat Aug 11 21:39:03 2007 From: president at ukraine.su (Max Tulyev) Date: Sat, 11 Aug 2007 22:39:03 +0300 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> References: <20084E5A-2EC9-4E73-925D-5C9160610856@nosignal.org> Message-ID: <46BE1057.90707@ukraine.su> Hi, I think Anycast should be just an extra issue for getting a "regular" PI, and that PI should be not less than /24. Why not less than /24? Because of less size networks not routed in global Internet. Of course, we can do policies whatever we want, thinking about conservation, but people will have to lie to RIPE NCC to get really useful block (or even got less size block, spend money and time, and have to drop it because of unable to provide service). By the way, what is current anycast projects' behavior now? Getting a "regular" PI? Getting more specific from somebody? Andy Davidson wrote: > > Hi, > > Can I get the community's thoughts on this, please .. > > I think we have a well defined policy on what to do when someone needs > some PI in order to run an Anycasted DNS service. We set out a family > of requirements based on geographic diversity, for instance, that > clearly states what should be in place when a request for PI for DNS use > is made. > > What if a company wants to try to deploy an anycasted production service > for something which is not DNS ? It could be a proprietary protocol, or > something standard like http. Is the community view that they should > just deaggregate some of their PA - which I don't like the sound of - or > apply for PI in the normal way, and pretend anycast isn't necessarily > involved ? > > Many thanks > Andy > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From michael.dillon at bt.com Mon Aug 13 21:41:29 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 13 Aug 2007 20:41:29 +0100 Subject: [address-policy-wg] PI for Not-DNS Anycast. In-Reply-To: <46B9B4B7.3000501@inex.ie> References: <6.1.2.0.2.20070807195844.04c9f9c0@wheresmymailserver.com> <20070808072849.GN69215@Space.Net> <6.1.2.0.2.20070808123210.04a908e8@www.linuxadmin.org> <6.1.2.0.2.20070808141053.04a80198@www.linuxadmin.org> <56D28A2B-4287-41FA-8501-73B996CC1764@icann.org> <46B9B4B7.3000501@inex.ie> Message-ID: > This is the great thing about magic numbers. They offer a > thin veneer of authority and the possibility of enabling easy > policing. In many respects, it a real pity that rules based > on numbers pulled out of the air like this have such a > completely arbitrary basis. Life would be much easier. So where does the magic number 53 come from? Why is this anycast policy only going to give an address block to those who wish to anycast services on port 53? If I ran http on port 53, could I get an allocation under this policy? Why not? Note that when this was discussed in the past, it was pointed out that some people had done some actual experiments and discovered that many protocols which seem to be not-anycastable, are able to be anycast in practice due to the stability of the net. RIPE should not be making arbitrary limits on what people can do. Yes, let's have a policy to give out address blocks to people who can show that they are running (or intend to run) real anycast services. Let's not restrict what those services are. If we are concerned about too many requests coming in, then let's place an arbitrary numerical limit for now, which can be removed later. In the case of anycast, the relevant thing to count for an arbitrary limit, is the number of separate geographical locations. Two is sufficient from a technical point of view, but given that RIPE policy can change to meet changing needs, it seems to me that it is not unreasonable to place a larger limit, perhaps 4, perhaps 5. --Michael Dillon From rumy at ripe.net Mon Aug 20 16:39:05 2007 From: rumy at ripe.net (Rumy Kanis) Date: Mon, 20 Aug 2007 16:39:05 +0200 Subject: [address-policy-wg] New E-Learning Module: The RIPE Policy Development Process Message-ID: <46C9A789.9080506@ripe.net> Dear Colleagues, We are pleased to announce the launch of the latest module on the RIPE NCC E-Learning Centre: - The RIPE Policy Development Process This module explains how the process works and how you can take part in it. Once you have completed the module you will know how to: - Propose a new policy - Propose a change to an existing policy - Monitor policy discussions - Participate in policy discussions The RIPE NCC E-Learning Centre is a free-of-charge service available to everyone, and it can be found at: https://e-learning.ripe.net If you have any questions, please feel free to contact us at . Happy Learning, Rumy Kanis Training Services Manager RIPE NCC From rumy at ripe.net Mon Aug 20 16:39:05 2007 From: rumy at ripe.net (Rumy Kanis) Date: Mon, 20 Aug 2007 16:39:05 +0200 Subject: [address-policy-wg] [ncc-announce] New E-Learning Module: The RIPE Policy Development Process Message-ID: <46C9A789.9080506@ripe.net> Dear Colleagues, We are pleased to announce the launch of the latest module on the RIPE NCC E-Learning Centre: - The RIPE Policy Development Process This module explains how the process works and how you can take part in it. Once you have completed the module you will know how to: - Propose a new policy - Propose a change to an existing policy - Monitor policy discussions - Participate in policy discussions The RIPE NCC E-Learning Centre is a free-of-charge service available to everyone, and it can be found at: https://e-learning.ripe.net If you have any questions, please feel free to contact us at . Happy Learning, Rumy Kanis Training Services Manager RIPE NCC From Woeber at CC.UniVie.ac.at Fri Aug 24 12:02:53 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 24 Aug 2007 10:02:53 +0000 Subject: [address-policy-wg] Re: Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: In-Reply-To: <152533.59187.qm@web33106.mail.mud.yahoo.com> References: <152533.59187.qm@web33106.mail.mud.yahoo.com> Message-ID: <46CEACCD.3010800@CC.UniVie.ac.at> Dear Mattew, you request describes a situation that gets discussed again and again, but up till now these discussions haven't gotten anywhere close to a well-prepared and broadly accepted or acceptable proposal. Maybe now it is time to work on it again? However, imho, trying to make real progress involves modifying quite a few policies, procedures and behaviour patterns; not just with the ISPs but for the community at large. And on top of that, I guess we need a better definition of "contact" and the facility or mechanisms which theses contacts are expected (or requied) to provide, and to whom. May I suggest that you try to step forward with a proposal that fits in with the "Policy Development Process" for the RIPE region? You can find the details for this appraoch at the following page and/or document(s): RIPE Policy Development http://www.ripe.net/ripe/policies/ Policy Development Process in RIPE (Document ID: ripe-350) http://www.ripe.net/ripe/docs/pdp.html Regards, Wilfried W?ber (RIPE-DB WG Chair and member of the Data-Privacy TaskForce) BabyMatthew253 wrote: > To whoever may read these: > > I Matthew Brown, would like to request that there be some sort of action, to allow the ripe database managers to contact ISP(s) when someone reports incorrect or outdated information. This would be very helpful in the process of fighting spam and abuse, and when you rely on the whois servers around the world to get the correct email address(es) so you may forward the abuse/spam to the correct department, but only to have if fail because of outdated data, is not useful in the process of reporting it. As an internet user myself, it is a pain to get so much spam and abusive emails. I'm tired of opening my mailbox on a daily basis, to see I've gotten not one, or two, but on average 75 spam messages a day. And simply telling my email provider, in this case it is Yahoo, that an email is spam/abuse, is not enough to stop it from coming into my mailbox. I now take the time to report it to the proper ISP that holds the IP address where the spam/abuse comes from, or sometimes > its a potential virus that comes in the form of a URL/Web pages to visit. So, I rely on having correct data. Please look into developing a policy that will allow the ripe database managers the resources to contact ISP(s) when someone reports incorrect information, so that those of us, like me, who are tired of the amount of spam they get can have correct information when they go to look for it, instead of having to make phone contact with each individual ISP who happens to be international for me. I know that the whois database at www.arin.net has the resources to make contact when someone reports incorrect data, so why not follow suit and have the same resources to do the same thing. > > Sincerely, > Matthew Brown > > RIPE Database Manager wrote: To: BabyMatthew253 > Subject: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: > From: RIPE Database Manager > Date: Fri, 24 Aug 2007 10:25:14 +0200 > > > Dear BabyMatthew253, > > Thank you for your email regarding out of date contact data in the RIPE > database. > > There may be options we could pursue to check the validity of the contact > data in the objects in the RIPE Database. Where we have a direct > relationship with the owners of these objects we could request that they > update this information. But we do not have a mandate from the RIPE > community to allocate any resources to this activity. If you feel this > should have a higher priority then you may raise the issue on the Database > Working Group or Antispam Working Group or Address Policy Working Group > mailing lists. You can find information about the mailing lists here > > http://www.ripe.net/ripe/wg/index.html > > These are open working groups and views are welcomed from anyone who > wishes to discuss relevant issues. > > > Regards, > > Milena Rakin > ____________________________ > RIPE Database Administration. > > > > > --------------------------------- > Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. From babymattb253 at yahoo.com Fri Aug 24 10:54:48 2007 From: babymattb253 at yahoo.com (BabyMatthew253) Date: Fri, 24 Aug 2007 01:54:48 -0700 (PDT) Subject: [address-policy-wg] Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: Message-ID: <152533.59187.qm@web33106.mail.mud.yahoo.com> To whoever may read these: I Matthew Brown, would like to request that there be some sort of action, to allow the ripe database managers to contact ISP(s) when someone reports incorrect or outdated information. This would be very helpful in the process of fighting spam and abuse, and when you rely on the whois servers around the world to get the correct email address(es) so you may forward the abuse/spam to the correct department, but only to have if fail because of outdated data, is not useful in the process of reporting it. As an internet user myself, it is a pain to get so much spam and abusive emails. I'm tired of opening my mailbox on a daily basis, to see I've gotten not one, or two, but on average 75 spam messages a day. And simply telling my email provider, in this case it is Yahoo, that an email is spam/abuse, is not enough to stop it from coming into my mailbox. I now take the time to report it to the proper ISP that holds the IP address where the spam/abuse comes from, or sometimes its a potential virus that comes in the form of a URL/Web pages to visit. So, I rely on having correct data. Please look into developing a policy that will allow the ripe database managers the resources to contact ISP(s) when someone reports incorrect information, so that those of us, like me, who are tired of the amount of spam they get can have correct information when they go to look for it, instead of having to make phone contact with each individual ISP who happens to be international for me. I know that the whois database at www.arin.net has the resources to make contact when someone reports incorrect data, so why not follow suit and have the same resources to do the same thing. Sincerely, Matthew Brown RIPE Database Manager wrote: To: BabyMatthew253 Subject: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: From: RIPE Database Manager Date: Fri, 24 Aug 2007 10:25:14 +0200 Dear BabyMatthew253, Thank you for your email regarding out of date contact data in the RIPE database. There may be options we could pursue to check the validity of the contact data in the objects in the RIPE Database. Where we have a direct relationship with the owners of these objects we could request that they update this information. But we do not have a mandate from the RIPE community to allocate any resources to this activity. If you feel this should have a higher priority then you may raise the issue on the Database Working Group or Antispam Working Group or Address Policy Working Group mailing lists. You can find information about the mailing lists here http://www.ripe.net/ripe/wg/index.html These are open working groups and views are welcomed from anyone who wishes to discuss relevant issues. Regards, Milena Rakin ____________________________ RIPE Database Administration. --------------------------------- Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. -------------- next part -------------- An HTML attachment was scrubbed... URL: From iljitsch at muada.com Sat Aug 25 14:15:32 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 25 Aug 2007 14:15:32 +0200 Subject: [address-policy-wg] Re: IPv6 addresses really are scarce after all In-Reply-To: <200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> References: <46C613E0.8010909@bogus.com> <46C629D2.20009@cs.utk.edu> <17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com> <46C6B5BB.5000203@cs.utk.edu> <200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> Message-ID: [CCing this to ARIN PPML and RIPE address-policy, but Reply-To: ietf at ietf.org, when replying, please pick just one list. Also, please read Thomas' entire original message at http://www1.ietf.org/mail- archive/web/ietf/current/msg47431.html ] [You may want to skip ahead to my point about the HD ratio at the end.] On 24-aug-2007, at 23:34, Thomas Narten wrote: > The fact is, the /48 boundary is _NOT_ architectural, True. However, this doesn't mean that /48 is completely arbitrary, either. /64 for subnets is based on the availability of 64-bit unique numbers in the form of MAC addresses that make it possible to have stateless autoconfiguration where a system always has the same address without the need for explicit coordination or configuration. People often attribute the fact that IPv4 addresses didn't run out in 2005 as predicted in the early 1990s to NAT, but there is another technique that is even more popular than NAT that also played in important rule: ethernet switching. Back when IPv6 was designed, it was common to have a substantial number of different subnets for different purposes to avoid having unnecessary large "collision domains". These days, you can easily throw hundreds, if not thousands of systems in a single subnet without performance penalties so most networks don't need all that many subnets. So the original goal of providing something a number of subnets that is large enough for 99.9% of all IPv6 users arguably required a /48 (65536 subnets). With 2000::/3 given out for global unicast purposes, that allows 2^45 / 48s, which should be more than enough to give all inhabitants of the planet their own /48 with a few to spare. So a /48 is both big enough for pretty much everyone, and small enough that we can give one to pretty much everyone. Last but not least, it's very useful to have a standard size, because then, if you go from one ISP to another, you're never in the situation where you need to renumber into a smaller block of address space, which is much, much harder than just replacing the first X bits of the address (where X is presumably 48). This was especially true in the presence of DNAME and bitlabels in the DNS. For those of you that don't know about this, it's rather complex and now obsolete, but around the turn of the century, this was a hot new mechanism to support easy renumbering in the DNS. (Read about it here http://www.apress.com/ book/supplementDownload.html?bID=10026&sID=3120 but don't say I didn't warn you.) So /48 was certainly "a good idea at the time". If we were doing all of this today, we could probably go a bit lower than 65536 subnets, such as 4096, but not THAT much lower. For instance, 256 subnets (/ 56) is still a very large number, so it assumes that people will be subnetting, but I'm not confident that it's enough for 99.9% of all future IPv6 users. Another issue is what we give to people who aren't going to build a network with subnets. The old recommendation was a /64 (= 1 subnet) for users who don't need to subnet. But unlike with IPv4, where end- users often get a single IP address and turn that into a subnet with NAT, with IPv6 you pretty much always need TWO subnets, although one of them can be shared. For instance, if I want to connect a bunch of computers in my home to my DSL line with IPv6, I need a /64 on my wifi network at home, but it's not really possible to use addresses from that same /64 between my ADSL modem and the DSL concentrator at the central office. As an ISP, I could set up one /64 to talk to all the DSL modems connected to a central office and then delegate a /64 to each user, but this is problematic for technical reasons (broadcasts/mulsticast vs NBMA) and control issues (which user does traffic from an address in that shared /64 come from). So if I were designing an ISP network, I would want to give at least two /64s or a /63 to every customer. In practice, it's much easier to go up a few bits and make it a /60, where I use one /64 for the SIP- customer link and the customer gets to use the other 15 subnets however they want. This way, I avoid getting support calls from people who want to have an extra DMZ subnet or different subnets for their wired and wireless networks. Again, as an ISP, I wouldn't want to think about how many subnets customers are going to use when they need more than that /60. Much easier to simply sell them a business account and give them a /48. Remember, every time a simple residential customer calls the support number, that costs an ISP the entire profit for that customer for a year. Avoiding support calls is one of the highest priorities for ISPs. > What the appropriate size of an assignment for an end site should be > is really more of an operational issue than architectural one. If a > site gets too little, and needs to get more later (maybe at the cost > of renumbering) that is an operational issue. And the idea that we can > give out "enough" address space to a site so that it doesn't have to > renumber (ever) is pretty silly. That doesn't mean it's impossible to pick sizes that are worse than others. And even though we have reverted back to simple use of the DNS with IPv6 where having the same address block size when going from ISP to ISP is less important, it's still beneficial to have as few block sizes as possible to that people don't have to go from big to small. > The RIRs adopted the "/48 to everyone" in its initial stab at IPv6 > policy back in 2002. Even at that time, there was much screaming and > gnashing of teeth from the operator community saying "wasteful", > "excessive", "really stupid", etc. The wastefulness occurred when the IPv6 address size was set to 128 bits. This means that every IPv6 packet has to carry 32 bytes of address information. Now that we've eaten that cost, there is little use in trying to _use_ fewer of those bits that we're paying for with every packet. I can see how "/48 for everyone" could be considered too much (although 35184 billion of those aren't going to be used up any time soon) but can we at least retain "/48 for everyone who asks for one"? > If I assign 4M /48's of IPv6 (one to each cable modem on my > network), according to the HD-ratio I am justified to obtain > something around a /20 of IPv6 addresses. In other words, I am > justified in getting 268M /48's even though I am only using > 4M of > them. That would be enough for me to assign at least two for > every household in the US (not just the 19M on my network). Yes, this is a problem that the current policies, including the unofficial ones (for instance that ARIN reserves a /29 when an ISP gets a /32) don't address. Suppose a large ISP that operates across the US or Europe gets that / 20. So how are they going to announce that, as a single /20? I don't think so. They're going to deaggregate. And they can easily do that, because their block is much larger than the minimum /32 block that people are presumably going to be filtering on. In the degenerative case, which we can already see in IPv4, ISPs simply announce whatever they have as the smallest possible announcement. So that ISP that needs 4 million /48s = 64 /32s but gets a /20 = 4096 /32s COULD advertise 4096 prefixes because the RIRs thought they would need to aggregate, while if the RIRs assumed that they wouldn't aggregate, they would have gotten the space in the form of a number of much smaller blocks and they would only have been able to announce 100 or so /32s. A much more appropriate policy would be to start with a certain minimum allocation, and then whenever someone comes back for more, give them a new block that is 2, 4 or 8 times as big as the previous block until a certain maximum block size is reached. For aggregation purposes, there is no benefit in having blocks larger than a /24, because by the time that a significant portion of the the IPv6 space ends up in the routing tables, having 2^24 routes won't be a problem. > The > community feedback was that LIRs were smart enough to make reasonable > assignments based on actual customer need. The trouble is that even more so than at the IETF, the RIR community as seen from the policy development process is whoever happens to show up. This means only a small part of all stakeholders provide input. > Surely, everyone will agree that > giving a /56 to home sites is more than enough space for the foresable > future! If /48 is too much for home sites then /56 is too much as well. From michael.dillon at bt.com Sun Aug 26 13:41:43 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 26 Aug 2007 12:41:43 +0100 Subject: [address-policy-wg] RE: IPv6 addresses really are scarce after all In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <46C613E0.8010909@bogus.com><46C629D2.20009@cs.utk.edu><17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com><46C6B5BB.5000203@cs.utk.edu><200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: > The definition of a small network is pretty much "single > subnet". Yes, I understand very well that the average home of > the future will have a mixed wiring. Of course, my own home > does have Ethernet and Wi-Fi. In the not so distant future, > it will have several Wi-Fi networks operating on different > frequencies, some form of power-line networking, and some > rooms may have their own high speed wireless wiring using UWB > or some similar technology. But I am pretty much convinced > that all of these will be organized as a single subnet. You are remarkably trusting. You do all your homebanking on the same subnet as your teenage children who are studying Hacking 101 in the privacy of their bedroom? And when guests come over for dinner, you have no objection to them taking their laptop to the bathroom in order to surf for child porn over your wireless network. The fact is that a lot of people will WANT subnets in the home. They will want a router/firewall that will isolate each of the children's bedrooms so that they cannot mess with your bank account or with their brother's/sister's romantic chat sessions. Many people will want all wireless access to go through a router. Many will have an in-law suite, and want to seamlessly integrate their relative's existing network via a simple router connection. And the family jewels, that Raid 5 server cluster that holds all the family photos and videos, will be behind another router/firewall. When the kids host a LAN party, the gamers will connect to the family network via a router/firewall with limited Internet access for only the necessary protocols. Subnets multiply for architectural and security reasons. Multiple subnets per home is *NOT* a waste of anything. It is an invitation to dreamers and inventors to make better network things for the home market. It is an enabler of business activity, an enabler of competition. --Michael Dillon From leo.vegoda at icann.org Sun Aug 26 20:41:12 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Sun, 26 Aug 2007 19:41:12 +0100 Subject: [address-policy-wg] Re: [anti-spam-wg] Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: In-Reply-To: <200708241908.PAA02461@Sparkle.Rodents.Montreal.QC.CA> References: <152533.59187.qm@web33106.mail.mud.yahoo.com> <200708241908.PAA02461@Sparkle.Rodents.Montreal.QC.CA> Message-ID: <89F45AD7-1601-483D-B35C-46CFA6397A4E@icann.org> Mouse, On 24 Aug 2007, at 19:55, der Mouse wrote: >> I Matthew Brown, would like to request that there be some sort of >> action, to allow the ripe database managers to contact ISP(s) when >> someone reports incorrect or outdated information. > > Good luck - and I mean that; I hope you succeed, though at this > point I > don't really expect it. I've gone a few rounds with RIPE myself on > that issue; they appear to want the authority of "owning" (and being > paid for the subdelegation of) address space without the concomitant > responsibility. When you last commented on this subject in April, I suggested that you propose a policy to tackle the issue. Perhaps you are still developing your proposal. In any case, I look forward to reading it. > Not surprising, of course; lots of people would rather > pocket the money and duck the responsibility. The real problem is > that > ICANN/IANA lets them get away with it, and I see that (that the top of > the governance pyramid does not impose responsibility on those to whom > it delegates authority - and I don't mean just RIRs; the same problem > recurs with domains) as the fundamental problem that is killing > today's > net with abusers and abuses. Sadly, you have misunderstood the policy development process. IANA does not set policy and nor does the RIPE NCC. Policy proposals come from anyone interested in developing policy, are discussed by others interested in developing policy and only become policy when there is a consensus that they are a good idea. IANA only implements global policies and only when all five RIR communities have reached consensus on a proposal and sent it to the ICANN board via the ASO. IANA and ICANN are the end and not the start of the process and the responsibility sits with us all and not with an elite group at the RIPE NCC or IANA. I'm sorry to disappoint you but if you want a policy you will have to develop and propose it before it can be agreed and implemented. Matthew Brown's mail was an excellent starting point for a discussion on what should be in a database policy. There is real value in following up on his request and developing a formal proposal that can become policy. To that end, I'd be grateful if the chairs of the appropriate WGs could coordinate and arrange agenda time for a discussion based on Matthew's request at RIPE 55. Thanks, Leo Vegoda From fw at deneb.enyo.de Mon Aug 27 08:33:55 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 27 Aug 2007 08:33:55 +0200 Subject: [address-policy-wg] Re: [anti-spam-wg] Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: In-Reply-To: <200708270256.WAA03833@Sparkle.Rodents.Montreal.QC.CA> (der Mouse's message of "Sun, 26 Aug 2007 22:36:48 -0400 (EDT)") References: <152533.59187.qm@web33106.mail.mud.yahoo.com> <200708241908.PAA02461@Sparkle.Rodents.Montreal.QC.CA> <46D02023.40909@dcrocker.net> <200708251658.MAA10393@Sparkle.Rodents.Montreal.QC.CA> <46D23236.2080404@dcrocker.net> <200708270256.WAA03833@Sparkle.Rodents.Montreal.QC.CA> Message-ID: <87fy25bi5o.fsf@mid.deneb.enyo.de> * der Mouse: > But, in any case, the carrier enforces against abuse, so the registrars > have nothing to do in that regard. What happens if the registrar gets duped and assigns ressources to a fraudulent carrier? From dhc at dcrocker.net Sat Aug 25 14:27:15 2007 From: dhc at dcrocker.net (Dave Crocker) Date: Sat, 25 Aug 2007 08:27:15 -0400 Subject: [address-policy-wg] Re: [anti-spam-wg] Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: In-Reply-To: <200708241908.PAA02461@Sparkle.Rodents.Montreal.QC.CA> References: <152533.59187.qm@web33106.mail.mud.yahoo.com> <200708241908.PAA02461@Sparkle.Rodents.Montreal.QC.CA> Message-ID: <46D02023.40909@dcrocker.net> der Mouse wrote: > The real problem is that > ICANN/IANA lets them get away with it, and I see that (that the top of > the governance pyramid does not impose responsibility on those to whom > it delegates authority ... > Any system with mismatches between authority and responsibility grows > abuses, until one of three things happens: The scope of this problem is much larger than ICANN or the Internet. We need to press for the same application of power against communication abusers by the equivalent authorities who assign telephone numbers and postal addresses. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From huitema at windows.microsoft.com Sat Aug 25 17:28:18 2007 From: huitema at windows.microsoft.com (Christian Huitema) Date: Sat, 25 Aug 2007 08:28:18 -0700 Subject: [address-policy-wg] RE: IPv6 addresses really are scarce after all In-Reply-To: References: <46C613E0.8010909@bogus.com> <46C629D2.20009@cs.utk.edu><17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com><46C6B5BB.5000203@cs.utk.edu><200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> >From an architecture point of view, I believe there are only two interesting "delegation" lengths, /48 and /64. My rationale is that there really are two kinds of networks: big and small. The definition of a small network is pretty much "single subnet". Yes, I understand very well that the average home of the future will have a mixed wiring. Of course, my own home does have Ethernet and Wi-Fi. In the not so distant future, it will have several Wi-Fi networks operating on different frequencies, some form of power-line networking, and some rooms may have their own high speed wireless wiring using UWB or some similar technology. But I am pretty much convinced that all of these will be organized as a single subnet. There are multiple trends pushing for the simple subnet. Most home networking technologies have a deeply engrained "single subnet" assumption, and will simply refuse to establish connections out of the subnet. Wireless technology is evolving towards "mesh", in which the wireless segments are bridged on demand following the vagaries of radio propagation and the movements of devices. Mesh pretty much assumes that the IP address remains unaffected by low level topology changes, which means a host will not change subnet because it just switched to a different radio. Users will keep finding it easier to deploy self forming layer 2 networks than manage the additional complexity of subnets. Of course, the technology has limit today. Subnet sizes are limited by the efficiency of the spanning tree algorithm, or by the quadratic scaling effect of multicast operation. But these limits can be pushed. The spanning tree algorithm can be replaced by something more efficient, and indeed will be as the "mesh" technology evolves. Multicast overhead can be reduced with appropriate filters. It can also be reduced if applications switch from simplistic multicast schemes to more elaborate technologies, e.g. distributed hash tables. These evolutions will be naturally driven by market demand, as homes get equipped with more and more devices, all the way to the "IPv6 light bulb". The single subnet is well served by a /64 prefix. Devices can be built in factory with unique /64 numbers. When there are privacy issues, hosts can pick random 64 bit numbers and not be really worried about collisions, at least not until there are billions of hosts in the subnet. Of course, the home may well get several /64 prefixes, for example because it is multi-homed. But there is no particular need to aggregate these prefixes. Indeed, if the goal is multi-homing, the different prefixes will come through entirely different delegation chains. If the granular level is /64, then what should the next level be? Well, as far for now, /48 makes a lot of sense. It is enough for most enterprises, allowing them to delegate /64 to each interesting subnet. I would assert that the smaller value, /56, is too small. It is not sufficient in most cases, and it also unduly increase the registration load in the registries. -- Christian Huitema From moore at cs.utk.edu Sat Aug 25 18:28:07 2007 From: moore at cs.utk.edu (Keith Moore) Date: Sat, 25 Aug 2007 12:28:07 -0400 Subject: [address-policy-wg] Re: IPv6 addresses really are scarce after all In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <46C613E0.8010909@bogus.com> <46C629D2.20009@cs.utk.edu><17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com><46C6B5BB.5000203@cs.utk.edu><200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <46D05897.5010906@cs.utk.edu> /64 is too small for a home network. It might indeed turn out that it's possible to bridge several different kinds of media on a single subnet, but it's bad planning to assume that this will be the case and overly constrain home users. In addition, part of the popularity of NAT has resulted from its allowing a consumer to simply "plug in" a new network to an existing network. But the popularity of NAT in IPv4 has also greatly limited the ability of the IPv4 network to support new applications, and increased the expense required to support others. A lot of the value add in IPv6 results from its having enough address bits that NAT is no longer necessary. But if we constrain home users to the point that they see a benefit from NATting, we will have destroyed much of the additional value of IPv6. The /48 boundary was selected to balance several competing interests - e.g. those of ISPs and registries vs. those of end-users and equipment manufacturers. There's a tremendous advantage in having nearly everyone get the same allocation size. This is not a decision that should be revisited lightly, or by a group representing only a narrow segment of those interests. > >From an architecture point of view, I believe there are only two > interesting "delegation" lengths, /48 and /64. My rationale is that > there really are two kinds of networks: big and small. > > The definition of a small network is pretty much "single subnet". Yes, I > understand very well that the average home of the future will have a > mixed wiring. Of course, my own home does have Ethernet and Wi-Fi. In > the not so distant future, it will have several Wi-Fi networks operating > on different frequencies, some form of power-line networking, and some > rooms may have their own high speed wireless wiring using UWB or some > similar technology. But I am pretty much convinced that all of these > will be organized as a single subnet. > > There are multiple trends pushing for the simple subnet. Most home > networking technologies have a deeply engrained "single subnet" > assumption, and will simply refuse to establish connections out of the > subnet. Wireless technology is evolving towards "mesh", in which the > wireless segments are bridged on demand following the vagaries of radio > propagation and the movements of devices. Mesh pretty much assumes that > the IP address remains unaffected by low level topology changes, which > means a host will not change subnet because it just switched to a > different radio. Users will keep finding it easier to deploy self > forming layer 2 networks than manage the additional complexity of > subnets. > > Of course, the technology has limit today. Subnet sizes are limited by > the efficiency of the spanning tree algorithm, or by the quadratic > scaling effect of multicast operation. But these limits can be pushed. > The spanning tree algorithm can be replaced by something more efficient, > and indeed will be as the "mesh" technology evolves. Multicast overhead > can be reduced with appropriate filters. It can also be reduced if > applications switch from simplistic multicast schemes to more elaborate > technologies, e.g. distributed hash tables. These evolutions will be > naturally driven by market demand, as homes get equipped with more and > more devices, all the way to the "IPv6 light bulb". > > The single subnet is well served by a /64 prefix. Devices can be built > in factory with unique /64 numbers. When there are privacy issues, hosts > can pick random 64 bit numbers and not be really worried about > collisions, at least not until there are billions of hosts in the > subnet. Of course, the home may well get several /64 prefixes, for > example because it is multi-homed. But there is no particular need to > aggregate these prefixes. Indeed, if the goal is multi-homing, the > different prefixes will come through entirely different delegation > chains. > > If the granular level is /64, then what should the next level be? Well, > as far for now, /48 makes a lot of sense. It is enough for most > enterprises, allowing them to delegate /64 to each interesting subnet. I > would assert that the smaller value, /56, is too small. It is not > sufficient in most cases, and it also unduly increase the registration > load in the registries. > > -- Christian Huitema > > > > _______________________________________________ > Ietf mailing list > Ietf at ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > From mouse at Rodents.Montreal.QC.CA Sat Aug 25 18:37:01 2007 From: mouse at Rodents.Montreal.QC.CA (der Mouse) Date: Sat, 25 Aug 2007 12:37:01 -0400 (EDT) Subject: [address-policy-wg] Re: [anti-spam-wg] Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: In-Reply-To: <46D02023.40909@dcrocker.net> References: <152533.59187.qm@web33106.mail.mud.yahoo.com> <200708241908.PAA02461@Sparkle.Rodents.Montreal.QC.CA> <46D02023.40909@dcrocker.net> Message-ID: <200708251658.MAA10393@Sparkle.Rodents.Montreal.QC.CA> >> The real problem is that ICANN/IANA lets them get away with it, and >> I see that (that the top of the governance pyramid does not impose >> responsibility on those to whom it delegates authority >> Any system with mismatches between authority and responsibility >> grows abuses, until one of three things happens: > The scope of this problem is much larger than ICANN or the Internet. > We need to press for the same application of power against > communication abusers by the equivalent authorities who assign > telephone numbers and postal addresses. I don't think so. In neither case is there the same kind of mismatch between authority and responsibility. In the case of telephone numbers, the delegated-to entities (the telcos) do take the responsibility - they don't ignore abuse. Filing complaints about telephone harrassment or other abuse doesn't happen that much, but that's in part because the threat is always there, and it's a real threat. Furthermore, as common carriers, the telcos are comparatively tightly regulated - I don't know the details, but at least some of that assumption of responsibility is mandated by law. In the case of postal addresses, there is no intermediate layer - the same entity that is the top-level manager is also the bottom-level manager, as if the IANA assigned individnal machines' IP addresses (which would be bizarre for the Internet, but, because the systems are so different, works for the postal system). And the responsibility is there; abuse involving postal addresses exists, but again, not much, because there are real sanctions against abusers. Use a postal address as a drop-box for a criminal enterprise and watch the heat that comes down on you for it. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From moore at cs.utk.edu Sat Aug 25 19:08:42 2007 From: moore at cs.utk.edu (Keith Moore) Date: Sat, 25 Aug 2007 13:08:42 -0400 Subject: [address-policy-wg] Re: IPv6 addresses really are scarce after all In-Reply-To: <59D5CFF02CEE1D3C96D66409@p3.JCK.COM> References: <46C613E0.8010909@bogus.com> <46C629D2.20009@cs.utk.edu> <17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com> <46C6B5BB.5000203@cs.utk.edu> <200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <46D05897.5010906@cs.utk.edu> <59D5CFF02CEE1D3C96D66409@p3.JCK.COM> Message-ID: <46D0621A.5040204@cs.utk.edu> John C Klensin wrote: > --On Saturday, 25 August, 2007 12:28 -0400 Keith Moore > wrote: > > >> /64 is too small for a home network. It might indeed turn out >> that it's possible to bridge several different kinds of media >> on a single subnet, but it's bad planning to assume that this >> will be the case and overly constrain home users. In >> addition, part of the popularity of NAT has resulted from its >> allowing a consumer to simply "plug in" a new network to an >> existing network. But the popularity of NAT in IPv4 has also >> greatly limited the ability of the IPv4 network to support new >> applications, and increased the expense required to support >> others. A lot of the value add in IPv6 results from its >> having enough address bits that NAT is no longer necessary. >> But if we constrain home users to the point that they see a >> benefit from NATting, we will have destroyed much of the >> additional value of IPv6. >> > > Keith, > > Will all due respect, even if you assume a "home" with ten > occupants, a few hundred subnets based on functions, and enough > sensor-type devices to estimate several thousand of them per > occupant and a few thousand more per room, 2**64 is still a > _lot_ of addresses. And 2**45 prefixes under 2000:/3 is a _lot_ of prefixes. But the sheer number of addresses in a subnet or prefixes available to be assigned doesn't seem to be the limiting factor in either address block assignment or subnetting of leaf networks. Every level of delegation seems to eat a couple of address bits. What bothers me about a /64 is not the scarcity of addresses, but the inability to subnet it. (and that, IMHO, was a poor design choice in IPv6, but I think it's rather late to revisit that choice, just like I think it's late to revisit /48.) > Now that number goes down significantly > --and I would agree with your assertion-- if we were still > assuming the use of hardware-assigned MAC addresses to populate > that space. But we largely are not. If we changed IPv6 so that users can have subnet prefixes longer than /64, I must have missed it. > The use of NAT to expand address space in residential use of > IPv4 has been largely to expand one or two addresses into around > 2**16. I guess I'm of the opinion that "residential" use is highly varied, and will become more varied in the future. I don't want Internet protocol design choices to constrain what people might reasonably do in a future home or home office. I also don't think it should be assumed that "residential" prefixes will exclusively be used in residences. Keith From john-ietf at jck.com Sat Aug 25 19:41:09 2007 From: john-ietf at jck.com (John C Klensin) Date: Sat, 25 Aug 2007 13:41:09 -0400 Subject: [address-policy-wg] Re: IPv6 addresses really are scarce after all In-Reply-To: <46D0621A.5040204@cs.utk.edu> References: <46C613E0.8010909@bogus.com> <46C629D2.20009@cs.utk.edu> <17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com> <46C6B5BB.5000203@cs.utk.edu> <200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <46D05897.5010906@cs.utk.edu> <59D5CFF02CEE1D3C96D66409@p3.JCK.COM> <46D0621A.5040204@cs.utk.edu> Message-ID: --On Saturday, 25 August, 2007 13:08 -0400 Keith Moore wrote: > John C Klensin wrote: >> --On Saturday, 25 August, 2007 12:28 -0400 Keith Moore >> wrote: >> >> >>> /64 is too small for a home network. It might indeed turn >>> out that it's possible to bridge several different kinds of >>> media on a single subnet, but it's bad planning to assume >... >> Will all due respect, even if you assume a "home" with ten >> occupants, a few hundred subnets based on functions, and >> enough sensor-type devices to estimate several thousand of >> them per occupant and a few thousand more per room, 2**64 is >> still a _lot_ of addresses. > And 2**45 prefixes under 2000:/3 is a _lot_ of prefixes. But > the sheer number of addresses in a subnet or prefixes > available to be assigned doesn't seem to be the limiting > factor in either address block assignment or subnetting of > leaf networks. Every level of delegation seems to eat a > couple of address bits. Yes. Of course. Again, I'm not convinced that this is a good idea, just trying to keep the discussion focused and real. > What bothers me about a /64 is not the scarcity of addresses, > but the inability to subnet it. (and that, IMHO, was a poor > design choice in IPv6, but I think it's rather late to revisit > that choice, just like I think it's late to revisit /48.) This gets to one of the issues I _am_ concerned about. While I didn't call it out explicitly in my response to Thomas, I believe that, if the RIRs start saying "give out /64s unless someone can prove to your satisfaction that they need a lot of subnets" to ISPs, we have ample evidence that some, perhaps many, ISPs serving the residential market will construe "prove to our satisfaction" as "pay us a lot of extra money". If that happens, our experience with IPv4 and NATs suggests to me that it will be a _very_ short period of time before devices hit the consumer market that either do subnetting on longer-than-/64 prefixes, are set up to handle some other model of address pools, or NAT (I'd predict all three and would find the middle one interesting) along with patches to stacks that support them as needed. Since we probably won't revisit the /64 subnetting choice, those patches will be made independent of any standard or IETF advice which suggests that there may be interoperability problems if there is any opportunity for them. And _that_ is bad news. It is also news that reinforces my response to Thomas: there really are architectural issues in this sort of decision and no one I know of has chartered the RIRs to make those types of architectural decisions. john From john-ietf at jck.com Sat Aug 25 18:47:52 2007 From: john-ietf at jck.com (John C Klensin) Date: Sat, 25 Aug 2007 12:47:52 -0400 Subject: [address-policy-wg] Re: IPv6 addresses really are scarce after all In-Reply-To: <46D05897.5010906@cs.utk.edu> References: <46C613E0.8010909@bogus.com> <46C629D2.20009@cs.utk.edu> <17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com> <46C6B5BB.5000203@cs.utk.edu> <200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <46D05897.5010906@cs.utk.edu> Message-ID: <59D5CFF02CEE1D3C96D66409@p3.JCK.COM> --On Saturday, 25 August, 2007 12:28 -0400 Keith Moore wrote: > /64 is too small for a home network. It might indeed turn out > that it's possible to bridge several different kinds of media > on a single subnet, but it's bad planning to assume that this > will be the case and overly constrain home users. In > addition, part of the popularity of NAT has resulted from its > allowing a consumer to simply "plug in" a new network to an > existing network. But the popularity of NAT in IPv4 has also > greatly limited the ability of the IPv4 network to support new > applications, and increased the expense required to support > others. A lot of the value add in IPv6 results from its > having enough address bits that NAT is no longer necessary. > But if we constrain home users to the point that they see a > benefit from NATting, we will have destroyed much of the > additional value of IPv6. Keith, Will all due respect, even if you assume a "home" with ten occupants, a few hundred subnets based on functions, and enough sensor-type devices to estimate several thousand of them per occupant and a few thousand more per room, 2**64 is still a _lot_ of addresses. Now that number goes down significantly --and I would agree with your assertion-- if we were still assuming the use of hardware-assigned MAC addresses to populate that space. But we largely are not. The use of NAT to expand address space in residential use of IPv4 has been largely to expand one or two addresses into around 2**16. Even those of us who run several subnets with different security policies don't often use that much space up. While we clearly could in the future, and I don't like NATs much more than you do, a /64 gives 48 bits of headroom -- over a dozen decimal orders of magnitude if my mental arithmetic is correct -- above any regularly-demonstrated current need. That is a lot of headroom, enough that the assertions above are not obviously true, at least without a lot more rationale. That doesn't mean I'm convinced that shifting the boundary is either necessary or desirable. But I don't think hyperbole helps the discussion. john From moore at cs.utk.edu Sat Aug 25 19:54:01 2007 From: moore at cs.utk.edu (Keith Moore) Date: Sat, 25 Aug 2007 13:54:01 -0400 Subject: [address-policy-wg] Re: IPv6 addresses really are scarce after all In-Reply-To: References: <46C613E0.8010909@bogus.com> <46C629D2.20009@cs.utk.edu> <17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com> <46C6B5BB.5000203@cs.utk.edu> <200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <46D05897.5010906@cs.utk.edu> <59D5CFF02CEE1D3C96D66409@p3.JCK.COM> <46D0621A.5040204@cs.utk.edu> Message-ID: <46D06CB9.8010902@cs.utk.edu> John, It seems like we are on the same page. I'm very concerned about the potential of this change to snowball in to lots of other changes that would be undesirable, or at least highly disruptive. The /48 choice is only one of several interlocking choices that were carefully-crafted compromises, and if we change /48 then we risk revisiting all of those other choices in order to maintain that sense of balance - or worse, losing that balance. Keith > --On Saturday, 25 August, 2007 13:08 -0400 Keith Moore > wrote: > > >> John C Klensin wrote: >> >>> --On Saturday, 25 August, 2007 12:28 -0400 Keith Moore >>> wrote: >>> >>> >>> >>>> /64 is too small for a home network. It might indeed turn >>>> out that it's possible to bridge several different kinds of >>>> media on a single subnet, but it's bad planning to assume >>>> >> ... >> >>> Will all due respect, even if you assume a "home" with ten >>> occupants, a few hundred subnets based on functions, and >>> enough sensor-type devices to estimate several thousand of >>> them per occupant and a few thousand more per room, 2**64 is >>> still a _lot_ of addresses. >>> > > >> And 2**45 prefixes under 2000:/3 is a _lot_ of prefixes. But >> the sheer number of addresses in a subnet or prefixes >> available to be assigned doesn't seem to be the limiting >> factor in either address block assignment or subnetting of >> leaf networks. Every level of delegation seems to eat a >> couple of address bits. >> > > Yes. Of course. Again, I'm not convinced that this is a good > idea, just trying to keep the discussion focused and real. > > >> What bothers me about a /64 is not the scarcity of addresses, >> but the inability to subnet it. (and that, IMHO, was a poor >> design choice in IPv6, but I think it's rather late to revisit >> that choice, just like I think it's late to revisit /48.) >> > > This gets to one of the issues I _am_ concerned about. While I > didn't call it out explicitly in my response to Thomas, I > believe that, if the RIRs start saying "give out /64s unless > someone can prove to your satisfaction that they need a lot of > subnets" to ISPs, we have ample evidence that some, perhaps > many, ISPs serving the residential market will construe "prove > to our satisfaction" as "pay us a lot of extra money". If that > happens, our experience with IPv4 and NATs suggests to me that > it will be a _very_ short period of time before devices hit the > consumer market that either do subnetting on longer-than-/64 > prefixes, are set up to handle some other model of address > pools, or NAT (I'd predict all three and would find the middle > one interesting) along with patches to stacks that support them > as needed. > > Since we probably won't revisit the /64 subnetting choice, those > patches will be made independent of any standard or IETF advice > which suggests that there may be interoperability problems if > there is any opportunity for them. > > And _that_ is bad news. It is also news that reinforces my > response to Thomas: there really are architectural issues in > this sort of decision and no one I know of has chartered the > RIRs to make those types of architectural decisions. > > john > > > From john-ietf at jck.com Sun Aug 26 15:07:59 2007 From: john-ietf at jck.com (John C Klensin) Date: Sun, 26 Aug 2007 09:07:59 -0400 Subject: [address-policy-wg] RE: IPv6 addresses really are scarce after all In-Reply-To: References: <46C613E0.8010909@bogus.com><46C629D2.20009@cs.utk.edu> <17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com> <46C6B5BB.5000203@cs.utk.edu> <200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: --On Sunday, 26 August, 2007 12:41 +0100 michael.dillon at bt.com wrote: >> The definition of a small network is pretty much "single >> subnet". Yes, I understand very well that the average home of >> the future will have a mixed wiring. Of course, my own home >> does have Ethernet and Wi-Fi. In the not so distant future, >> it will have several Wi-Fi networks operating on different >... > You are remarkably trusting. You do all your homebanking on > the same subnet as your teenage children who are studying > Hacking 101 in the privacy of their bedroom? And when guests > come over for dinner, you have no objection to them taking > their laptop to the bathroom in order to surf for child porn > over your wireless network. > > The fact is that a lot of people will WANT subnets in the > home. They will want a router/firewall that will isolate each > of the children's bedrooms so that they cannot mess with your > bank account or with their brother's/sister's romantic chat > sessions. Many people will want all wireless access to go > through a router. Many will have an in-law suite, and want to > seamlessly integrate their relative's existing network via a > simple router connection. And the family jewels, that Raid 5 > server cluster that holds all the family photos and videos, > will be behind another router/firewall. When the kids host a > LAN party, the gamers will connect to the family network via a > router/firewall with limited Internet access for only the > necessary protocols. Subnets multiply for architectural and > security reasons. >... Michael, Assume we agree on the needed functionality. It is hard to disagree and many of us have seen the need to isolate some people and apparatus from others, and to assign different capability to them, for many years. That still leaves room to ask several questions. I believe those questions need to be asked, and the relevant technical work done. And I think one needs to do that work and then adjust address policy to match, not change address policy without making corresponding technical/ protocol changes. Examples: (1) Unless it was changed when I wasn't looking, there is a rule in the IPv6 architecture that says that one cannot subnet on a prefix longer than a /64. That rule appears to be someone hostile to efficient use of address space at the "small network with subnets" side of things. Has that rule outlived its usefulness? If so, how do we go about changing it before IPv6 is sufficiently widely deployed to make it even more difficult and disruptive to do so? (2) The many examples you give seem to be to be associated with different domains of authorization and privilege for different groups of people and functions within the home. My impression of the experience and literature in the field is that almost every time someone tries to create such a typology, they conclude that these are much better modeled as sometimes-overlapping domains rather than as discrete partitions. The subnet-based model you posit requires that people or devices switch addresses when they change functions or activities. Up to a point, one can do it that way (and many of us have, even with IPv4). But I suggest that trying to use subnetting as the primary and only tool to accomplish those functions is architecturally just wrong, _especially_ for the types of authorization-limitation cases you list. Wouldn't you rather have mechanisms within your home network, possibly bound to your switches, that could associate authorization property lists with each user or device and then enforce those properties? Kerberos (a very old protocol by now) took the first steps in that direction by associating access to server-type functions with authorization properties rather than physical connectivity. Perhaps it is time to extend a model of that sort to access to network resources --such as routing to other addresses both inside and outside of the home network-- and to think through how it could be scaled to effective and cost-efficient operation in a home-sized network. (3) It may be worth remembering that subnetting was introduced into the IPv4 architecture partially to deal with routing isolation and efficiency for LANs based on 10Base10 and 10Base2 Ethernet --backbone-style networks at the LAN, or groups of LANs, level. While some lazy few of us still have some 10Base2 in our LANs, the move toward LAN segments based on twisted-pair cabling and fanout switch arrangements creates opportunities we didn't have when "segment" was a physical property rather than a logical one. Is it time to review and update the network architecture to reflect new opportunities in the physical one, rather than assuming that authorization is necessarily reflected in subnets? (4) Which IETF WG is working on these things? :-( john From arnt at gulbrandsen.priv.no Sun Aug 26 15:53:51 2007 From: arnt at gulbrandsen.priv.no (Arnt Gulbrandsen) Date: Sun, 26 Aug 2007 15:53:51 +0200 Subject: [address-policy-wg] Re: IPv6 addresses really are scarce after all In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <46C613E0.8010909@bogus.com> <46C629D2.20009@cs.utk.edu> <17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com> <46C6B5BB.5000203@cs.utk.edu> <200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: Christian Huitema writes: > The definition of a small network is pretty much "single subnet". Yes, > I understand very well that the average home of the future will have > a mixed wiring. Of course, my own home does have Ethernet and Wi-Fi. > In the not so distant future, it will have several Wi-Fi networks > operating on different frequencies, some form of power-line > networking, and some rooms may have their own high speed wireless > wiring using UWB or some similar technology. But I am pretty much > convinced that all of these will be organized as a single subnet. You mean that the faster actual subnets will not be subnets in the IETF sense, right? If a number of devices have some extremely fast special network, and a bridge or router to connect them to the rest of the world, presumably they need the extra bandwidth: If their traffic were to leak onto the slower net, it would be more or less unusable. But there are several ways in which the fast devices can leak traffic, often involving broastcast or multicast. (I have some neat audio boxes that multicast to group "all-devices-from-manufacturer-x", very nice, but I'm glad my backbone isn't 802.11.) Either the IETF subnet has to be usable to describe these actual subnets (ie. people get more than a /64 automatically so it's the common case and random consumerboxes are built for it) or there'll eventually be some new subber-than-subnet concept so devices can broadcast or multicast traffic onto their fast subber-than-subnet without overwhelming the slow parts of the subnet. Arnt From huitema at windows.microsoft.com Sun Aug 26 17:16:28 2007 From: huitema at windows.microsoft.com (Christian Huitema) Date: Sun, 26 Aug 2007 08:16:28 -0700 Subject: [address-policy-wg] RE: IPv6 addresses really are scarce after all In-Reply-To: References: <46C613E0.8010909@bogus.com><46C629D2.20009@cs.utk.edu><17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com><46C6B5BB.5000203@cs.utk.edu><200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com><70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064058BF22B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> > Assume we agree on the needed functionality. It is hard to > disagree and many of us have seen the need to isolate some > people and apparatus from others, and to assign different > capability to them, for many years. People want security, and the threats that Michael mention are real: children spying on the parent's traffic, guests abusing the access to do something illegal on the Internet. But subnets are not a particularly efficient way of solving these threats. Take the issue of guests abusing the privilege and engaging in illegal action. The concrete risk is that men in black will knock at your door and ask about said actions. Picture yourself arguing that "it obviously wasn't me, because the packets come from the network that I provide to my guests". The men in black will not be impressed, since you obviously have access to all the networks in your house. Your only defense will be to rat a specific guest, supposing of course that you are so enclined. Subnet or no subnet will no help you do that. Access control and logs will help, but these are not tied to subnets. Consider then the attacks between computers on the same network. Michael mentioned traffic snooping. But modern Wi-Fi network are protected against that already. They negotiate different per-session keys. Even in promiscuous mode, the Wi-Fi card does not see the unicast traffic of the other stations in the network. In home networks, the key is derived from an initial 4-ways handshake, secured by a pass-phrase. Most deployments use a single pass-phrase today, so teenagers could indeed develop tools to crack the exchange. But nothing prevents using different pass-phrases for different group of users. The other risk are the active attacks between connected computers. However, as John pointed out, there is lot of demand for connectivity between computers in the home. Many people have tried to engineer network topologies that follow organization or authorization boundaries, but the mostly that makes your network expensive to run without really solving the issues. Also, ultimately, all forms of topology based control rely on the security of the home router. Do you really believe that a teenager who is clever enough to hack into Wi-Fi access protections will not also be able to hack into the home router? If we want actual protection, it is probably much easier to use end to end security. And in your own house, you might consider forms of social control, as in "OK, you hacked my computer, give me the keys of your car..." Frankly, I don't see users managing subnets any time soon. -- Christian Huitema From moore at cs.utk.edu Sun Aug 26 20:32:24 2007 From: moore at cs.utk.edu (Keith Moore) Date: Sun, 26 Aug 2007 14:32:24 -0400 Subject: [address-policy-wg] Re: IPv6 addresses really are scarce after all In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064058BF22B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <46C613E0.8010909@bogus.com><46C629D2.20009@cs.utk.edu><17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com><46C6B5BB.5000203@cs.utk.edu><200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com><70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF22B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <46D1C738.7070406@cs.utk.edu> subnets have proven to a useful tool in the past, and may prove so again in the future, even if the reasons for future use are different than those for past and present use. I don't see why we should constrain the network architecture to deny use of this tool to ordinary users. Keith >> Assume we agree on the needed functionality. It is hard to >> disagree and many of us have seen the need to isolate some >> people and apparatus from others, and to assign different >> capability to them, for many years. >> > > People want security, and the threats that Michael mention are real: > children spying on the parent's traffic, guests abusing the access to do > something illegal on the Internet. But subnets are not a particularly > efficient way of solving these threats. > > Take the issue of guests abusing the privilege and engaging in illegal > action. The concrete risk is that men in black will knock at your door > and ask about said actions. Picture yourself arguing that "it obviously > wasn't me, because the packets come from the network that I provide to > my guests". The men in black will not be impressed, since you obviously > have access to all the networks in your house. Your only defense will be > to rat a specific guest, supposing of course that you are so enclined. > Subnet or no subnet will no help you do that. Access control and logs > will help, but these are not tied to subnets. > > Consider then the attacks between computers on the same network. Michael > mentioned traffic snooping. But modern Wi-Fi network are protected > against that already. They negotiate different per-session keys. Even in > promiscuous mode, the Wi-Fi card does not see the unicast traffic of the > other stations in the network. In home networks, the key is derived from > an initial 4-ways handshake, secured by a pass-phrase. Most deployments > use a single pass-phrase today, so teenagers could indeed develop tools > to crack the exchange. But nothing prevents using different pass-phrases > for different group of users. > > The other risk are the active attacks between connected computers. > However, as John pointed out, there is lot of demand for connectivity > between computers in the home. Many people have tried to engineer > network topologies that follow organization or authorization boundaries, > but the mostly that makes your network expensive to run without really > solving the issues. > > Also, ultimately, all forms of topology based control rely on the > security of the home router. Do you really believe that a teenager who > is clever enough to hack into Wi-Fi access protections will not also be > able to hack into the home router? > > If we want actual protection, it is probably much easier to use end to > end security. And in your own house, you might consider forms of social > control, as in "OK, you hacked my computer, give me the keys of your > car..." > > Frankly, I don't see users managing subnets any time soon. > > -- Christian Huitema > > > > > > > > > _______________________________________________ > Ietf mailing list > Ietf at ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > From mouse at Rodents.Montreal.QC.CA Sun Aug 26 23:59:14 2007 From: mouse at Rodents.Montreal.QC.CA (der Mouse) Date: Sun, 26 Aug 2007 17:59:14 -0400 (EDT) Subject: [address-policy-wg] Re: [anti-spam-wg] Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: In-Reply-To: <89F45AD7-1601-483D-B35C-46CFA6397A4E@icann.org> References: <152533.59187.qm@web33106.mail.mud.yahoo.com> <200708241908.PAA02461@Sparkle.Rodents.Montreal.QC.CA> <89F45AD7-1601-483D-B35C-46CFA6397A4E@icann.org> Message-ID: <200708262225.SAA02234@Sparkle.Rodents.Montreal.QC.CA> >>> I Matthew Brown, would like to request that there be some sort of >>> action, to allow the ripe database managers to contact ISP(s) when >>> someone reports incorrect or outdated information. >> Good luck - and I mean that; I hope you succeed, though at this >> point I don't really expect it. I've gone a few rounds with RIPE >> myself on that issue; they appear to want the authority of "owning" >> (and being paid for the subdelegation of) address space without the >> concomitant responsibility. > When you last commented on this subject in April, I suggested that > you propose a policy to tackle the issue. Perhaps you are still > developing your proposal. In any case, I look forward to reading it. ["You" and related words here refer to ICANN/IANA, not any individual except insofar as that individual is wearing an ICANN/IANA hat.] Why is it *my* duty to fix *your* screwup? The current, broken, system was put in place asking (or even telling) me; why is it up to me to fix its problems? Because I'm the person pointing them out!? *You* are being paid to run the Internet; go do your job! Asking me to make up for your failings - without pay, I note - is shirking your duty. In any case, my "proposal" is that ICANN impose responsibility along with authority: as a simple example (restricted just to address space assignment), it could establish an AUP that RIRs would have to comply with to keep their assigned space - and then enforce it (this step is not optional, or the fix won't actually fix anything). What would this AUP say? I don't know, offhand; I am not a policy author. I recall seeing RIPE say their sub-assignees have to conform to an AUP of some sort, at least de-jure; if that memory is accurate, that policy might well be a reasonable place to start. >> The real problem is that ICANN/IANA lets them get away with it, and >> I see that (that the top of the governance pyramid does not impose >> responsibility on those to whom it delegates authority - and I don't >> mean just RIRs; the same problem recurs with domains) as the >> fundamental problem that is killing today's net with abusers and >> abuses. > Sadly, you have misunderstood the policy development process. IANA > does not set policy and nor does the RIPE NCC. IANA (or perhaps ICANN; I'm not entirely clear where the boundaries between them lie) *has* to. They have been given the authority; they have to take the responsibility - or we have the kind of mismatch I wrote about in the quote above. When they delegate authority, such as by assigning address space to RIRs, they have to impose corresponding responsibility, or, again, we have a mismatch. If they - IANA/ICANN - accept the authority but not the responsibility, as you seem to be saying they have, they system will break. Is breaking, in the case of the Internet, and will break worse and worse until the mismatch is fixed. Sitting on their thumbs waiting for someone else to solve the problem, which is what I see them doing, is *not* a responsible thing for ICANN/IANA to do here. If this is being done because that's what the procedures in place call for, then the procedures themselves are broken and need to be fixed. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From pbaker at verisign.com Mon Aug 27 00:49:46 2007 From: pbaker at verisign.com (Hallam-Baker, Phillip) Date: Sun, 26 Aug 2007 15:49:46 -0700 Subject: [address-policy-wg] RE: IPv6 addresses really are scarce after all In-Reply-To: Message-ID: <198A730C2044DE4A96749D13E167AD37013A01AC@MOU1WNEXMB04.vcorp.ad.vrsn.com> > From: John C Klensin [mailto:john-ietf at jck.com] > Examples: > > (1) Unless it was changed when I wasn't looking, there is a > rule in the IPv6 architecture that says that one cannot > subnet on a prefix longer than a /64. That rule appears to > be someone hostile to efficient use of address space at the > "small network with subnets" side of things. Has that rule > outlived its usefulness? If so, how do we go about changing > it before IPv6 is sufficiently widely deployed to make it > even more difficult and disruptive to do so? Perhaps you could define the term subnet? I don't see how such an architectural limitation can be enforced. There is no way that the IETF can prevent an ISP issuing IPv6 customers a /128 if they choose. The situation we have is similar to that which Octavian found himself in the aftermath of the assasination of Ceasar, he had authority but not power. It is not a hopeless position, I have often found authority to provide more real influence than formal decision making power. But understanding the difference is critical if there is to be effective influence. > But I suggest that trying to use subnetting as the primary > and only tool to accomplish those functions is > architecturally just wrong, _especially_ for the types of > authorization-limitation cases you list. Wouldn't you rather > have mechanisms within your home network, possibly bound to > your switches, that could associate authorization property > lists with each user or device > and then enforce those properties? I agree, encoding authorization data into the network address is not a good strategy, another structural oddity is that we continue to view the Internet as a network of hosts rather than a network of services. > (3) It may be worth remembering that subnetting was > introduced into the IPv4 architecture partially to deal with > routing isolation and efficiency for LANs based on 10Base10 > and 10Base2 Ethernet --backbone-style networks at the LAN, or > groups of LANs, level. While some lazy few of us still have > some 10Base2 in our LANs, the move toward LAN segments based > on twisted-pair cabling and fanout switch arrangements > creates opportunities we didn't have when "segment" was a > physical property rather than a logical one. Is it time to > review and update the network architecture to reflect new > opportunities in the physical one, rather than assuming that > authorization is necessarily reflected in subnets? Again, I agree, hence my request for a definition of subnet. It is a term that has been thrown around with much abandon but looks very likely to mean different things to different people at this point. From moore at cs.utk.edu Mon Aug 27 01:17:38 2007 From: moore at cs.utk.edu (Keith Moore) Date: Sun, 26 Aug 2007 19:17:38 -0400 Subject: [address-policy-wg] Re: IPv6 addresses really are scarce after all In-Reply-To: <198A730C2044DE4A96749D13E167AD37013A01AC@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD37013A01AC@MOU1WNEXMB04.vcorp.ad.vrsn.com> Message-ID: <46D20A12.2040008@cs.utk.edu> >> (1) Unless it was changed when I wasn't looking, there is a >> rule in the IPv6 architecture that says that one cannot >> subnet on a prefix longer than a /64. That rule appears to >> be someone hostile to efficient use of address space at the >> "small network with subnets" side of things. Has that rule >> outlived its usefulness? If so, how do we go about changing >> it before IPv6 is sufficiently widely deployed to make it >> even more difficult and disruptive to do so? >> > > Perhaps you could define the term subnet? > > I don't see how such an architectural limitation can be enforced. There is no way that the IETF can prevent an ISP issuing IPv6 customers a /128 if they choose. > Perhaps not, but such an ISP might incur significant support costs. For instance, an ISP that assigned a /128 might get a complaint every time a customer tried to change his computer or network card. That, and several IPv6 protocols were designed with the assumption that /64 was the maximum length of a prefix to be assigned to a net. There aren't any more bits in those protocols to support a longer subnet mask. Realistically if an ISP wanted to restrict its customers to a maximum of one IPv6 host there are probably less disruptive (therefore cheaper) ways to do this than to try to make the customer's network prefix be a /128. And then the customers would just NAT, and the ISP's effort would be wasted. So there's little benefit to the ISP in doing this, particularly if they can get enough addresses from their upstream providers or registries. More broadly, IETF can't prevent an ISP from offering a service that claims to be Internet but doesn't follow the specified protocols. But since those protocols are the agreements by which interoperability is obtained, an ISP that violates those protocols risks alienating its customers when their applications do not work. In practice, ISPs do this routinely (e.g. ISPs that provide DNS servers that lie about the RRs for a given zone), and they also get pushback for doing so. Customers are slow to learn but some of them do change ISPs when they find out that they're being screwed. As you point out, we have very little power to prevent ISPs (or equipment vendors, or OS vendors, or users) from doing harm. But that doesn't mean we should say that it's okay for them to do things that we have every reason to believe will do harm. > I agree, encoding authorization data into the network address is not a good strategy, another structural oddity is that we continue to view the Internet as a network of hosts rather than a network of services. > Well, at one level, it is a network of hosts. The network of services is built on top of the network of hosts. It's just that the boundary between the two is fuzzy. Keith From dhc at dcrocker.net Mon Aug 27 04:08:54 2007 From: dhc at dcrocker.net (Dave Crocker) Date: Sun, 26 Aug 2007 22:08:54 -0400 Subject: [address-policy-wg] Re: [anti-spam-wg] Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: In-Reply-To: <200708251658.MAA10393@Sparkle.Rodents.Montreal.QC.CA> References: <152533.59187.qm@web33106.mail.mud.yahoo.com> <200708241908.PAA02461@Sparkle.Rodents.Montreal.QC.CA> <46D02023.40909@dcrocker.net> <200708251658.MAA10393@Sparkle.Rodents.Montreal.QC.CA> Message-ID: <46D23236.2080404@dcrocker.net> der Mouse wrote: >> The scope of this problem is much larger than ICANN or the Internet. >> We need to press for the same application of power against >> communication abusers by the equivalent authorities who assign >> telephone numbers and postal addresses. > > I don't think so. In neither case is there the same kind of mismatch > between authority and responsibility. > > In the case of telephone numbers, the delegated-to entities (the > telcos) do take the responsibility - they don't ignore abuse. Filing They have specific statutory rights and obligations as carriers, not as registrars. (Note, for example, that number portability now nicely separates the registration function from carriage.) A domain registrar is not the carrier of content. > In the case of postal addresses, there is no intermediate layer - the > same entity that is the top-level manager is also the bottom-level > manager Actually, that's not correct. The post office assigns postal units, typically aligned with city/town boundaries and subdivided by postal code/zip code. But they do not define city/town boundaries and they do not assign street names or numbers. Again, carriage is distinguished from registration. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mouse at Rodents.Montreal.QC.CA Mon Aug 27 04:36:48 2007 From: mouse at Rodents.Montreal.QC.CA (der Mouse) Date: Sun, 26 Aug 2007 22:36:48 -0400 (EDT) Subject: [address-policy-wg] Re: [anti-spam-wg] Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: In-Reply-To: <46D23236.2080404@dcrocker.net> References: <152533.59187.qm@web33106.mail.mud.yahoo.com> <200708241908.PAA02461@Sparkle.Rodents.Montreal.QC.CA> <46D02023.40909@dcrocker.net> <200708251658.MAA10393@Sparkle.Rodents.Montreal.QC.CA> <46D23236.2080404@dcrocker.net> Message-ID: <200708270256.WAA03833@Sparkle.Rodents.Montreal.QC.CA> >>> The scope of this problem is much larger than ICANN or the >>> Internet. We need to press for the same application of power >>> against communication abusers by the equivalent authorities who >>> assign telephone numbers and postal addresses. >> In the case of telephone numbers, the delegated-to entities (the >> telcos) do take the responsibility - they don't ignore abuse. > They have specific statutory rights and obligations as carriers, not > as registrars. (Note, for example, that number portability now > nicely separates the registration function from carriage.) Not really; porting a number - where possible; I assume you're talking NANPA here - transfers the registration as well as the carriage. In particular, consider porting it a second time; the original carrier, the one whom you are arguing is still registrar, is out of the loop. >> In the case of postal addresses, [...] > Again, carriage is distinguished from registration. I suspect it depends on jurisdiction. But, in any case, the carrier enforces against abuse, so the registrars have nothing to do in that regard. Since there is a monopoly postal carrier, that situation is not very analogous to the Internet. In the telephone case, it depends. In some places, there is a monopoly carrier, and the above remarks apply. In places where there isn't, like the USA, a carrier that did not deal with abusers on its service would need to be slapped down. As far as I know, all such places also have something like the USA's common-carrier status, with legal oversight dealing with rogue actors in the telco space. If there is a jursidction with no monopoly carrier and no government oversight, then, yes, it probably needs attention from someone, quite possibly the number registrar(s). If the above assumptions fail, there will be similar problems in the telephone and postal realms, yes. It's possible there are places now (perhaps even the USA) where the stage is set for problems, and they just haven't got big enough yet to be very visible. If abuses start growing in the telephone or postal worlds, it would be worth taking a good look around for a mismatch between authority and responsibility. In any case, none of that is really very relevant to the Internet. Whether bad things are happening in place B doesn't mean that they're not in place A, nor that place A's bad things don't need attention. The only way this is relevant is if there is a long-standing mismatch between authority and responsibility somewhere that hasn't been abused, which if so is a point against my theory; I'm not convinced either telco or post is an example. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From leo.vegoda at icann.org Mon Aug 27 10:25:45 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 27 Aug 2007 10:25:45 +0200 Subject: [address-policy-wg] Re: [anti-spam-wg] Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: In-Reply-To: <200708262225.SAA02234@Sparkle.Rodents.Montreal.QC.CA> References: <152533.59187.qm@web33106.mail.mud.yahoo.com> <200708241908.PAA02461@Sparkle.Rodents.Montreal.QC.CA> <89F45AD7-1601-483D-B35C-46CFA6397A4E@icann.org> <200708262225.SAA02234@Sparkle.Rodents.Montreal.QC.CA> Message-ID: <189D258D-F144-46EA-BF55-26EDEA231E7C@icann.org> On 26 Aug 2007, at 23:59, der Mouse wrote: [...] > In any case, my "proposal" is that ICANN impose responsibility along > with authority: as a simple example (restricted just to address space > assignment), it could establish an AUP that RIRs would have to comply > with to keep their assigned space - and then enforce it (this step is > not optional, or the fix won't actually fix anything). Are you suggesting that ICANN should assume the regulatory role that currently sits with sovereign nations? [...] >> Sadly, you have misunderstood the policy development process. IANA >> does not set policy and nor does the RIPE NCC. > > IANA (or perhaps ICANN; I'm not entirely clear where the boundaries > between them lie) *has* to. They have been given the authority; they > have to take the responsibility - or we have the kind of mismatch I > wrote about in the quote above. When they delegate authority, such as > by assigning address space to RIRs, they have to impose corresponding > responsibility, or, again, we have a mismatch. > > If they - IANA/ICANN - accept the authority but not the > responsibility, > as you seem to be saying they have, they system will break. Is > breaking, in the case of the Internet, and will break worse and worse > until the mismatch is fixed. > > Sitting on their thumbs waiting for someone else to solve the problem, > which is what I see them doing, is *not* a responsible thing for > ICANN/IANA to do here. If this is being done because that's what the > procedures in place call for, then the procedures themselves are > broken > and need to be fixed. Please let me know where I can get a copy of the document authorising IANA to regulate in this area. A top down approach is unlikely to work without effective enforcement mechanisms. As you'd like to see an AUP it might be helpful to give us a general idea of what you'd like to see in it and what you'd like to see done when it is not followed. At the moment I'm not sure what you want and that makes it difficult to draft a policy proposal. Regards, Leo Vegoda From filiz at ripe.net Mon Aug 27 15:53:14 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 27 Aug 2007 15:53:14 +0200 Subject: [address-policy-wg] 2007-02 Policy Proposal Withdrawn (Change in IP Assignments for Anycasting DNS Policy) Message-ID: <20070827135314.C42302F583@herring.ripe.net> PDP Number: 2007-02 Change in IP Assignments for Anycasting DNS Policy Dear Colleagues, Policy proposal 2007-02, "Change in IP Assignments for Anycasting DNS Policy" has been withdrawn. The proposer decided that there was insufficient support for the proposal. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/archive/ Regards Filiz Yilmaz RIPE NCC Policy Development Officer From arnt at gulbrandsen.priv.no Mon Aug 27 11:10:53 2007 From: arnt at gulbrandsen.priv.no (Arnt Gulbrandsen) Date: Mon, 27 Aug 2007 11:10:53 +0200 Subject: [address-policy-wg] Re: IPv6 addresses really are scarce after all In-Reply-To: <198A730C2044DE4A96749D13E167AD37013A01AC@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD37013A01AC@MOU1WNEXMB04.vcorp.ad.vrsn.com> Message-ID: Hallam-Baker, Phillip writes: > I don't see how such an architectural limitation can be enforced. > There is no way that the IETF can prevent an ISP issuing IPv6 > customers a /128 if they choose. Not directly, but there's the indirect route: a) IETF designs IPv6 autoconfiguration. b) Linksys, D-Link, Netgear and friends make boxes that support autoconfiguration. c) ISP hand out /128s. d) Autoconfiguration doesn't work well. e) Customers call ISP support. f) ISP loses $$$. g) ISP starts issuing /48s instead. I don't know the first thing about how IPv6 autoconfiguration works. It worked very well in my previous office. Will it work better when the router has a /48 at hand than a /64 or /128? Arnt From peter at peter-dambier.de Mon Aug 27 13:22:16 2007 From: peter at peter-dambier.de (Peter Dambier) Date: Mon, 27 Aug 2007 13:22:16 +0200 Subject: [address-policy-wg] Re: IPv6 addresses really are scarce after all In-Reply-To: References: <198A730C2044DE4A96749D13E167AD37013A01AC@MOU1WNEXMB04.vcorp.ad.vrsn.com> Message-ID: <46D2B3E8.1010808@peter-dambier.de> Arnt Gulbrandsen wrote: > Hallam-Baker, Phillip writes: > >> I don't see how such an architectural limitation can be enforced. >> There is no way that the IETF can prevent an ISP issuing IPv6 >> customers a /128 if they choose. > > > Not directly, but there's the indirect route: a) IETF designs IPv6 > autoconfiguration. b) Linksys, D-Link, Netgear and friends make boxes > that support autoconfiguration. c) ISP hand out /128s. d) > Autoconfiguration doesn't work well. e) Customers call ISP support. f) > ISP loses $$$. g) ISP starts issuing /48s instead. > > I don't know the first thing about how IPv6 autoconfiguration works. It > worked very well in my previous office. Will it work better when the > router has a /48 at hand than a /64 or /128? > > Arnt > > _______________________________________________ > Ietf mailing list > Ietf at ietf.org > https://www1.ietf.org/mailman/listinfo/ietf I remember working with my own little lan: three Site Local and one tunnel networks. radvd or SuSE 7.1 and SuSE 8.2 did expect /64 The tunnel would either give me a /64 without local router or a /48 if I had a local router. Today Site Local is given up. So I changed to 192.168... addresses with 6to4 addressing. RFC 2462 says we normally have EUI-64 addressing that is either a funtion of the MAC address or a random number. With EUI-64 (64 bits) the prefix must be /64 for an autoconfigured network segment. The tunnel used to be a /124 network segment overlapping my /64 with ..0 the net, ..1 the other end of the tunnel, ..2 me and ..3 broadcast. Theoretically ..2 would have been a router for anything in my /64, but that never worked. So practically I ended up with a /128 If you have a LAN with servers you need predictable addresses for your servers. Renumbering is not an option. Site Local does not exist any longer. 182.168.. with 6to4 addressing is the only way I see. But that means - no autoconfiguration. Without autoconfiguration /124 and NAT is good enough for me. But how about my aunt with her laptop? Kind regards Peter and Karin -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter at peter-dambier.de mail: peter at echnaton.arl.pirates http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/ From pbaker at verisign.com Mon Aug 27 14:15:40 2007 From: pbaker at verisign.com (Hallam-Baker, Phillip) Date: Mon, 27 Aug 2007 05:15:40 -0700 Subject: [address-policy-wg] RE: IPv6 addresses really are scarce after all In-Reply-To: Message-ID: <198A730C2044DE4A96749D13E167AD37013A01BC@MOU1WNEXMB04.vcorp.ad.vrsn.com> Looks to me like people are trying to use technology to effect their political goals. I don't think that is a good idea, particularly since the process does not allow the goals to be stated or debated directly. So even if we agree on the end goals we are unlikely to end up with a mechanism that achieves them. We went through all that with the crypto-wars. We ended up with a set of cryptography protocols that almost nobody uses. I see no political reason to insist on a /48 as the minimum allocation. A /96 gives me more addresses than the old IPv4 space had. If we attempt to insist on a /x as the minimum allocation by introducing technical limitations that make it impossible to use less than a /x all we do is to make an allocation that could have been sufficient insufficient. > -----Original Message----- > From: Arnt Gulbrandsen [mailto:arnt at gulbrandsen.priv.no] > Sent: Monday, August 27, 2007 5:11 AM > To: ietf at ietf.org > Cc: michael.dillon at bt.com; John C Klensin; Hallam-Baker, > Phillip; ppml at arin.net; address-policy-wg at ripe.net > Subject: Re: IPv6 addresses really are scarce after all > > Hallam-Baker, Phillip writes: > > I don't see how such an architectural limitation can be enforced. > > There is no way that the IETF can prevent an ISP issuing IPv6 > > customers a /128 if they choose. > > Not directly, but there's the indirect route: a) IETF designs > IPv6 autoconfiguration. b) Linksys, D-Link, Netgear and > friends make boxes that support autoconfiguration. c) ISP > hand out /128s. d) Autoconfiguration doesn't work well. e) > Customers call ISP support. f) ISP loses $$$. g) ISP starts > issuing /48s instead. > > I don't know the first thing about how IPv6 autoconfiguration > works. It worked very well in my previous office. Will it > work better when the router has a /48 at hand than a /64 or /128? > > Arnt > From arnt at gulbrandsen.priv.no Mon Aug 27 14:28:11 2007 From: arnt at gulbrandsen.priv.no (Arnt Gulbrandsen) Date: Mon, 27 Aug 2007 14:28:11 +0200 Subject: [address-policy-wg] Re: IPv6 addresses really are scarce after all In-Reply-To: <198A730C2044DE4A96749D13E167AD37013A01BC@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD37013A01BC@MOU1WNEXMB04.vcorp.ad.vrsn.com> Message-ID: Hallam-Baker, Phillip writes: > Looks to me like people are trying to use technology to effect their > political goals. Guilty as charged, and proud of it. My political goal is to make computers help people in their daily life, and I believe that eliminating the class of users without the ability to subnet, leaving only one type of internet user, helps towards that goal. If there's only one type of network to autoconfigure, testing and deploying autoconfiguring devices is simpler, and autoconfiguration will do the right thing in a larger percentage of cases, leaving more people happy and making fewer people call support. Arnt From bgp2 at linuxadmin.org Mon Aug 27 16:38:25 2007 From: bgp2 at linuxadmin.org (Greg L.) Date: Mon, 27 Aug 2007 17:38:25 +0300 Subject: [address-policy-wg] 2007-02 Policy Proposal Withdrawn (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <20070827135314.C42302F583@herring.ripe.net> References: <20070827135314.C42302F583@herring.ripe.net> Message-ID: <6.1.2.0.2.20070827173730.08027920@www.linuxadmin.org> very sad...... At 17:56 2007.08.27., you wrote: >PDP Number: 2007-02 >Change in IP Assignments for Anycasting DNS Policy > >Dear Colleagues, > >Policy proposal 2007-02, "Change in IP Assignments for Anycasting >DNS Policy" has been withdrawn. The proposer decided that there was >insufficient support for the proposal. > >You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/archive/ > > >Regards > >Filiz Yilmaz >RIPE NCC >Policy Development Officer From michael.dillon at bt.com Mon Aug 27 22:52:48 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 27 Aug 2007 21:52:48 +0100 Subject: [address-policy-wg] RE: IPv6 addresses really are scarce after all In-Reply-To: References: <46C613E0.8010909@bogus.com><46C629D2.20009@cs.utk.edu> <17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com> <46C6B5BB.5000203@cs.utk.edu> <200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: > (2) The many examples you give seem to be to be associated > with different domains of authorization and privilege for > different groups of people and functions within the home. My > impression of the experience and literature in the field is > that almost every time someone tries to create such a > typology, they conclude that these are much better modeled as > sometimes-overlapping domains rather than as discrete > partitions. The subnet-based model you posit requires that > people or devices switch addresses when they change functions > or activities. Up to a point, one can do it that way (and > many of us have, even with IPv4). The subtext here is Ethernet. People are talking about home networks based on Ethernet and whether or not they should be segmented by routers. In my experience Ethernet bridges and switches are not designed with security as a goal. When they fail to transmit all incoming frames on all interfaces, it is to prevent segment overload or broadcast storms. There are many cases where people have found ways, sometimes quite simple ways, to receive Ethernet frames that are not addressed to them. Given this backdrop, I am suggesting that a homeowner may have several reasons for inserting routers (and router/firewalls) into their home network, thus requiring the ability to have multiple /64 IPv6 subnets. Architecture aside, this is a pragmatic response to an information security issue. > But I suggest that trying to use subnetting as the primary > and only tool to accomplish those functions is > architecturally just wrong, _especially_ for the types of > authorization-limitation cases you list. Wouldn't you rather > have mechanisms within your home network, possibly bound to > your switches, that could associate authorization property > lists with each user or device > and then enforce those properties? This would be nice, but I believe this needs more work and not just in the IETF. Also, I believe that the IETF should tackle the basic requirements for a home and/or business IPv6 Internet gateway first, and then go on to the more advanced security issues. > (4) Which IETF WG is working on these things? :-( Or failing that, which area does it belong in? --Michael Dillon From terry.l.davis at boeing.com Mon Aug 27 16:04:14 2007 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Mon, 27 Aug 2007 07:04:14 -0700 Subject: [address-policy-wg] RE: [ppml] IPv6 addresses really are scarce after all In-Reply-To: References: <46C613E0.8010909@bogus.com><46C629D2.20009@cs.utk.edu><17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com><46C6B5BB.5000203@cs.utk.edu><200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com><70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A03685B20@XCH-NW-8V1.nw.nos.boeing.com> Michael Agree. And don't forget that your: - power company - communication/entertainment provider/s - alarm/monitoring company - local government - EMS All have at least discussions in progress that would give each home/apartment a subnet (albeit possibly/probably on different networks) for there use as a home service provider. Take care Terry > -----Original Message----- > From: michael.dillon at bt.com [mailto:michael.dillon at bt.com] > Sent: Sunday, August 26, 2007 4:42 AM > To: ppml at arin.net; address-policy-wg at ripe.net; ietf at ietf.org > Subject: Re: [ppml] IPv6 addresses really are scarce after all > > > The definition of a small network is pretty much "single > > subnet". Yes, I understand very well that the average home of > > the future will have a mixed wiring. Of course, my own home > > does have Ethernet and Wi-Fi. In the not so distant future, > > it will have several Wi-Fi networks operating on different > > frequencies, some form of power-line networking, and some > > rooms may have their own high speed wireless wiring using UWB > > or some similar technology. But I am pretty much convinced > > that all of these will be organized as a single subnet. > > You are remarkably trusting. You do all your homebanking on the same > subnet as your teenage children who are studying Hacking 101 in the > privacy of their bedroom? And when guests come over for dinner, you have > no objection to them taking their laptop to the bathroom in order to > surf for child porn over your wireless network. > > The fact is that a lot of people will WANT subnets in the home. They > will want a router/firewall that will isolate each of the children's > bedrooms so that they cannot mess with your bank account or with their > brother's/sister's romantic chat sessions. Many people will want all > wireless access to go through a router. Many will have an in-law suite, > and want to seamlessly integrate their relative's existing network via a > simple router connection. And the family jewels, that Raid 5 server > cluster that holds all the family photos and videos, will be behind > another router/firewall. When the kids host a LAN party, the gamers will > connect to the family network via a router/firewall with limited > Internet access for only the necessary protocols. Subnets multiply for > architectural and security reasons. > > Multiple subnets per home is *NOT* a waste of anything. It is an > invitation to dreamers and inventors to make better network things for > the home market. It is an enabler of business activity, an enabler of > competition. > > --Michael Dillon > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member > Services > Help Desk at info at arin.net if you experience any issues. From mouse at Rodents.Montreal.QC.CA Mon Aug 27 16:40:40 2007 From: mouse at Rodents.Montreal.QC.CA (der Mouse) Date: Mon, 27 Aug 2007 10:40:40 -0400 (EDT) Subject: [address-policy-wg] Re: [anti-spam-wg] Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: In-Reply-To: <189D258D-F144-46EA-BF55-26EDEA231E7C@icann.org> References: <152533.59187.qm@web33106.mail.mud.yahoo.com> <200708241908.PAA02461@Sparkle.Rodents.Montreal.QC.CA> <89F45AD7-1601-483D-B35C-46CFA6397A4E@icann.org> <200708262225.SAA02234@Sparkle.Rodents.Montreal.QC.CA> <189D258D-F144-46EA-BF55-26EDEA231E7C@icann.org> Message-ID: <200708271527.LAA07375@Sparkle.Rodents.Montreal.QC.CA> >> In any case, my "proposal" is that ICANN impose responsibility along >> with authority: as a simple example (restricted just to address >> space assignment), it could establish an AUP that RIRs would have to >> comply with to keep their assigned space - and then enforce it (this >> step is not optional, or the fix won't actually fix anything). > Are you suggesting that ICANN should assume the regulatory role that > currently sits with sovereign nations? What regulatory role is that? The one that RIPE is assuming in imposing an AUP on its sub-assignees (if my memory of their claim is accurate)? The one that (almost) every ISP in the world assumes in imposing an AUP on its customers? >> Sitting on their thumbs waiting for someone else to solve the >> problem, which is what I see them doing, is *not* a responsible >> thing for ICANN/IANA to do here. If this is being done because >> that's what the procedures in place call for, then the procedures >> themselves are broken and need to be fixed. > Please let me know where I can get a copy of the document authorising > IANA to regulate in this area. Why do you need one? IANA has the authority to delegate address space (again, restricting the discussion to just address space for ease of language); where does it get that from? What compels it to so delegate without an AUP attached? If there is such a thing, then that thing is (part of) the problem and needs to be fixed before we can have a non-broken Internet. > A top down approach is unlikely to work without effective enforcement > mechanisms. Oh, certainly. The AUPs I'm speaking of would have to be enforced, or they won't help anything. > As you'd like to see an AUP it might be helpful to give us a general > idea of what you'd like to see in it and what you'd like to see done > when it is not followed. At the moment I'm not sure what you want > and that makes it difficult to draft a policy proposal. As I remarked upthread, I'm not a policy author. But there are plenty of AUPs around to look at as examples; as I also remarked upthread, I think RIPE told me they have one that they impose, de-jure at least, on their sub-assignees; that might be a reasonable place to start. Most ISPs have one; looking at a bunch of them would be a reasonable source of ideas too. Looking back to the days when there was an effective authority at the top in the form of the NSF and (earlier) DARPA and looking at the AUPs they had might give some ideas - though you'd have substantial sections to rip out. As for penalties, I don't know what would be most reasonable. Penultimately, there's deassigning of the address space in question; ultimately, revoking of all assignments and the "charter", if you will, as RIR. But those would necessarily be last-resort steps; I'm not sure what would be appropriate as intermediate sanctions. Maybe look at what ISPs do for problem customers? All your talk about bottom-up policy is, I think, missing something important. It seems to be treating the net as a democracy. Internet governance has never been democratic. Perhaps it would be better if it were, perhaps not - but it isn't; it is, and always has been, dictatorial. The dictators have been benevolent, laissez-faire, and relatively willing to listen to the populace, so it hasn't felt much like a dictatorship, but that's what it's been. And that could be where the problem is coming from: it looks to me as though you're treating the net like a dictatorship when it comes to authority, but like a democracy when it comes to responsibility. In any case, once again, why are you asking me to do your work for you? It's your *job* there, you at ICANN and the IANA, to deal with the difficult issues of Internet governance; go do your job! (What makes me think you're not? All the problems that have arisen under - and, I believe, from - your regime, and the nothing I see being done to deal with them.) Or don't, and watch the slide downhill continue. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From jnc at mercury.lcs.mit.edu Mon Aug 27 19:42:04 2007 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 27 Aug 2007 13:42:04 -0400 (EDT) Subject: [address-policy-wg] RE: IPv6 addresses really are scarce after all Message-ID: <20070827174204.BC82E872F8@mercury.lcs.mit.edu> > From: "Hallam-Baker, Phillip" > Perhaps you could define the term subnet? "IP subnet", or "subnet" in the more general networking (outside-the-IP-community - the null set these days, I know) sense? For the first, originally, back in the days of class A/B/C "network numbers", it was a chunk of address space smaller than the "network" it was assigned from; it was used to provide addresses for a particular physical network. Now that we have CIDR, it seems to basically just means a chunk of address space assigned to a particular hardware network (the second meaning of "subnet"). For the second, it meant a particular physical network, i.e. the collection of end-stations which could send packets directly to each other without going through a router. This was before bridges, hubs, etc. Goodness knows what it means now! I'd suggest "multicast broadcast domain" as a good modern functional definition. Noel From stephen at sprunk.org Mon Aug 27 23:08:14 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 27 Aug 2007 16:08:14 -0500 Subject: [address-policy-wg] Re: [ppml] IPv6 addresses really are scarce after all References: <46C613E0.8010909@bogus.com><46C629D2.20009@cs.utk.edu><17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com><46C6B5BB.5000203@cs.utk.edu><200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com><70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <018801c7e8f1$88990300$4d3816ac@atlanta.polycom.com> Thus spake > In my experience Ethernet bridges and switches are not > designed with security as a goal. When they fail to transmit > all incoming frames on all interfaces, it is to prevent segment > overload or broadcast storms. There are many cases where > people have found ways, sometimes quite simple ways, to > receive Ethernet frames that are not addressed to them. > Given this backdrop, I am suggesting that a homeowner > may have several reasons for inserting routers (and router / > firewalls) into their home network, thus requiring the ability > to have multiple /64 IPv6 subnets. Architecture aside, this > is a pragmatic response to an information security issue. Basically, because some people are too dense to use IPsec or SSL for traffic they don't want observed, you want to greatly complicate the average home network's design? That they should be more scared of, say, their spouse sniffing their credit card numbers at home than the NSA and FBI tapping their email and web browsing at the CO? Sorry, but that's the wrong response to the wrong problem. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From dean at av8.com Tue Aug 28 01:02:41 2007 From: dean at av8.com (Dean Anderson) Date: Mon, 27 Aug 2007 19:02:41 -0400 (EDT) Subject: [address-policy-wg] Re: [ppml] IPv6 addresses really are scarce after all In-Reply-To: <018801c7e8f1$88990300$4d3816ac@atlanta.polycom.com> Message-ID: On Mon, 27 Aug 2007, Stephen Sprunk wrote: > Basically, because some people are too dense to use IPsec or SSL for traffic > they don't want observed, you want to greatly complicate the average home > network's design? That they should be more scared of, say, their spouse > sniffing their credit card numbers at home than the NSA and FBI tapping > their email and web browsing at the CO? It has nothing to do with IPsec or SSL. Your view of what people do at home is kind of narrow. Some people run businesses out of their house, and some have quite complicated home networks, with wifi for guests and and other parts they don't want guests to get into. If you have the space, give it out. (that was the point of a 16 byte IP address) The notion that a home user's subnetting makes any difference to the DFZ is just plain nonsense. Those sub-blocks are aggregated by their provider. The home user doesn't need or take a full view, either. They have just their subnets and a default route. At the other end, the notion that geographic aggregation reduces the DFZ is likewise nonsense. It just eases the job of the RIR and running multiple RIRs. But every block delegated by the RIR will probably make it into the DFZ, unless it is used for some kind of non-public routing, in which case perhaps it makes it into some DFZ's, but not others. There usually isn't any aggregation of blocks delegated by the RIR. --Dean > Sorry, but that's the wrong response to the wrong problem. > > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From tommy.perniciaro at thomson.net Tue Aug 28 01:38:48 2007 From: tommy.perniciaro at thomson.net (Tommy Perniciaro) Date: Mon, 27 Aug 2007 16:38:48 -0700 Subject: [address-policy-wg] Re: [ppml] IPv6 addresses really are scarce after all In-Reply-To: Message-ID: I agree with Dean entirely. On 8/27/07 4:02 PM, "Dean Anderson" wrote: > On Mon, 27 Aug 2007, Stephen Sprunk wrote: > >> > Basically, because some people are too dense to use IPsec or SSL for >> traffic >> > they don't want observed, you want to greatly complicate the average home >> > network's design? That they should be more scared of, say, their spouse >> > sniffing their credit card numbers at home than the NSA and FBI tapping >> > their email and web browsing at the CO? > > It has nothing to do with IPsec or SSL. Your view of what people do at > home is kind of narrow. Some people run businesses out of their house, > and some have quite complicated home networks, with wifi for guests and > and other parts they don't want guests to get into. > > If you have the space, give it out. (that was the point of a 16 byte IP > address) The notion that a home user's subnetting makes any difference > to the DFZ is just plain nonsense. Those sub-blocks are aggregated by > their provider. The home user doesn't need or take a full view, either. > They have just their subnets and a default route. > > At the other end, the notion that geographic aggregation reduces the DFZ > is likewise nonsense. It just eases the job of the RIR and running > multiple RIRs. But every block delegated by the RIR will probably make > it into the DFZ, unless it is used for some kind of non-public routing, > in which case perhaps it makes it into some DFZ's, but not others. There > usually isn't any aggregation of blocks delegated by the RIR. > > --Dean > >> > Sorry, but that's the wrong response to the wrong problem. >> > >> > S >> > >> > Stephen Sprunk "God does not play dice." --Albert Einstein >> > CCIE #3723 "God is an inveterate gambler, and He throws the >> > K5SSS dice at every possible opportunity." --Stephen Hawking >> > >> > >> > _______________________________________________ >> > PPML >> > You are receiving this message because you are subscribed to the ARIN >> Public Policy >> > Mailing List (PPML at arin.net). >> > Unsubscribe or manage your mailing list subscription at: >> > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member >> Services >> > Help Desk at info at arin.net if you experience any issues. >> > >> > > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public > Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member > Services > Help Desk at info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Aug 28 09:56:20 2007 From: randy at psg.com (Randy Bush) Date: Tue, 28 Aug 2007 16:56:20 +0900 Subject: [address-policy-wg] Re: [anti-spam-wg] Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: In-Reply-To: <200708271527.LAA07375@Sparkle.Rodents.Montreal.QC.CA> References: <152533.59187.qm@web33106.mail.mud.yahoo.com> <200708241908.PAA02461@Sparkle.Rodents.Montreal.QC.CA> <89F45AD7-1601-483D-B35C-46CFA6397A4E@icann.org> <200708262225.SAA02234@Sparkle.Rodents.Montreal.QC.CA> <189D258D-F144-46EA-BF55-26EDEA231E7C@icann.org> <200708271527.LAA07375@Sparkle.Rodents.Montreal.QC.CA> Message-ID: <46D3D524.2040901@psg.com> perhaps this layer 12 discussion could be moved to the igf mailings lists, wherever they are. randy From rumy at ripe.net Tue Aug 28 12:51:10 2007 From: rumy at ripe.net (Rumy Kanis) Date: Tue, 28 Aug 2007 12:51:10 +0200 Subject: [address-policy-wg] RIPE NCC E-Learning Centre: New PDP Module In-Reply-To: <46C9A789.9080506@ripe.net> References: <46C9A789.9080506@ripe.net> Message-ID: <46D3FE1E.2040608@ripe.net> Dear Colleagues, Last week, we announced that a new E-Learning module on the RIPE Policy Development Process (PDP) was available in the RIPE NCC's E-Learning Centre. Unfortunately, we directed you to an old version of this module. The updated version of the PDP module is now available at: https://e-learning.ripe.net We apologise for any inconvenience this may have caused. Kind regards, Rumy Kanis Training Services Manager RIPE NCC From marc.van.selm at nc3a.nato.int Thu Aug 30 08:41:04 2007 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Thu, 30 Aug 2007 08:41:04 +0200 Subject: [address-policy-wg] Re: [ppml] IPv6 addresses really are scarce after all In-Reply-To: References: Message-ID: <200708300841.04887.marc.van.selm@nc3a.nato.int> On Tuesday 28 August 2007 01:02, Dean Anderson wrote: > On Mon, 27 Aug 2007, Stephen Sprunk wrote: > > Basically, because some people are too dense to use IPsec or SSL for > > traffic they don't want observed, you want to greatly complicate the > > average home network's design? That they should be more scared of, say, > > their spouse sniffing their credit card numbers at home than the NSA and > > FBI tapping their email and web browsing at the CO? > > It has nothing to do with IPsec or SSL. Your view of what people do at > home is kind of narrow. Some people run businesses out of their house, > and some have quite complicated home networks, with wifi for guests and > and other parts they don't want guests to get into. I agree, not all home users have a small flat LAN. I'm personally running a VPN between 2 locations (privately) that are 85km seperated. Concequently I have 3 subnets (location A, WAN and location B). Besides that I have a VPN access when I'm on the road into those as well (currently IPv4 but as soon as I have the time v6). So I guess I'm actually using 4 subnets. I'm currently running my WLAN closed and not open to my guests but if I would open it (which I consider when I have some time to set up a captive portal log-in facility). Then I'd have 6 subnets (the 4 already mentioned + guest WLAN at both locations). I know I'm not the average user and probably more a geek but... And like Dean suggests already, I use crypto for completely different purposes, I don't need to subnet for that. Regards, Marc -- -- This mail is personal -- All statements in this mail are made from my own personal perspective and do not necessarily reflect my employer's opinions or policies. From leo.vegoda at icann.org Fri Aug 31 12:57:34 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 31 Aug 2007 12:57:34 +0200 Subject: [address-policy-wg] Re: [anti-spam-wg] Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: In-Reply-To: <200708271527.LAA07375@Sparkle.Rodents.Montreal.QC.CA> References: <152533.59187.qm@web33106.mail.mud.yahoo.com> <200708241908.PAA02461@Sparkle.Rodents.Montreal.QC.CA> <89F45AD7-1601-483D-B35C-46CFA6397A4E@icann.org> <200708262225.SAA02234@Sparkle.Rodents.Montreal.QC.CA> <189D258D-F144-46EA-BF55-26EDEA231E7C@icann.org> <200708271527.LAA07375@Sparkle.Rodents.Montreal.QC.CA> Message-ID: <055FF44A-BE47-4397-AD76-01E3656511D9@icann.org> On 27 Aug 2007, at 16:40, der Mouse wrote: [...] >> Please let me know where I can get a copy of the document authorising >> IANA to regulate in this area. > > Why do you need one? IANA has the authority to delegate address space > (again, restricting the discussion to just address space for ease of > language); where does it get that from? What compels it to so > delegate > without an AUP attached? The authority is given by the RIR communities who develop the policy. The policy they drafted and agreed did not include an AUP section. I have a feeling that it might not include an AUP because it no-one wanted one. I could be wrong, though. You can propose a change to that policy through the same system. If you want to change the whole system then Randy is right and you need to take things up elsewhere, like at the IGF. Regards, Leo Vegoda From michael.dillon at bt.com Fri Aug 31 17:31:50 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 31 Aug 2007 16:31:50 +0100 Subject: [address-policy-wg] Re: IPv6 addresses really are scarce after all In-Reply-To: <59D5CFF02CEE1D3C96D66409@p3.JCK.COM> References: <46C613E0.8010909@bogus.com> <46C629D2.20009@cs.utk.edu> <17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com> <46C6B5BB.5000203@cs.utk.edu> <200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <46D05897.5010906@cs.utk.edu> <59D5CFF02CEE1D3C96D66409@p3.JCK.COM> Message-ID: > Will all due respect, even if you assume a "home" with ten > occupants, a few hundred subnets based on functions, and > enough sensor-type devices to estimate several thousand of > them per occupant and a few thousand more per room, 2**64 is still a > _lot_ of addresses. This is hyperbole. All IPv6 subnets have the same minimum number of addresses (2**64) regardless of where they are used. > But I don't think hyperbole > helps the discussion. I agree. In any case, it doesn't make sense to discuss IPv6 in terms of hostcounts. It makes more sense to discuss numbers of subnets or numbers of aggregation levels. If a private home with two occupants and one PC, builds out an in-law suite for one mother-in-law with one PC, then it still makes sense to have at least two subnets in that private home, i.e. at least one level of aggregation. Hostcount is irrelevant. Note that if both mother-in-law and homeowner install 4 or five home media devices, the subnetted architecture will work better than a /64 per home scenario. Now that we have shown subnetting is useful in a private home, it is clear that a /64 per home is not enough. It still leaves open the question of whether a /48 is too much, i.e. too many subnets and/or too many levels of aggregation. If a /48 is not too much, then the IETF should issue guidance that states that. If some prefix length between /48 and /64 is OK under certain circumstances then the IETF should issue guidance which states that. I still have not seen any clear indication that there is a negative technical impact of assigning a /56 per home. To date, the only clear technical issue I have seen mentioned for subnet prefixes longer than /48 is that if they are not on a 4-bit hex nibble boundary, it makes IPv6 PTR delegation more complex. --Michael Dillon From mouse at Rodents.Montreal.QC.CA Fri Aug 24 20:55:14 2007 From: mouse at Rodents.Montreal.QC.CA (der Mouse) Date: Fri, 24 Aug 2007 14:55:14 -0400 (EDT) Subject: [address-policy-wg] Re: [anti-spam-wg] Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: In-Reply-To: <152533.59187.qm@web33106.mail.mud.yahoo.com> References: <152533.59187.qm@web33106.mail.mud.yahoo.com> Message-ID: <200708241908.PAA02461@Sparkle.Rodents.Montreal.QC.CA> > I Matthew Brown, would like to request that there be some sort of > action, to allow the ripe database managers to contact ISP(s) when > someone reports incorrect or outdated information. Good luck - and I mean that; I hope you succeed, though at this point I don't really expect it. I've gone a few rounds with RIPE myself on that issue; they appear to want the authority of "owning" (and being paid for the subdelegation of) address space without the concomitant responsibility. Not surprising, of course; lots of people would rather pocket the money and duck the responsibility. The real problem is that ICANN/IANA lets them get away with it, and I see that (that the top of the governance pyramid does not impose responsibility on those to whom it delegates authority - and I don't mean just RIRs; the same problem recurs with domains) as the fundamental problem that is killing today's net with abusers and abuses. Any system with mismatches between authority and responsibility grows abuses, until one of three things happens: (1) the mismatch is corrected, (2) the system collapses, or (3) in mild cases, an equilibrium is reached, with the level of abuse concomitant with the level of mismatches. In the case of Internet governance, the mismatch appears to be total, so (3) is out, and there appears to be no will whatever to do (1), so I expect the abuses to simply grow until the net collapses from them. The only reason I'm not just standing back and watching it happen is that I'd like to have a usable Internet myself in the near term - during the time it would take for the current system to collapse and shake out something less broken. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B