Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Mon, 26 Apr 2010 07:46:04 -0700 Jim Burwell j...@jsbc.cc wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/26/2010 03:36, Mikael Abrahamsson wrote: On Sun, 25 Apr 2010, Owen DeLong wrote: I fail to see how link local is any more difficult than any other IPv6 address. They're different because you have to know your local network interface name as well. Windows might get interesting as windows interface naming is, uh, creative at best. Exactly. Installation software could make this easy. It could either prompt the user to type in the address on a sticker then enumerate all interfaces on the system and attempt to contact the router on each NIC. Another possibility is that it could enumerate all the interfaces, then use the IPv6 link-local scope all routers multicast (ff02::2) to enumerate a list of routers found on each link, sort them and/or filter them by ethernet OUI, and present a list of choices for the user to click on to configure the router. The user could also easily match the enet address on a little slip of paper or sticker on the router to this list, or through some initial settings on the router which allow info to be pulled from it somehow, present a list of unconfigured routers, etc, etc. Point is, I can imagine a lot of ways this could be made user-proof via software/firmware combination that requires no advanced networking knowledge. It's called multicast DNS. It's easier for that to deal just with vanilla IPv6 addresses (i.e. via application calls to getaddrinfo()), rather than IPv6 LL addrs + interface names. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvVpywACgkQ2fXFxl4S7sSCuwCg07Gwxz6NDYuTkVYr5gP5LUMC n4EAoIdqZQ7C/01X0EcV3vnZiTD4b7Vc =hDQN -END PGP SIGNATURE-
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Apr 29, 2010, at 4:26 AM, Mark Smith wrote:
On Mon, 26 Apr 2010 07:46:04 -0700
Jim Burwell j...@jsbc.cc wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/26/2010 03:36, Mikael Abrahamsson wrote:
On Sun, 25 Apr 2010, Owen DeLong wrote:
I fail to see how link local is any more difficult than any
other IPv6 address.
They're different because you have to know your local network
interface name as well.
Windows might get interesting as windows interface naming is,
uh, creative at best.
Exactly.
Installation software could make this easy. It could either prompt
the user to type in the address on a sticker then enumerate all
interfaces on the system and attempt to contact the router on each NIC.
Another possibility is that it could enumerate all the interfaces,
then use the IPv6 link-local scope all routers multicast (ff02::2) to
enumerate a list of routers found on each link, sort them and/or
filter them by ethernet OUI, and present a list of choices for the
user to click on to configure the router. The user could also easily
match the enet address on a little slip of paper or sticker on the
router to this list, or through some initial settings on the router
which allow info to be pulled from it somehow, present a list of
unconfigured routers, etc, etc.
Point is, I can imagine a lot of ways this could be made user-proof
via software/firmware combination that requires no advanced networking
knowledge.
It's called multicast DNS. It's easier for that to deal just with
vanilla IPv6 addresses (i.e. via application calls to getaddrinfo()),
rather than IPv6 LL addrs + interface names.
Actually, mDNS will handle IPv6 LL just fine. The interface name is
automatically provided along with the scope in the return values from
getaddrinfo():
struct addrinfo {
int ai_flags; /* input flags */
int ai_family; /* protocol family for socket */
int ai_socktype;/* socket type */
int ai_protocol;/* protocol for socket */
socklen_t ai_addrlen; /* length of socket-address */
struct sockaddr *ai_addr; /* socket-address for socket */
char *ai_canonname; /* canonical name for service location */
struct addrinfo *ai_next; /* pointer to next in list */
};
struct sockaddr is an abstraction to an address-family specific structure.
The IPv6 structure (sockaddr_in6) is as follows:
struct sockaddr_in6 {
__uint8_t sin6_len; /* length of this struct(sa_family_t)*/
sa_family_t sin6_family;/* AF_INET6 (sa_family_t) */
in_port_t sin6_port; /* Transport layer port # (in_port_t)*/
__uint32_t sin6_flowinfo; /* IP6 flow information */
struct in6_addr sin6_addr; /* IP6 address */
__uint32_t sin6_scope_id; /* scope zone index */
};
Note that the sockaddr_in6 structure will contain an in6_addr structure
and a sin6_scope_id (which specifies the scope of the address and
should, according to RFC 4007 contain enough information to identify
the zone (interface) as well).
Thus you should be able to pass the return value of getaddrinfo()
with an mDNS result containing a link local address to connect()
and expect it to work just fine.
Owen
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Apr 29, 2010, at 8:45 AM, Bill Stewart wrote: On Mon, Apr 26, 2010 at 7:20 AM, Stephen Sprunk step...@sprunk.org wrote: The vast majority of residential customers have a single subnet, so they can get by just fine using IPv6 link-local addresses. The vanishingly small percentage that have multiple subnets are presumably savvy enough to set up ULA-R addresses. There is no need for ULA-C in this scenario. Actually it's pretty common for residential customers to have multiple subnets, one wired and one wireless, even if they're both NAT'd to 192.168.x.x. They may may or not be doing anything with the wired subnet, and their wireless router may also be providing a wired subnet bridged with the wireless, If it's bridged, they are not separate subnets. This is the most common configuration. For one thing, if they are both NAT'd, things on wireless the consumer expects to be able to talk to things on wired tend not to work. (This is only partially due to NAT, but, largely due to lazy code that assumes everything is on one subnet which is usually a safe assumption. The reason this became a usually safe assumption is another example of damage done by NAT). and it's all happening in little consumer-appliance boxes that work by magic, but it's out there. Not quite the way you seem to think it is. Owen
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Apr 25, 2010, at 7:37 PM, Mikael Abrahamsson wrote: On Sun, 25 Apr 2010, Doug Barton wrote: On 04/25/10 16:42, Owen DeLong wrote: That's what Link Local is for. fe80::EUI-64%interface For example, if the CPE is connected to the customer's network on eth0 and the CPE mac address is 00:45:4b:b9:02:be, you could go to: http://[fe80::0245:4bff:feb9:02be]%eth0 ... and regardless of the specific method, the vendors already document the procedure for connecting to the web interface for IPv4, there is no reason to believe that they could not or would not do the same for IPv6 if necessary. Does anyone actually believe that the above is user-friendly and will work in real life? Using link-local for this kind of end-user administration of their equipment is doomed to fail. There needs to be a procedure for devices which are going to get DHCP-PD from the provider, that they have a certain prefix they use until they actually get the real PD prefix, so end user dns etc works so it's easy to do administration of the device. I fail to see how link local is any more difficult than any other IPv6 address. I also fail to see how this is significantly different from the way these devices work in IPv4. We can't expect end-users to do the above procedure. Of course not... End users will get a slip of paper with the computed Link Local already on it in the form of connect to http://[fe80::0245:4bff:feb9:02be]%xxx Where xxx will be en0 for Mac, eth0 for Linux, etc. If it's a wireless adapter, it will be en1 for Mac. Windows might get interesting as windows interface naming is, uh, creative at best. Owen
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Sun, 25 Apr 2010 20:03:29 -0700 Doug Barton do...@dougbarton.us wrote: On 04/25/10 19:37, Mikael Abrahamsson wrote: On Sun, 25 Apr 2010, Doug Barton wrote: ... and regardless of the specific method, the vendors already document the procedure for connecting to the web interface for IPv4, there is no reason to believe that they could not or would not do the same for IPv6 if necessary. Does anyone actually believe that the above is user-friendly and will work in real life? Sorry, I knew that I shouldn't have helped perpetuate this thread, which (IMO) is already way off topic. I think it is entirely reasonable to discus. End-users of the Internet indirectly pay operators' salaries, so it is very wise for operators to remember to think like the customer (or, in the least, remember that if operators make the Internet too hard to use, they'll likely be the ones called around to their non-technical relatives' place to fix my broken Internet).
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Mon, 26 Apr 2010 00:46:17 +0100 Tony Hoyle t...@hoyle.me.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/04/2010 23:53, Mark Smith wrote: On Sun, 25 Apr 2010 16:17:21 +0100 Tony Hoyle t...@hoyle.me.uk wrote: On 25/04/2010 03:01, Mark Smith wrote: I'm a typical, fairly near future residential customer. I have a NAS that I have movies stored on. My ISP delegates an IPv6 prefix to me with a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes What ISP would put a 'lifetime' on your ipv6 prefix? Because they loan it to you while you are their customer. Unless you get PI, you don't 'own' your addresses, so you can't take them with you when you change ISPs. In IPv4 a lifetime is implicit, which might be as long/short as while your current connection is up, in IPv6 it is explicit. That's not what 'lifetime' means in this discusion. They're talking about v6 addresses changing when you're with the same provider - indeed, when logged into the same link even. That's insane. How much do you understand about IPv6 addressing? Are you aware that IPv6 addresses have explicit preferred and valid lifetimes, and therefore they can change over time? A change of ISP is a major change. Your ipv4 addresses will change as well if you change ISP. As you say, if you don't want them to change get PI space. v6 and v4 are no different in this respect. Tony -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL1NRJAAoJEJ1qCQ6ePCDUDeQH/07EZ2uBb5E2Is5juO1NCp4S BYl36VnSIwmadVZpQxJ2tmrJB2jKGV2sV4K0hJ/QRHRNK0k0CJv2k/KWPf8sis6p v6bDjnHD1k4bSTxuwEgRbAbPB5uDpRaw7F2ItgdNKGmf8KZh+tCX4uYZ3Pger0Q9 BEE6y/PjDlgk+ZW+BX6Jgp5raBC9gWu0hiFIhiIRXxmUNgKmJpaRsc6DH5jC5Hch BhrDxvHZCMNpG2KH32w9D955FSHBCt/ih/hNEB36yDTiln4gMx99jKquECeZrujJ zX1+sZ0DtLGR3oFjXyXfVS+8Y13i2fLYfQ1g5l/dhXGGs+Nwwb0ska8K+D5Tza0= =cgpi -END PGP SIGNATURE-
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
Use mdns/bonjour to connect to unconfigured devices. It uses link- local addresses (no need for an uplink and works for any kind of device) and provides friendly names. Tony (on his iPod). -- f.anthony.n.finch d...@dotat.at http://dotat.at/ On 26 Apr 2010, at 03:37, Mikael Abrahamsson swm...@swm.pp.se wrote: On Sun, 25 Apr 2010, Doug Barton wrote: On 04/25/10 16:42, Owen DeLong wrote: That's what Link Local is for. fe80::EUI-64%interface For example, if the CPE is connected to the customer's network on eth0 and the CPE mac address is 00:45:4b:b9:02:be, you could go to: http://[fe80::0245:4bff:feb9:02be]%eth0 ... and regardless of the specific method, the vendors already document the procedure for connecting to the web interface for IPv4, there is no reason to believe that they could not or would not do the same for IPv6 if necessary. Does anyone actually believe that the above is user-friendly and will work in real life? Using link-local for this kind of end-user administration of their equipment is doomed to fail. There needs to be a procedure for devices which are going to get DHCP-PD from the provider, that they have a certain prefix they use until they actually get the real PD prefix, so end user dns etc works so it's easy to do administration of the device. We can't expect end-users to do the above procedure. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Sun, 25 Apr 2010, Owen DeLong wrote: I fail to see how link local is any more difficult than any other IPv6 address. They're different because you have to know your local network interface name as well. Windows might get interesting as windows interface naming is, uh, creative at best. Exactly. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/04/2010 08:08, Mark Smith wrote: How much do you understand about IPv6 addressing? Are you aware that IPv6 addresses have explicit preferred and valid lifetimes, and therefore they can change over time? Only via privacy extensions.. and I always switch them off as they're a pain in the neck. Even with those they don't change the prefix. My /48 is allocated to me.. In no sane world would that suddenly change, unless I did something major like change ISP, any more than my v4 address would suddenly change. You're trying to say ipv6 prefixes change randomly over time - just think of the implications if that could happen... even basic things like firewalling would become a nightmare. Tony -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL1Ya9AAoJEJ1qCQ6ePCDU5H0H/RE+eHLqJ/18akk/OQHaGF1H 6DebnteCd73tHzzY+1rNs0yNlOkFIE6u3FSCjRgP0Es+x4K7RjKsBhKzWYxhb+t3 CnPQNySP1diQxhCPZV/aTOC+/hyAKFdsQhz4TKVhMdhbA+K+wqpwUWAAXZMTVpoh GuMdK6EngV0IHw2gMwt+VdLVMbKII2BTiw7GVKnULwWhPUOipfJ0othxPhStULtg 3adZo4ka+129Cpv3Kx0BkMLTLUDneJA8Ia6MgRRz7G9SBlaJQ6J6Oidcp49Ag3SF 4jw+8DhLQbZJPsuRjxcdBYZDEHkVBqTje+KNbp2tuAUUCzqKClOSGycszyfncp0= =MWdV -END PGP SIGNATURE-
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
Mikael Abrahamsson wrote: Yeah, and when I try that on my linux box it won,t install the software for some reason. we need solutions that are cross platform and open, let's not help microsoft any further, thank you. Ummm, we're talking about idiots that can't figure out how to type and address. If you're on a linux box, presumably there is someone around that can hit a link-local or other addressing scheme programmed on the router. Jack
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Mon, 26 Apr 2010, Jack Bates wrote: Ummm, we're talking about idiots that can't figure out how to type and address. If you're on a linux box, presumably there is someone around that can hit a link-local or other addressing scheme programmed on the router. This is getting wildly off topic, but if you go to the ubuntu support channels and forums (and mac I guess) you'll see that this is no longer true. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
Mark Smith wrote: The IPv6 Internet needs to be at least as user friendly as IPv4, so asking residential customers to type in anything harder than an IPv4 address is unacceptable. IPv6 has plenty of them. http://www.rfc-editor.org/rfc/rfc4193.txt rfc4193, and please remember you can bind multiple IPv6 addresses, which makes it even more fun, and there's honestly no reason why dns services, capture services, etc on a home router can't make it a painless process. That being said, typing a shortcut address into a browser won't be bad and since not link-local you don't have to worry about the %interface crap. Jack
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On 24 Apr 2010 21:01, Mark Smith wrote: On Thu, 22 Apr 2010 01:48:18 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Wed, Apr 21, 2010 at 5:47 PM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: So what happens when you change providers? How are you going to keep using globals that now aren't yours? use pi space, request it from your local friendly RIR. I was hoping that wasn't going to be your answer. So do you expect every residential customer to get a PI from an RIR? The vast majority of residential customers have no idea what globals or PI are. They use PA and they're fine with that--despite being forcibly renumbered every few hours/days. (Many ISPs deliberately tune their DHCP servers to give residential customers a different address each time for market segmentation reasons.) Here's the scenario: I'm a typical, fairly near future residential customer. I have a NAS that I have movies stored on. My ISP delegates an IPv6 prefix to me with a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes. ... I start watching a 2 hour movie, delivered from my NAS to my TV over IPv6, using the GUA addresses (because you're saying I don't ULAs). 5 minutes into the movie, my Internet drops out. And five minutes and a few seconds into the movie, the movie drops out because the DRM mechanism can't phone home anymore to validate you still have a license to watch it. I have an IP-based DVR, and that's exactly what happens. However, let us look forward to a world where the TV/movie studios have woken up to the fact that DRM does more harm than good, as the record industry recently has: 1 hour, 35 minutes into movie, the movies drops out, because the IPv6 addresses used to deliver it can't be used anymore. The vast majority of residential customers have a single subnet, so they can get by just fine using IPv6 link-local addresses. The vanishingly small percentage that have multiple subnets are presumably savvy enough to set up ULA-R addresses. There is no need for ULA-C in this scenario. The only semi-rational justification for ULA-C is that organizations privately internetworking with other organizations are scared of ULA-R collisions. However, PI solves that problem just as readily. If one cannot afford or qualify for PI, or one wants a non-PI prefix due to delusions of better security, one can use a private deconfliction registry, e.g. http://www.sixxs.net/tools/grh/ula/. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/26/2010 03:36, Mikael Abrahamsson wrote: On Sun, 25 Apr 2010, Owen DeLong wrote: I fail to see how link local is any more difficult than any other IPv6 address. They're different because you have to know your local network interface name as well. Windows might get interesting as windows interface naming is, uh, creative at best. Exactly. Installation software could make this easy. It could either prompt the user to type in the address on a sticker then enumerate all interfaces on the system and attempt to contact the router on each NIC. Another possibility is that it could enumerate all the interfaces, then use the IPv6 link-local scope all routers multicast (ff02::2) to enumerate a list of routers found on each link, sort them and/or filter them by ethernet OUI, and present a list of choices for the user to click on to configure the router. The user could also easily match the enet address on a little slip of paper or sticker on the router to this list, or through some initial settings on the router which allow info to be pulled from it somehow, present a list of unconfigured routers, etc, etc. Point is, I can imagine a lot of ways this could be made user-proof via software/firmware combination that requires no advanced networking knowledge. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvVpywACgkQ2fXFxl4S7sSCuwCg07Gwxz6NDYuTkVYr5gP5LUMC n4EAoIdqZQ7C/01X0EcV3vnZiTD4b7Vc =hDQN -END PGP SIGNATURE-
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Apr 26, 2010, at 5:27 AM, Tony Hoyle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/04/2010 08:08, Mark Smith wrote: How much do you understand about IPv6 addressing? Are you aware that IPv6 addresses have explicit preferred and valid lifetimes, and therefore they can change over time? Only via privacy extensions.. and I always switch them off as they're a pain in the neck. Even with those they don't change the prefix. Uh, no... If you're using slack, IPv6 addresses have explicit preferred and valid lifetimes for the PREFIX which can change over time at the decision of the person running the device(s) issuing the RAs. My /48 is allocated to me.. In no sane world would that suddenly change, unless I did something major like change ISP, any more than my v4 address would suddenly change. Agreed, mostly. If your provider issues your /48 to you via DHCP-PD, then, it, too, has a desired and valid lifetime which is expected to be passed along in your subordinate RAs, and, it means that if they reconfigure their DHCP server, you are expected to abide by the change. You're trying to say ipv6 prefixes change randomly over time - just think of the implications if that could happen... even basic things like firewalling would become a nightmare. Whether they do or not depends on your circumstance and the design of upstream networks. They may or may not. Certainly it is desirable from a customer perspective that they do not. It may be equally desirable from a carrier perspective that they do. Personally, I hope carriers will design their networks well enough that changing prefixes at random times is not necessary and customers can get a better IPv6 experience. We, for one, use static assignments at HE. Owen
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Mon, Apr 26, 2010 at 11:01 AM, Owen DeLong o...@delong.com wrote: We, for one, use static assignments at HE. HE.net provides a fine tunneled service, they have a limited number of 'pops', so it can afford to split their initial allocation up into very large chunks ... look at the typical DSL/cable deployment, splitting of headends and or pops COULD cause outgrowth of the initial pop-level allocation and forcing a re-addressing of the downstream users, if keeping some aggregation is relevant to the provider. I hear HE is headed back to their local RIR for another allocation though, eh? -chris
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
Owen DeLong wrote: Whether they do or not depends on your circumstance and the design of upstream networks. They may or may not. Certainly it is desirable from a customer perspective that they do not. It may be equally desirable from a carrier perspective that they do. Personally, I hope carriers will design their networks well enough that changing prefixes at random times is not necessary and customers can get a better IPv6 experience. I won't say that it never changes, but generally it has not. Prefix is 2607:F780:1::/48 assign /60 prefix 1 entries in use, 4095 available, 0 rejected 0 entries cached, 1000 maximum UserPrefix Interface 0001000110D1D32C001 2607:F780:1::/60AT5/0.14250 I presume it will stay the same as long as cache works. Jack
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Apr 26, 2010, at 7:20 AM, Stephen Sprunk wrote: On 24 Apr 2010 21:01, Mark Smith wrote: On Thu, 22 Apr 2010 01:48:18 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Wed, Apr 21, 2010 at 5:47 PM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: So what happens when you change providers? How are you going to keep using globals that now aren't yours? use pi space, request it from your local friendly RIR. I was hoping that wasn't going to be your answer. So do you expect every residential customer to get a PI from an RIR? The vast majority of residential customers have no idea what globals or PI are. They use PA and they're fine with that--despite being forcibly renumbered every few hours/days. (Many ISPs deliberately tune their DHCP servers to give residential customers a different address each time for market segmentation reasons.) The majority of residential cusotmers bitch about paying $20/month for what they have and are not planning to multihome. This was a comment about multihoming. FWIW, this residential user has PI from an RIR (v4 and v6) and is multihomed using it. It works fine. The only semi-rational justification for ULA-C is that organizations privately internetworking with other organizations are scared of ULA-R collisions. However, PI solves that problem just as readily. If one cannot afford or qualify for PI, or one wants a non-PI prefix due to delusions of better security, one can use a private deconfliction registry, e.g. http://www.sixxs.net/tools/grh/ula/. The claim being made which I was attempting to refute had nothing to do with residential. IT was that ULA-C with NAT at the border would allow an organization to semi-transparently switch back and forth between providers. This is a (somewhat) common practice in IPv4 for delivering (degraded) multihoming. Owen
RE: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
While I appreciate Bill's attempt to raise attention to the draft, I needed to update it anyway with the intent to greatly simplify things and hopefully clarify at the same time. Given the interest level in this thread, I will ask for comments here before publishing the updated I-D. Replace intro paragraph 2 with: In any case, the prefixes defined here are not expected to appear in the routing system for the global Internet. A frequent question is how this prefix differs from a PI assignment. The simple answer is in expectation of global public routability. A PI assignment has the expectation that it could appear in the global DFZ, where a ULA-C registration is expected to be limited reach as service providers are free to, and expected to filter the entire FC00::/7 prefix as bogon space. The appropriate use of these prefixes is within a single network administration, or between privately interconnected networks that want to ensure that private communications do not accidentally get routed over the public Internet as might happen with PI. Replace section 3.2 3.3 with: Global IDs MUST be allocated under a single allocation and registration authority. The IAB SHOULD designate IANA as the registration authority. As policies differ around the world, IANA SHOULD delegate to the RIRs in a manner similar to the /12 approach used for the 2000::/3 prefix. The RIRs SHOULD establish registration policies which recognize that ULA-C prefixes are not a threat to the global DFZ, and therefore easier to justify. Organizations that don't want an ongoing relationship with the RIRs SHOULD be directed to RFC 4193. The requirements for ULA-C allocation and registrations are: - Globally Unique. - Available to anyone in an unbiased manner. - Available as a single prefix when justified to align subnet structures with PA or PI. Other clean up as necessary to align with this simplified text. The point is to remove as much policy as possible from the IETF text, and leave that to each region. Comments welcome, and to the extent they are operationally related to the DFZ could remain on nanog, but otherwise should be on the IETF 6man list. Tony -Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Monday, April 26, 2010 8:33 AM To: Stephen Sprunk Cc: North American Noise and Off-topic Gripes Subject: Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] On Apr 26, 2010, at 7:20 AM, Stephen Sprunk wrote: On 24 Apr 2010 21:01, Mark Smith wrote: On Thu, 22 Apr 2010 01:48:18 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Wed, Apr 21, 2010 at 5:47 PM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: So what happens when you change providers? How are you going to keep using globals that now aren't yours? use pi space, request it from your local friendly RIR. I was hoping that wasn't going to be your answer. So do you expect every residential customer to get a PI from an RIR? The vast majority of residential customers have no idea what globals or PI are. They use PA and they're fine with that--despite being forcibly renumbered every few hours/days. (Many ISPs deliberately tune their DHCP servers to give residential customers a different address each time for market segmentation reasons.) The majority of residential cusotmers bitch about paying $20/month for what they have and are not planning to multihome. This was a comment about multihoming. FWIW, this residential user has PI from an RIR (v4 and v6) and is multihomed using it. It works fine. The only semi-rational justification for ULA-C is that organizations privately internetworking with other organizations are scared of ULA- R collisions. However, PI solves that problem just as readily. If one cannot afford or qualify for PI, or one wants a non-PI prefix due to delusions of better security, one can use a private deconfliction registry, e.g. http://www.sixxs.net/tools/grh/ula/. The claim being made which I was attempting to refute had nothing to do with residential. IT was that ULA-C with NAT at the border would allow an organization to semi-transparently switch back and forth between providers. This is a (somewhat) common practice in IPv4 for delivering (degraded) multihoming. Owen
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
Subject: Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Date: Sun, Apr 25, 2010 at 11:31:06AM +0930 Quoting Mark Smith (na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org): So what happens when you change providers? How are you going to keep using globals that now aren't yours? use pi space, request it from your local friendly RIR. I was hoping that wasn't going to be your answer. So do you expect every residential customer to get a PI from an RIR? No, won't be necessary. Typical leases on v4 are extremely stable. I see no reason why they should be less so -- bar implementation hickups -- in v6. My dynamic v4 address of my Telia DSL at home has been the same for over a year. The ISP that messes this up will lose customers. As long as we use self-healing reasonably abstracted means of pointing out where our stuff is we'll easily survive renumbering should it occur. As long as the renumbering is less frequent than the TTL on the DNS records. For DLNA-like stuff, there is always FE80::/10, besides. The uniqueness of the unicast IP address is the key to its value and the means with which it enables us to build new stuff from which we make money. Corrupting the uniqueness requirement is devaluing the real reach and power of the IP address in search of shortsighted futile gains and is a practice any network professional should abstain from. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 As President I have to go vacuum my coin collection! pgpiRLW0QQMJg.pgp Description: PGP signature
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/04/2010 03:01, Mark Smith wrote: I'm a typical, fairly near future residential customer. I have a NAS that I have movies stored on. My ISP delegates an IPv6 prefix to me with a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes What ISP would put a 'lifetime' on your ipv6 prefix? That seems insane to me... they should give you a /48 and be done with it. Even the free tunnel brokers do that. But then I never understood dynamic ipv4 either Tony -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL1F0BAAoJEJ1qCQ6ePCDUKnkH/iwae1SessBxQ708eLennoZV Zmy+2jSABgQtY+GTpqkXzn/Tr5tXWJfq4+ONx4N0SfA6e2asKkUtf6+/ZzWx/gUA EmCQ966HIMdJoCGeFc4snCMm6vOe+fqRcZA0BqGbF6bEkctuyEETVlr6jDfFXqcA oFwibApR/GmBOd/1IfMh3dNjHEt4XtfoL9BUqOUiPzfI2+xByaHfh3I04yskFZkf 7EDW+JVbMA9w9Hy6M1nsggHijETpBKiDsHusrFhRaq9h6NdL8Ypf0D4+DIluGuOR zuAcrOCu1dd3Y4fLkOwej7z1C5QDMLluToUQhCljua6agOhzJKsh5u4Acfc0Wik= =NtLo -END PGP SIGNATURE-
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On 4/25/2010 10:17, Tony Hoyle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/04/2010 03:01, Mark Smith wrote: I'm a typical, fairly near future residential customer. I have a NAS that I have movies stored on. My ISP delegates an IPv6 prefix to me with a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes What ISP would put a 'lifetime' on your ipv6 prefix? That seems insane to me... they should give you a /48 and be done with it. Even the free tunnel brokers do that. But then I never understood dynamic ipv4 either +1 Tony -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL1F0BAAoJEJ1qCQ6ePCDUKnkH/iwae1SessBxQ708eLennoZV Zmy+2jSABgQtY+GTpqkXzn/Tr5tXWJfq4+ONx4N0SfA6e2asKkUtf6+/ZzWx/gUA EmCQ966HIMdJoCGeFc4snCMm6vOe+fqRcZA0BqGbF6bEkctuyEETVlr6jDfFXqcA oFwibApR/GmBOd/1IfMh3dNjHEt4XtfoL9BUqOUiPzfI2+xByaHfh3I04yskFZkf 7EDW+JVbMA9w9Hy6M1nsggHijETpBKiDsHusrFhRaq9h6NdL8Ypf0D4+DIluGuOR zuAcrOCu1dd3Y4fLkOwej7z1C5QDMLluToUQhCljua6agOhzJKsh5u4Acfc0Wik= =NtLo -END PGP SIGNATURE- -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Apr 25, 2010, at 8:17 AM, Tony Hoyle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/04/2010 03:01, Mark Smith wrote: I'm a typical, fairly near future residential customer. I have a NAS that I have movies stored on. My ISP delegates an IPv6 prefix to me with a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes What ISP would put a 'lifetime' on your ipv6 prefix? That seems insane to me... they should give you a /48 and be done with it. Even the free tunnel brokers do that. But then I never understood dynamic ipv4 either If they are using DHCP-PD, then, it comes with a lifetime whether it is static or not. The reality is that unless they need to renumber you, you'll probably get a new RA with the 60/90 minute lifetimes specified each time RAs are sent and your counters will all get reset to 60/90 for the foreseeable future. The preferred and valid lifetimes aren't limitations, they're minimums. The prefix should be yours and should be functional for you for AT LEAST the valid lifetime. Owen
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
What ISP would put a 'lifetime' on your ipv6 prefix? That seems insane to me... they should give you a /48 and be done with it. Even the free tunnel brokers do that. But then I never understood dynamic ipv4 either Dynamic IPv4 isn't too difficult to understand. There are two main arguments: - Dynamic addresses is a way to differentiate residential customers (who pay less) from business customers (who pay more). - Dynamic addresses makes it much easier to handle customers in bulk. You can have *one* standardized form of DNS info (forward/reverse), no customer defined DNS at all. You can easily move customers to a new aggregation box when the current box is reaching max capacity - just remember to lower your DHCP lease time beforehand. You may not need to alert customers individually as long as work is done within your well defined service windows. etc etc. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Apr 25, 2010, at 9:11 AM, sth...@nethelp.no wrote: What ISP would put a 'lifetime' on your ipv6 prefix? That seems insane to me... they should give you a /48 and be done with it. Even the free tunnel brokers do that. But then I never understood dynamic ipv4 either Dynamic IPv4 isn't too difficult to understand. There are two main arguments: - Dynamic addresses is a way to differentiate residential customers (who pay less) from business customers (who pay more). Which is both specious and obnoxious. Given a choice between a provider which does this and one who does not, I will always choose the one that does not. Unfortunately, there is no PON vendor in my area, so I live with com cast business (on a dynamic IP because I refuse to pay their absurd mark-up on IP addresses). Given a PON vendor in my neighborhood, I'd drop Comcast in a heartbeat. - Dynamic addresses makes it much easier to handle customers in bulk. You can have *one* standardized form of DNS info (forward/reverse), no customer defined DNS at all. You can easily move customers to a new aggregation box when the current box is reaching max capacity - just remember to lower your DHCP lease time beforehand. You may not need to alert customers individually as long as work is done within your well defined service windows. etc etc. This is true. However, I'd be willing to pay some amount to cover this difference. Interestingly, Comcast is the only provider where I've been unable to get a static address on a residential plan at any price. They're also the only provider that has tried to charge more for a static on business service. Steinar Haug, Nethelp consulting, sth...@nethelp.no Owen
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Sun, 25 Apr 2010 13:21:16 -0400 Richard Barnes richard.bar...@gmail.com wrote: Moreover, the general point stands that Mark's problem is one of bad ISP decisions, not anything different between IPv4/RFC1918 and IPv6. My example, although a bit convoluted to demonstrate a point, is about robustness against Internet link failure. I don't think people's internal connectivity should be dependent on their Internet link being available and being assigned global address space. That's what the global only people are saying. (how is the customer going to access the CPE webserver to enter ISP login details when they get the CPE out of the box, if hasn't got address space because it hasn't connected to the ISP ...) On Sun, Apr 25, 2010 at 11:48 AM, Owen DeLong o...@delong.com wrote: On Apr 25, 2010, at 8:17 AM, Tony Hoyle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/04/2010 03:01, Mark Smith wrote: I'm a typical, fairly near future residential customer. I have a NAS that I have movies stored on. My ISP delegates an IPv6 prefix to me with a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes What ISP would put a 'lifetime' on your ipv6 prefix? That seems insane to me... they should give you a /48 and be done with it. Even the free tunnel brokers do that. But then I never understood dynamic ipv4 either If they are using DHCP-PD, then, it comes with a lifetime whether it is static or not. The reality is that unless they need to renumber you, you'll probably get a new RA with the 60/90 minute lifetimes specified each time RAs are sent and your counters will all get reset to 60/90 for the foreseeable future. The preferred and valid lifetimes aren't limitations, they're minimums. The prefix should be yours and should be functional for you for AT LEAST the valid lifetime. Owen
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Sun, 25 Apr 2010 16:17:21 +0100 Tony Hoyle t...@hoyle.me.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/04/2010 03:01, Mark Smith wrote: I'm a typical, fairly near future residential customer. I have a NAS that I have movies stored on. My ISP delegates an IPv6 prefix to me with a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes What ISP would put a 'lifetime' on your ipv6 prefix? Because they loan it to you while you are their customer. Unless you get PI, you don't 'own' your addresses, so you can't take them with you when you change ISPs. In IPv4 a lifetime is implicit, which might be as long/short as while your current connection is up, in IPv6 it is explicit. (other people who've responded have provided other valid reasons, so I won't repeat them) That seems insane to me... they should give you a /48 and be done with it. Even the free tunnel brokers do that. No they don't. They set a lifetime too, and if you change tunnel broker, you don't get to keep using the same addresses. But then I never understood dynamic ipv4 either Tony -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL1F0BAAoJEJ1qCQ6ePCDUKnkH/iwae1SessBxQ708eLennoZV Zmy+2jSABgQtY+GTpqkXzn/Tr5tXWJfq4+ONx4N0SfA6e2asKkUtf6+/ZzWx/gUA EmCQ966HIMdJoCGeFc4snCMm6vOe+fqRcZA0BqGbF6bEkctuyEETVlr6jDfFXqcA oFwibApR/GmBOd/1IfMh3dNjHEt4XtfoL9BUqOUiPzfI2+xByaHfh3I04yskFZkf 7EDW+JVbMA9w9Hy6M1nsggHijETpBKiDsHusrFhRaq9h6NdL8Ypf0D4+DIluGuOR zuAcrOCu1dd3Y4fLkOwej7z1C5QDMLluToUQhCljua6agOhzJKsh5u4Acfc0Wik= =NtLo -END PGP SIGNATURE-
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
In message u2j88ac5c711004251021q54694443l687b8f6aa78c4...@mail.gmail.com, Richard Barnes writes: Moreover, the general point stands that Mark's problem is one of bad ISP decisions, not anything different between IPv4/RFC1918 and IPv6. Actually one needs to deploy a ULA or have PI addresses to handle external link down events that are long enough to cause any provider supplied addresses to expire. With address selection rules setup so that you prefer ULA over non-ULA for intra site it just works. For some services you only advertise a ULA address even if the host machine has both. I was disscussing how a CPE device should be advertising DNS severs in DHCP and decided that adverising ULA addresses for the DNS proxy/forewarding server was the best way to do this. Mark On Sun, Apr 25, 2010 at 11:48 AM, Owen DeLong o...@delong.com wrote: On Apr 25, 2010, at 8:17 AM, Tony Hoyle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/04/2010 03:01, Mark Smith wrote: I'm a typical, fairly near future residential customer. I have a NAS that I have movies stored on. My ISP delegates an IPv6 prefix to me wit= h a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes What ISP would put a 'lifetime' on your ipv6 prefix? =A0That seems insan= e to me... they should give you a /48 and be done with it. =A0Even the fre= e tunnel brokers do that. But then I never understood dynamic ipv4 either If they are using DHCP-PD, then, it comes with a lifetime whether it is static or not. The reality is that unless they need to renumber you, you'll probably get a new RA with the 60/90 minute lifetimes specified each time RAs are sent and your counters will all get reset to 60/90 for the foreseeable future. =A0The preferred and valid lifetimes aren't limitations, they're minimums. =A0The prefix should be yours and should be functional for you for AT LEAST the valid lifetime. Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Mon, Apr 26, 2010 at 08:20:33AM +0930, Mark Smith wrote: On Sun, 25 Apr 2010 13:21:16 -0400 Richard Barnes richard.bar...@gmail.com wrote: Moreover, the general point stands that Mark's problem is one of bad ISP decisions, not anything different between IPv4/RFC1918 and IPv6. My example, although a bit convoluted to demonstrate a point, is about robustness against Internet link failure. I don't think people's internal connectivity should be dependent on their Internet link being available and being assigned global address space. That's what the global only people are saying. (how is the customer going to access the CPE webserver to enter ISP login details when they get the CPE out of the box, if hasn't got address space because it hasn't connected to the ISP ...) I've been using IPv6 for about 18 seconds, and even *I* know the answer to that one -- the link-local address. - Matt -- You are capable, creative, competent, careful. Prove it. -- Seen in a fortune cookie
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Apr 25, 2010, at 3:50 PM, Mark Smith wrote: On Sun, 25 Apr 2010 13:21:16 -0400 Richard Barnes richard.bar...@gmail.com wrote: Moreover, the general point stands that Mark's problem is one of bad ISP decisions, not anything different between IPv4/RFC1918 and IPv6. My example, although a bit convoluted to demonstrate a point, is about robustness against Internet link failure. I don't think people's internal connectivity should be dependent on their Internet link being available and being assigned global address space. That's what the global only people are saying. Your internet connectivity, by definition, depends on an internet link being available. No link, no connection. Simple as that. Now, if you're talking about multihoming, I, as one of the global only people, am suggesting that you get your global addresses from ARIN and advertise it to both of your upstreams. I know this is not popular with many of the ISPs out there because there is a cost to that and a scale factor that still has yet to be addressed in the IP routing paradigm. However, I think that will happen anyway. Alternatively, even if you want to do some funky NAT-based solution, there's nothing wrong with using GUA on the internal side of the NAT to your PA prefixes outside. That way, when you get the opportunity to remove that NAT cruft from your environment, you already have usable addresses and you don't have to renumber. (how is the customer going to access the CPE webserver to enter ISP login details when they get the CPE out of the box, if hasn't got address space because it hasn't connected to the ISP ...) That's what Link Local is for. fe80::EUI-64%interface For example, if the CPE is connected to the customer's network on eth0 and the CPE mac address is 00:45:4b:b9:02:be, you could go to: http://[fe80::0245:4bff:feb9:02be]%eth0 Owen On Sun, Apr 25, 2010 at 11:48 AM, Owen DeLong o...@delong.com wrote: On Apr 25, 2010, at 8:17 AM, Tony Hoyle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/04/2010 03:01, Mark Smith wrote: I'm a typical, fairly near future residential customer. I have a NAS that I have movies stored on. My ISP delegates an IPv6 prefix to me with a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes What ISP would put a 'lifetime' on your ipv6 prefix? That seems insane to me... they should give you a /48 and be done with it. Even the free tunnel brokers do that. But then I never understood dynamic ipv4 either If they are using DHCP-PD, then, it comes with a lifetime whether it is static or not. The reality is that unless they need to renumber you, you'll probably get a new RA with the 60/90 minute lifetimes specified each time RAs are sent and your counters will all get reset to 60/90 for the foreseeable future. The preferred and valid lifetimes aren't limitations, they're minimums. The prefix should be yours and should be functional for you for AT LEAST the valid lifetime. Owen
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/04/2010 23:53, Mark Smith wrote: On Sun, 25 Apr 2010 16:17:21 +0100 Tony Hoyle t...@hoyle.me.uk wrote: On 25/04/2010 03:01, Mark Smith wrote: I'm a typical, fairly near future residential customer. I have a NAS that I have movies stored on. My ISP delegates an IPv6 prefix to me with a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes What ISP would put a 'lifetime' on your ipv6 prefix? Because they loan it to you while you are their customer. Unless you get PI, you don't 'own' your addresses, so you can't take them with you when you change ISPs. In IPv4 a lifetime is implicit, which might be as long/short as while your current connection is up, in IPv6 it is explicit. That's not what 'lifetime' means in this discusion. They're talking about v6 addresses changing when you're with the same provider - indeed, when logged into the same link even. That's insane. A change of ISP is a major change. Your ipv4 addresses will change as well if you change ISP. As you say, if you don't want them to change get PI space. v6 and v4 are no different in this respect. Tony -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL1NRJAAoJEJ1qCQ6ePCDUDeQH/07EZ2uBb5E2Is5juO1NCp4S BYl36VnSIwmadVZpQxJ2tmrJB2jKGV2sV4K0hJ/QRHRNK0k0CJv2k/KWPf8sis6p v6bDjnHD1k4bSTxuwEgRbAbPB5uDpRaw7F2ItgdNKGmf8KZh+tCX4uYZ3Pger0Q9 BEE6y/PjDlgk+ZW+BX6Jgp5raBC9gWu0hiFIhiIRXxmUNgKmJpaRsc6DH5jC5Hch BhrDxvHZCMNpG2KH32w9D955FSHBCt/ih/hNEB36yDTiln4gMx99jKquECeZrujJ zX1+sZ0DtLGR3oFjXyXfVS+8Y13i2fLYfQ1g5l/dhXGGs+Nwwb0ska8K+D5Tza0= =cgpi -END PGP SIGNATURE-
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/04/2010 00:32, Matthew Palmer wrote: I've been using IPv6 for about 18 seconds, and even *I* know the answer to that one -- the link-local address. It should respond at ff02::2 as well (at least to a ping, so you can get the LL address if you don't know it). Tony -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL1NWbAAoJEJ1qCQ6ePCDU2ScIANFCWKUhc7zfs0ajLL1fkUNe 7DR4LlStfh1XQArQ50eBVmCLpZGrx8bWcluT+PUHSnQve2lLkLKB6MIbrJ4ezc8g sa/hIcpPKioLpAuQr9q3HEPqqiIJ58119wIVGdglWPEeyjlWZih+n6wWoZ4WVeFK aKXXdhE5s8QhZeUEzDioktxl9r1wRQK+ecFYWWF8K9sHd4ePwViyfsk7xnLhaWxp /98BlYGeKMgMfLGH1aNxVYwbEM77KOqXcJbN1Gc2QB03wi4RJyw9/45dR+dzeSbn LrbWmulqBi79Jv9InPY6FNqf8RjYspl2a+hXiRLimW2yNcp19W5f9Wrh1/7v6JE= =3opf -END PGP SIGNATURE-
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On 04/25/10 16:42, Owen DeLong wrote: That's what Link Local is for. fe80::EUI-64%interface For example, if the CPE is connected to the customer's network on eth0 and the CPE mac address is 00:45:4b:b9:02:be, you could go to: http://[fe80::0245:4bff:feb9:02be]%eth0 ... and regardless of the specific method, the vendors already document the procedure for connecting to the web interface for IPv4, there is no reason to believe that they could not or would not do the same for IPv6 if necessary. -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Sun, 25 Apr 2010, Doug Barton wrote: On 04/25/10 16:42, Owen DeLong wrote: That's what Link Local is for. fe80::EUI-64%interface For example, if the CPE is connected to the customer's network on eth0 and the CPE mac address is 00:45:4b:b9:02:be, you could go to: http://[fe80::0245:4bff:feb9:02be]%eth0 ... and regardless of the specific method, the vendors already document the procedure for connecting to the web interface for IPv4, there is no reason to believe that they could not or would not do the same for IPv6 if necessary. Does anyone actually believe that the above is user-friendly and will work in real life? Using link-local for this kind of end-user administration of their equipment is doomed to fail. There needs to be a procedure for devices which are going to get DHCP-PD from the provider, that they have a certain prefix they use until they actually get the real PD prefix, so end user dns etc works so it's easy to do administration of the device. We can't expect end-users to do the above procedure. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Mon, 26 Apr 2010 09:32:30 +1000 Matthew Palmer mpal...@hezmatt.org wrote: On Mon, Apr 26, 2010 at 08:20:33AM +0930, Mark Smith wrote: On Sun, 25 Apr 2010 13:21:16 -0400 Richard Barnes richard.bar...@gmail.com wrote: Moreover, the general point stands that Mark's problem is one of bad ISP decisions, not anything different between IPv4/RFC1918 and IPv6. My example, although a bit convoluted to demonstrate a point, is about robustness against Internet link failure. I don't think people's internal connectivity should be dependent on their Internet link being available and being assigned global address space. That's what the global only people are saying. (how is the customer going to access the CPE webserver to enter ISP login details when they get the CPE out of the box, if hasn't got address space because it hasn't connected to the ISP ...) I've been using IPv6 for about 18 seconds, and even *I* know the answer to that one -- the link-local address. Ever tried to ping a link local address? If you've been using IPv6 for only 18 seconds, probably not. Try it some time, hopefully you'll work out what the issue with using LLs is. - Matt -- You are capable, creative, competent, careful. Prove it. -- Seen in a fortune cookie
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On 04/25/10 19:37, Mikael Abrahamsson wrote: On Sun, 25 Apr 2010, Doug Barton wrote: ... and regardless of the specific method, the vendors already document the procedure for connecting to the web interface for IPv4, there is no reason to believe that they could not or would not do the same for IPv6 if necessary. Does anyone actually believe that the above is user-friendly and will work in real life? Sorry, I knew that I shouldn't have helped perpetuate this thread, which (IMO) is already way off topic. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Mon, 26 Apr 2010 12:31:51 +0930 Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Mon, 26 Apr 2010 09:32:30 +1000 Matthew Palmer mpal...@hezmatt.org wrote: On Mon, Apr 26, 2010 at 08:20:33AM +0930, Mark Smith wrote: On Sun, 25 Apr 2010 13:21:16 -0400 Richard Barnes richard.bar...@gmail.com wrote: Moreover, the general point stands that Mark's problem is one of bad ISP decisions, not anything different between IPv4/RFC1918 and IPv6. My example, although a bit convoluted to demonstrate a point, is about robustness against Internet link failure. I don't think people's internal connectivity should be dependent on their Internet link being available and being assigned global address space. That's what the global only people are saying. (how is the customer going to access the CPE webserver to enter ISP login details when they get the CPE out of the box, if hasn't got address space because it hasn't connected to the ISP ...) I've been using IPv6 for about 18 seconds, and even *I* know the answer to that one -- the link-local address. Ever tried to ping a link local address? If you've been using IPv6 for only 18 seconds, probably not. Try it some time, hopefully you'll work out what the issue with using LLs is. To make it easier, here's a clue: $ ip -6 route show | grep fe80 fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev tun6to4 proto kernel metric 256 mtu 1472 advmss 1412 hoplimit 4294967295 fe80::/64 dev pan0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 (eth1 is my wired/wireless LAN, tun6to4 is my IPv6 6to4 tunnel, and pan0 is my bluetooth LAN) - Matt -- You are capable, creative, competent, careful. Prove it. -- Seen in a fortune cookie
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
Mikael Abrahamsson wrote: Does anyone actually believe that the above is user-friendly and will work in real life? Using link-local for this kind of end-user administration of their equipment is doomed to fail. There needs to be a procedure for devices which are going to get DHCP-PD from the provider, that they have a certain prefix they use until they actually get the real PD prefix, so end user dns etc works so it's easy to do administration of the device. Last 3 cheap routers. BIG STICKER: INSTALL SOFTWARE BEFORE YOU PLUG THIS ROUTER IN! I doubt many users even use the old goto http://192.168.1.1/; anymore. That being said, there are private addressing schemes in IPv6 as well. No reason one could be bound to a cpe router with an easy to type address. Jack
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Sun, 25 Apr 2010, Jack Bates wrote: Last 3 cheap routers. BIG STICKER: INSTALL SOFTWARE BEFORE YOU PLUG THIS ROUTER IN! I doubt many users even use the old goto http://192.168.1.1/; anymore. That being said, there are private addressing schemes in IPv6 as well. No reason one could be bound to a cpe router with an easy to type address. Yeah, and when I try that on my linux box it won,t install the software for some reason. we need solutions that are cross platform and open, let's not help microsoft any further, thank you. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Sun, 25 Apr 2010 16:42:31 -0700 Owen DeLong o...@delong.com wrote: On Apr 25, 2010, at 3:50 PM, Mark Smith wrote: On Sun, 25 Apr 2010 13:21:16 -0400 Richard Barnes richard.bar...@gmail.com wrote: Moreover, the general point stands that Mark's problem is one of bad ISP decisions, not anything different between IPv4/RFC1918 and IPv6. My example, although a bit convoluted to demonstrate a point, is about robustness against Internet link failure. I don't think people's internal connectivity should be dependent on their Internet link being available and being assigned global address space. That's what the global only people are saying. Your internet connectivity, by definition, depends on an internet link being available. No link, no connection. Simple as that. Now, if you're talking about multihoming, I, as one of the global only people, am suggesting that you get your global addresses from ARIN and advertise it to both of your upstreams. I know this is not popular with many of the ISPs out there because there is a cost to that and a scale factor that still has yet to be addressed in the IP routing paradigm. However, I think that will happen anyway. Alternatively, even if you want to do some funky NAT-based solution, there's nothing wrong with using GUA on the internal side of the NAT to your PA prefixes outside. That way, when you get the opportunity to remove that NAT cruft from your environment, you already have usable addresses and you don't have to renumber. (how is the customer going to access the CPE webserver to enter ISP login details when they get the CPE out of the box, if hasn't got address space because it hasn't connected to the ISP ...) That's what Link Local is for. fe80::EUI-64%interface For example, if the CPE is connected to the customer's network on eth0 and the CPE mac address is 00:45:4b:b9:02:be, you could go to: http://[fe80::0245:4bff:feb9:02be]%eth0 Would you want to be asking residential customers (your other half, mother, father, sister etc. - not a tech like you) to work that out and then type that in? Would you want to be running the helpdesk that supports those customers, considering the chance of error there is (selecting the wrong interface, typos etc. etc.) The IPv6 Internet needs to be at least as user friendly as IPv4, so asking residential customers to type in anything harder than an IPv4 address is unacceptable. Adding in an interface name to a literal IPv6 address is effectively specifying a subnet, without specifying a subnet. ULAs (announced in RAs) make this easier, because you're not creating the requirement for applications to have to understand both literal LL IPv6 addresses as well as qualifying interface names. Regards, Mark.
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On 04/22/2010 11:23 AM, Christopher Morrow wrote: On Thu, Apr 22, 2010 at 12:13 PM, Bill Bogstad bogs...@pobox.com wrote: On Thu, Apr 22, 2010 at 11:03 AM, David Conrad d...@virtualized.org wrote: On Apr 21, 2010, at 10:48 PM, Christopher Morrow wrote: So what happens when you change providers? How are you going to keep using globals that now aren't yours? use pi space, request it from your local friendly RIR. And don't forget to invest in memory manufacturers and router vendors :-) Only required if those addresses are advertised to the Internet. Which is apparently NOT what people want to do with it. In addition, it seems like the RIRs frown on not publishing your IPv6 PI allocations. If you go this this is commonly held up as a reason that getting allocations is hard, but the infrastructure micro-allocations are never to be seen in the global table. It woudl be super nice if some kind RIR people could comment here, I believe in the ARIN region all you NEED to do is provide a spreadsheet showing your utilization, checking for the routes in the 'DFZ' (bmanning-summons) isn't relevant for additional requests. route, be sure to 'justify' as large an allocation as you could ever possibly imagine using because you'll only get one bite from that apple. see previous comment, I believe this is a red-herring. An entity that I worked for in the arin recieved an ip6 micro-allocation (/43) under current arin policy. it was our understanding at the time that that 6.5.8.3 was current the criterion for additional assignments. while I could imagine other criterion for being applied the assignment of 4,771 /56 prefixes doesn't seem particularly onerous to document, even if as it happens, it's not particularly aligned with the initial assignment policy which was tied to the number of /48 site subnets that were assigned. Or maybe someone could offer to advertise these deliberately unreachable addresses for a small fee and then null route any stray packets that happen to want to get there. Would this satisfy the letter (if not the spirit) for justifying PI space? you still have to provide SWIP, RWHOIS or some other accounting of the usage (spreadsheet/csvfile seems to be historically acceptable) -chris Bill Bogstad
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Thu, 22 Apr 2010 01:48:18 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Wed, Apr 21, 2010 at 5:47 PM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Wed, 21 Apr 2010 09:25:46 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong o...@delong.com wrote: While I think this is an improvement, unless the distribution of ULA-C is no cheaper and no easier to get than GUA, I still think there is reason to believe that it is likely ULA-C will become de facto GUA over the long term. As such, I still think the current draft is a bad idea absent appropriate protections in RIR policy. I agree with owen, mostly... except I think we should just push RIR's to make GUA accessible to folks that need ipv6 adress space, regardless of connectiivty to thegreater 'internet' (for some definition of that thing). ULA of all types causes headaches on hosts, routers, etc. There is no reason to go down that road, just use GUA (Globally Unique Addresses). So what happens when you change providers? How are you going to keep using globals that now aren't yours? use pi space, request it from your local friendly RIR. I was hoping that wasn't going to be your answer. So do you expect every residential customer to get a PI from an RIR? Here's the scenario: I'm a typical, fairly near future residential customer. I have a NAS that I have movies stored on. My ISP delegates an IPv6 prefix to me with a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes (in my personal opinion, thats too small, but it's the ISP's address space, so I have to accept the lifetimes they give me). I start watching a 2 hour movie, delivered from my NAS to my TV over IPv6, using the GUA addresses (because you're saying I don't ULAs). 5 minutes into the movie, my Internet drops out. 1 hour, 35 minutes into movie, the movies drops out, because the IPv6 addresses used to deliver it can't be used anymore. Is that an acceptable customer networking experience? It won't happen in IPv4, because customers typically have stable RFC1918 addresses. It is unacceptable that it should happen in IPv6, yet you can't expect residential customers to pay RIR fees to get PI address space - and should that even happen, when are we going to have carrier routers that can route 500 Million (my very much rough estimate of houses in the world) routes? The majority of Internet connections are residential. Enterprise solutions, like PI and RIR fees, aren't just feasible for the majority of the Internet. I'm also curious about these headaches. What are they? do I use that ula-* address to talk to someone or another GUA address? how do I decide? what about to business partners? That's why there are source address selection rules in IPv6, that factor in destination address types. one address... much simpler, much less to screw up. I'm all for simplicity. Unfortunately however, to overcome a problem, you usually have to add something, and adding something usually adds complexity. The key goal is to minimise the additional complexity as much as possible, without loosing the benefit. Networks need stable addressing, that is independent of the address space their Internet transit provider loans them. That allows them to change transit providers without disrupting their internal network. In IPv4, RFC1918 gives them that address stability, but then thrusts upon them the issues that NAT and duplicate/overlapping addressing creates. So the goal is: - stable addressing, independent of the stability of your transit provider's addresses that they temporarily loan to you - globally unique, or unique enough that collisions are very unlikely to occur, should you wish to permanently or temporarily interconnect domains (e.g. VPN) - user generated, so there is no cost or need to interact with a central authority and as IPv6 has formalised the support of interfaces having multiple addresses, ULAs suit those requirements. -chris -Chris
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
a few questions. IPv6 on your radar? Looking at options for addressing your future v6 needs? Have you looked at the IETF/ID in the subject line? ULA looks always interesting, but tends to end up in obscurity because the right folks don't buy in. Anyway, the proposal brings IPv6 down to about 40 globally routable bits, compared to 21 to 24 in IPv4. That's still a lot, though. A further simplification would replace the Global ID with the AS number. A real improvement over IPv4 would embed distinct IDs for location and identity of any subnet, but that would probably mean that subnets receive less than 64 bits.
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
Isn't global addresses you can take with you when you change providers kind of the definition of Provider Independent address space? If you want to keep the same addresses when you change providers, you just need to get a PI allocation. --Richard On Wed, Apr 21, 2010 at 5:47 PM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Wed, 21 Apr 2010 09:25:46 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong o...@delong.com wrote: While I think this is an improvement, unless the distribution of ULA-C is no cheaper and no easier to get than GUA, I still think there is reason to believe that it is likely ULA-C will become de facto GUA over the long term. As such, I still think the current draft is a bad idea absent appropriate protections in RIR policy. I agree with owen, mostly... except I think we should just push RIR's to make GUA accessible to folks that need ipv6 adress space, regardless of connectiivty to thegreater 'internet' (for some definition of that thing). ULA of all types causes headaches on hosts, routers, etc. There is no reason to go down that road, just use GUA (Globally Unique Addresses). So what happens when you change providers? How are you going to keep using globals that now aren't yours? I'm also curious about these headaches. What are they? -Chris
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Apr 21, 2010, at 10:48 PM, Christopher Morrow wrote: So what happens when you change providers? How are you going to keep using globals that now aren't yours? use pi space, request it from your local friendly RIR. And don't forget to invest in memory manufacturers and router vendors :-) Regards, -drc
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Thu, Apr 22, 2010 at 11:03 AM, David Conrad d...@virtualized.org wrote: On Apr 21, 2010, at 10:48 PM, Christopher Morrow wrote: So what happens when you change providers? How are you going to keep using globals that now aren't yours? use pi space, request it from your local friendly RIR. And don't forget to invest in memory manufacturers and router vendors :-) Only required if those addresses are advertised to the Internet. Which is apparently NOT what people want to do with it. In addition, it seems like the RIRs frown on not publishing your IPv6 PI allocations. If you go this route, be sure to 'justify' as large an allocation as you could ever possibly imagine using because you'll only get one bite from that apple. Or maybe someone could offer to advertise these deliberately unreachable addresses for a small fee and then null route any stray packets that happen to want to get there. Would this satisfy the letter (if not the spirit) for justifying PI space? Bill Bogstad
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Thu, Apr 22, 2010 at 12:13 PM, Bill Bogstad bogs...@pobox.com wrote: On Thu, Apr 22, 2010 at 11:03 AM, David Conrad d...@virtualized.org wrote: On Apr 21, 2010, at 10:48 PM, Christopher Morrow wrote: So what happens when you change providers? How are you going to keep using globals that now aren't yours? use pi space, request it from your local friendly RIR. And don't forget to invest in memory manufacturers and router vendors :-) Only required if those addresses are advertised to the Internet. Which is apparently NOT what people want to do with it. In addition, it seems like the RIRs frown on not publishing your IPv6 PI allocations. If you go this this is commonly held up as a reason that getting allocations is hard, but the infrastructure micro-allocations are never to be seen in the global table. It woudl be super nice if some kind RIR people could comment here, I believe in the ARIN region all you NEED to do is provide a spreadsheet showing your utilization, checking for the routes in the 'DFZ' (bmanning-summons) isn't relevant for additional requests. route, be sure to 'justify' as large an allocation as you could ever possibly imagine using because you'll only get one bite from that apple. see previous comment, I believe this is a red-herring. Or maybe someone could offer to advertise these deliberately unreachable addresses for a small fee and then null route any stray packets that happen to want to get there. Would this satisfy the letter (if not the spirit) for justifying PI space? you still have to provide SWIP, RWHOIS or some other accounting of the usage (spreadsheet/csvfile seems to be historically acceptable) -chris Bill Bogstad
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
believe in the ARIN region all you NEED to do is provide a spreadsheet showing your utilization, checking for the routes in the 'DFZ' (bmanning-summons) isn't relevant for additional requests. ... all circuits are busy, please call back later... -chris --bill
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Apr 22, 2010, at 9:13 AM, Bill Bogstad wrote: On Thu, Apr 22, 2010 at 11:03 AM, David Conrad d...@virtualized.org wrote: On Apr 21, 2010, at 10:48 PM, Christopher Morrow wrote: So what happens when you change providers? How are you going to keep using globals that now aren't yours? use pi space, request it from your local friendly RIR. And don't forget to invest in memory manufacturers and router vendors :-) Only required if those addresses are advertised to the Internet. Which is apparently NOT what people want to do with it. In addition, it seems like the RIRs frown on not publishing your IPv6 PI allocations. If you go this route, be sure to 'justify' as large an allocation as you could ever possibly imagine using because you'll only get one bite from that apple. We're working on policy to address that within the ARIN region. I suspect it will get addressed elsewhere as well. The bigger concern (and original intent of the phrases driving that concern) was that it be advertised as a single prefix and not multiple prefixes hitting the DFZ. Owen
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Wed, 21 Apr 2010 01:46:47 -0400 Daniel Senie d...@senie.com wrote: I see a need for stable, permanent blocks of addresses within an organization. For example, a branch office connecting to a central office over VPN: firewall rules need to be predictable. If the branch office' IPv6 block changes, much access will break. This is directly analogous to how RFC1918 space is used today in such environments. There is a need to have organizations be able to either self-assign or RIR-assign space that they own and can use without trouble within their network. That address space need not be routable on the public networks. In general I think this draft has merit. Unique Local Adresses, of which the linked draft is specifying a subset, were specified in RFC4193, published in October 2005. They meet all the requirements you've stated. You might also want to have a look at RFC3879, Deprecating Site Local Addresses for the reasons why IPv6 Site Local addresses, the direct IPv6 equivalent of RFC1918 addresses, were deprecated. Many of the reasons provided also apply to using IPv4 RFC1918 addresses. This draft is about a centralised registry for one half of the ULA space. It is debatable whether it is necessary, as ULAs shouldn't leak out of a site using them. The major concern is that if they are globally registered, then some people will start believing that they can use them as global addresses, and start demanding other parties such as their ISP or IXes route them, instead of getting proper global addresses for that purpose. As an example of the risks, an informal registry for non-central ULAs has been created at sixxs.net. As a single ULA /48 should be enough for most organisations, looking at the list, it seems that some people are already attempting an addressing 'land grab'. I can't even reach the website of one of the people who as registered 7 /48s. It's a bit hard to believe he has a large enough network to need 458 752 subnets ... http://www.sixxs.net/tools/grh/ula/list/ I think the fact that people have listed them there also means that they now think they now globally 'own' those addresses, and should there be a (very unlikely) collision, would argue that the address space was theirs first and point to that list. While duplicated ULAs shouldn't happen, it shouldn't matter if it does, unless those two organisations want to interconnect directly. ULAs are meant to be stable addressing for inside of your network. They are not meant to be leaked outside your network under most circumstances. The only time routes for your ULA address space may appear outside of your network is if you have a direct link to another organisation (i.e. a backdoor link), and you want to avoid using your Internet transit to reach them and vice-versa. In BGP terms, when you announce some of your ULA address space to the other organisation, you'd attach a NO_EXPORT community. Regards, Mark.
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong o...@delong.com wrote: While I think this is an improvement, unless the distribution of ULA-C is no cheaper and no easier to get than GUA, I still think there is reason to believe that it is likely ULA-C will become de facto GUA over the long term. As such, I still think the current draft is a bad idea absent appropriate protections in RIR policy. I agree with owen, mostly... except I think we should just push RIR's to make GUA accessible to folks that need ipv6 adress space, regardless of connectiivty to thegreater 'internet' (for some definition of that thing). ULA of all types causes headaches on hosts, routers, etc. There is no reason to go down that road, just use GUA (Globally Unique Addresses). -Chris
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Apr 21, 2010, at 9:25 AM, Christopher Morrow wrote: On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong o...@delong.com wrote: While I think this is an improvement, unless the distribution of ULA-C is no cheaper and no easier to get than GUA, I still think there is reason to believe that it is likely ULA-C will become de facto GUA over the long term. As such, I still think the current draft is a bad idea absent appropriate protections in RIR policy. I agree with owen, mostly... except I think we should just push RIR's to make GUA accessible to folks that need ipv6 adress space, regardless of connectiivty to thegreater 'internet' (for some definition of that thing). ULA of all types causes headaches on hosts, routers, etc. There is no reason to go down that road, just use GUA (Globally Unique Addresses). -Chris Failure to provide an ULA mechanism will result in self assignment from the spaces not yet made available for allocation. Down that road we will find history repeating itself. The reason I see a use in ULA-C is to ensure there is a way for cooperating organizations (whether within or between enterprises) to have addressing that will not overlap for private interconnects. If the RIRs will give out the space to end users and not charge a fortune for it, there may be a chance of that working. It is less clear whether this is within the business model or mission of the RIRs, though, to hand out very small chucks of address space to a very large number of organizations for address space that will not be routed. Of course if the ULA approach does gain acceptance, you'll have a LOT easier time deciding which blocks of addresses to permit and deny in your BGP sessions and packet filters on your borders.
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Apr 21, 2010, at 6:25 AM, Christopher Morrow wrote: I agree with owen, mostly... except I think we should just push RIR's to make GUA accessible to folks that need ipv6 adress space, regardless of connectiivty to thegreater 'internet' (for some definition of that thing). See RFC 1814. Fun how history repeats itself. Regards, -drc
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Wed, Apr 21, 2010 at 9:42 AM, Daniel Senie d...@senie.com wrote: On Apr 21, 2010, at 9:25 AM, Christopher Morrow wrote: On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong o...@delong.com wrote: While I think this is an improvement, unless the distribution of ULA-C is no cheaper and no easier to get than GUA, I still think there is reason to believe that it is likely ULA-C will become de facto GUA over the long term. As such, I still think the current draft is a bad idea absent appropriate protections in RIR policy. I agree with owen, mostly... except I think we should just push RIR's to make GUA accessible to folks that need ipv6 adress space, regardless of connectiivty to thegreater 'internet' (for some definition of that thing). ULA of all types causes headaches on hosts, routers, etc. There is no reason to go down that road, just use GUA (Globally Unique Addresses). -Chris Failure to provide an ULA mechanism will result in self assignment from the spaces not yet made available for allocation. Down that road we will find history repeating itself. The reason I see a use in ULA-C is to ensure there is a way for cooperating organizations (whether within or between enterprises) to have addressing that will not overlap for private interconnects. If the RIRs will give out the space to end users and not charge a fortune for it, there may be a chance of that working. It is less clear whether this is within the define 'fortune' ? I think currently for a PI /48 it's 1250/yr right? So... the cost (less really) of a laptop for your newest employee per year, basically. That seems quite reasonable (to me). Is that in the range you feel is acceptable? business model or mission of the RIRs, though, to hand out very small chucks of address space to a very large number of organizations for address space that will not be routed. 'not be routed' I think the RIR's should assign ip space, they have no idea (and no control) over where/what gets routed. They are a uniqueness registry really, for ipv6. Of course if the ULA approach does gain acceptance, you'll have a LOT easier time deciding which blocks of addresses to permit and deny in your BGP sessions and packet filters on your borders. PI for v6 comes from a set block in each RIR, eh? -Chris
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Wed, Apr 21, 2010 at 10:23 AM, David Conrad d...@virtualized.org wrote: On Apr 21, 2010, at 6:25 AM, Christopher Morrow wrote: I agree with owen, mostly... except I think we should just push RIR's to make GUA accessible to folks that need ipv6 adress space, regardless of connectiivty to thegreater 'internet' (for some definition of that thing). See RFC 1814. Fun how history repeats itself. yes... for those less willing to search: Unique Addresses are Good The abstract: The IAB suggests that while RFC 1597 establishes reserved IP address space for the use of private networks which are isolated and will remain isolated from the Internet, any enterprise which anticipates external connectivity to the Internet should apply for a globally unique address from an Internet registry or service provider. This does seem to be pretty much exactly my point (their point I suppose) Thx (as always drc) -chris
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Apr 21, 2010, at 7:23 AM, David Conrad wrote: On Apr 21, 2010, at 6:25 AM, Christopher Morrow wrote: I agree with owen, mostly... except I think we should just push RIR's to make GUA accessible to folks that need ipv6 adress space, regardless of connectiivty to thegreater 'internet' (for some definition of that thing). See RFC 1814. Fun how history repeats itself. Regards, -drc @Chris, I agree with you. Perhaps its time for us to throw a proposal into the hopper to do just that. Owen
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Apr 21, 2010, at 7:56 AM, Christopher Morrow wrote: yes... for those less willing to search: Unique Addresses are Good ... This does seem to be pretty much exactly my point (their point I suppose) Yup. Back in the day, the folks who ran the RIRs (at the time) were a bit distressed at that IAB statement as we had seen the writing on the wall and were telling customers that due to the limited nature of IPv4, if you didn't want to connect to the Internet, you should use private addressing. It was a bit of a War of RFCs (1597, 1627, 1814, 1918). My impression, which may be wrong, is that the primary driver for ULA-C is to avoid the administrative/cost overhead with entering into a relationship with the RIRs, particularly if there is no interest in connecting (directly) to the Internet. I guess I don't really see the harm... Regards, -drc Speaking personally. Not representing anyone but myself. Really. No, REALLY. (although this disclaimer doesn't appear to work for some folks who really should know better)
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Wed, Apr 21, 2010 at 09:11:38AM -0700, David Conrad wrote: On Apr 21, 2010, at 7:56 AM, Christopher Morrow wrote: yes... for those less willing to search: Unique Addresses are Good ... This does seem to be pretty much exactly my point (their point I suppose) Yup. Back in the day, the folks who ran the RIRs (at the time) were a bit distressed at that IAB statement as we had seen the writing on the wall and were telling customers that due to the limited nature of IPv4, if you didn't want to connect to the Internet, you should use private addressing. It was a bit of a War of RFCs (1597, 1627, 1814, 1918). My impression, which may be wrong, is that the primary driver for ULA-C is to avoid the administrative/cost overhead with entering into a relationship with the RIRs, particularly if there is no interest in connecting (directly) to the Internet. I guess I don't really see the harm... Regards, -drc Speaking personally. Not representing anyone but myself. Really. No, REALLY. (although this disclaimer doesn't appear to work for some folks who really should know better) this is my take as well. The RIR system works quite well, esp for networks/networking based on the previous centuries interconnection models. Its the best method for managing constrained resources, such as IPv4. something like ULA, esp the -C varient might be worthwhile as an alternative distribution channel, a way for folks who want to do novel things with networking/addressing that are not comprended in the normal bottom-up processes of the RIR system. In your words, avoid the adminisrative/cost overhead with entering(maintaining) a relationship with the RIRs I see this proposal as a vector for inovative change. --bill
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
if you think something like this is a good idea, worth persuing, I'd like to hear from you. and for those of us who think this whack-a-mole is still a stupid idea, where do we write? randy
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
I see a need for stable, permanent blocks of addresses within an organization. yep. unicast ipv6 address space will do just fine. randy
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Wed, Apr 21, 2010 at 03:22:47PM -0500, Randy Bush wrote: if you think something like this is a good idea, worth persuing, I'd like to hear from you. and for those of us who think this whack-a-mole is still a stupid idea, where do we write? randy apparently the same place! thanks Randy. --bill
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Wed, 21 Apr 2010 09:25:46 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong o...@delong.com wrote: While I think this is an improvement, unless the distribution of ULA-C is no cheaper and no easier to get than GUA, I still think there is reason to believe that it is likely ULA-C will become de facto GUA over the long term. As such, I still think the current draft is a bad idea absent appropriate protections in RIR policy. I agree with owen, mostly... except I think we should just push RIR's to make GUA accessible to folks that need ipv6 adress space, regardless of connectiivty to thegreater 'internet' (for some definition of that thing). ULA of all types causes headaches on hosts, routers, etc. There is no reason to go down that road, just use GUA (Globally Unique Addresses). So what happens when you change providers? How are you going to keep using globals that now aren't yours? I'm also curious about these headaches. What are they? -Chris
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Wed, 21 Apr 2010 09:11:38 -0700 David Conrad d...@virtualized.org wrote: On Apr 21, 2010, at 7:56 AM, Christopher Morrow wrote: yes... for those less willing to search: Unique Addresses are Good ... This does seem to be pretty much exactly my point (their point I suppose) Yup. Back in the day, the folks who ran the RIRs (at the time) were a bit distressed at that IAB statement as we had seen the writing on the wall and were telling customers that due to the limited nature of IPv4, if you didn't want to connect to the Internet, you should use private addressing. It was a bit of a War of RFCs (1597, 1627, 1814, 1918). My impression, which may be wrong, is that the primary driver for ULA-C is to avoid the administrative/cost overhead with entering into a relationship with the RIRs, particularly if there is no interest in connecting (directly) to the Internet. I guess I don't really see the harm... That's not what I recollect when the site-local/ULA discussions were going on in 2002. Specifically, ULA-Cs were to address the concern of some people that the statistical possibility of collisions was too high, and therefore they wanted to be assured of global ULA uniqueness via central registry. The chance of collision is quite low - from RFC4193, section 3.2.3, The following table shows the probability of a collision for a range of connections using a 40-bit Global ID field. Connections Probability of Collision 21.81*10^-12 104.54*10^-11 1004.54*10^-09 10004.54*10^-07 14.54*10^-05 Based on this analysis, the uniqueness of locally generated Global IDs is adequate for sites planning a small to moderate amount of inter-site communication using locally generated Global IDs. with 'connections' meaning backdoor links. Traditional, non-ULA-Cs would do the job your talking about fine. Regards, Mark.
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Thu, Apr 22, 2010 at 07:17:20AM +0930, Mark Smith wrote: On Wed, 21 Apr 2010 09:25:46 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong o...@delong.com wrote: While I think this is an improvement, unless the distribution of ULA-C is no cheaper and no easier to get than GUA, I still think there is reason to believe that it is likely ULA-C will become de facto GUA over the long term. As such, I still think the current draft is a bad idea absent appropriate protections in RIR policy. I agree with owen, mostly... except I think we should just push RIR's to make GUA accessible to folks that need ipv6 adress space, regardless of connectiivty to thegreater 'internet' (for some definition of that thing). ULA of all types causes headaches on hosts, routers, etc. There is no reason to go down that road, just use GUA (Globally Unique Addresses). So what happens when you change providers? How are you going to keep using globals that now aren't yours? I'm also curious about these headaches. What are they? I'm so not creative enough to compose this whole missive in TLAs... perhaps some day. Some bright blub got tired of typing out Globally Unique Addresses) and so started using the TLA/GUA. Which eventually got me to thinking. Technically, all IP addresses are globally unique. There is only one of them. 172.14.3.42/32 is a GUA. There are however, two other vectors which the community seems to want and we talk around them a whole bunch. Perhaps we should explicitly make them part of the conversation. ) A GUA has a single authoritative chain of custody... e.g. the community recognizes that only Bill Manning's Bait and Sushi shoppe (AS 66,666) is authorized to inject routes for and sink traffic to 172.14.3.0/24 The whole rPKI construct is built to support this idea. Now some prefixes are defined to -NOT- have a single authoriative chain of custody, witness RFC 1918. And NAT makes matters fuzzier ... bringing scoping into the mix - but I'll stick by the postualte that this single authoritative chain of custody is a key point in understanding how folk think of IP stewardship ... and (THIS IS IMPORTANT) ... there is this strong idea that a short custody chain is prefered over a long one. ) A GUA is temporally bound**... e.g. the community recognizes that for any given GUA, there is a temporal bounding on the chain of custody. DHCP is a canonical example for end/leaf sites, where GUAs are leased out for (comparitavely) brief time periods. ISPs lease space to their clients for longer periods, and RIRs are (mostly) binding a chain of custody to annual cycles. For some legacy space, the temporal binding is of -much- longer duration. so... I might argue that the IANA/RIR/LIR/Enterprise chain has the renumbering concern that you raise, while a IPR/Enterprise chain is much shorter and has a smaller renumbering concern. and -IF- the permise and details of the draft are to be beleived, then a delegation from that space is just as much assured of global uniqueness than space from an RIR. ** The Temporaly Unique Address/TUA !!!
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Thu, 22 Apr 2010 07:30:51 +0930, Mark Smith said: The following table shows the probability of a collision for a range of connections using a 40-bit Global ID field. Connections Probability of Collision 21.81*10^-12 104.54*10^-11 1004.54*10^-09 10004.54*10^-07 14.54*10^-05 Based on this analysis, the uniqueness of locally generated Global IDs is adequate for sites planning a small to moderate amount of inter-site communication using locally generated Global IDs. There is a measured rate by RIRs and the like on the order of 10^-6 for accidentally issuing duplicate integers (roughly approximated by 2 cases of duplicate ASNs out of (300K routes + 30K ASNs). In other words, unless you have over 1,000 or so backdoor links, you're more likely to get screwed over by an administrative drone fscking up your paperwork than you are of a statistical collision. pgpmAcEelzL25.pgp Description: PGP signature
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Wed, Apr 21, 2010 at 5:47 PM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Wed, 21 Apr 2010 09:25:46 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong o...@delong.com wrote: While I think this is an improvement, unless the distribution of ULA-C is no cheaper and no easier to get than GUA, I still think there is reason to believe that it is likely ULA-C will become de facto GUA over the long term. As such, I still think the current draft is a bad idea absent appropriate protections in RIR policy. I agree with owen, mostly... except I think we should just push RIR's to make GUA accessible to folks that need ipv6 adress space, regardless of connectiivty to thegreater 'internet' (for some definition of that thing). ULA of all types causes headaches on hosts, routers, etc. There is no reason to go down that road, just use GUA (Globally Unique Addresses). So what happens when you change providers? How are you going to keep using globals that now aren't yours? use pi space, request it from your local friendly RIR. I'm also curious about these headaches. What are they? do I use that ula-* address to talk to someone or another GUA address? how do I decide? what about to business partners? one address... much simpler, much less to screw up. -chris -Chris
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Wed, Apr 21, 2010 at 9:35 PM, valdis.kletni...@vt.edu wrote: On Thu, 22 Apr 2010 07:30:51 +0930, Mark Smith said: The following table shows the probability of a collision for a range of connections using a 40-bit Global ID field. Connections Probability of Collision 2 1.81*10^-12 10 4.54*10^-11 100 4.54*10^-09 1000 4.54*10^-07 1 4.54*10^-05 Based on this analysis, the uniqueness of locally generated Global IDs is adequate for sites planning a small to moderate amount of inter-site communication using locally generated Global IDs. There is a measured rate by RIRs and the like on the order of 10^-6 for accidentally issuing duplicate integers (roughly approximated by 2 cases of duplicate ASNs out of (300K routes + 30K ASNs). In other words, unless you have over 1,000 or so backdoor links, you're more likely to get screwed over by an administrative drone fscking up your paperwork than you are of a statistical collision. it's not about the frequency of collision, it's about the cost to rectify one/two/some. and the complexity this adds to every host/router/device in/around the network (dns, firewalls, acls, etc... icky) -chris
[Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
and a very pleasant evening. a few questions. IPv6 on your radar? Looking at options for addressing your future v6 needs? Have you looked at the IETF/ID in the subject line? if you think something like this is a good idea, worth persuing, I'd like to hear from you. --bill
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
While I think this is an improvement, unless the distribution of ULA-C is no cheaper and no easier to get than GUA, I still think there is reason to believe that it is likely ULA-C will become de facto GUA over the long term. As such, I still think the current draft is a bad idea absent appropriate protections in RIR policy. Owen On Apr 20, 2010, at 9:34 PM, bmann...@vacation.karoshi.com wrote: and a very pleasant evening. a few questions. IPv6 on your radar? Looking at options for addressing your future v6 needs? Have you looked at the IETF/ID in the subject line? if you think something like this is a good idea, worth persuing, I'd like to hear from you. --bill
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
I see a need for stable, permanent blocks of addresses within an organization. For example, a branch office connecting to a central office over VPN: firewall rules need to be predictable. If the branch office' IPv6 block changes, much access will break. This is directly analogous to how RFC1918 space is used today in such environments. There is a need to have organizations be able to either self-assign or RIR-assign space that they own and can use without trouble within their network. That address space need not be routable on the public networks. In general I think this draft has merit. On Apr 21, 2010, at 1:29 AM, Owen DeLong wrote: While I think this is an improvement, unless the distribution of ULA-C is no cheaper and no easier to get than GUA, I still think there is reason to believe that it is likely ULA-C will become de facto GUA over the long term. As such, I still think the current draft is a bad idea absent appropriate protections in RIR policy. Owen On Apr 20, 2010, at 9:34 PM, bmann...@vacation.karoshi.com wrote: and a very pleasant evening. a few questions. IPv6 on your radar? Looking at options for addressing your future v6 needs? Have you looked at the IETF/ID in the subject line? if you think something like this is a good idea, worth persuing, I'd like to hear from you. --bill
