Re: IPv6 Deployment for the LAN ... anycast
TJ wrote: WRT Anycast DNS; Perhaps a special-case of ULA, FD00::53? You want to allow for more than one for obvious fault isolation and load balancing reasons. The draft suggested using prefix:::1 FWIW - I think simple anycast fits that bill. I think for very small/small networks anycast requires a lot of overhead and understanding. If your big enough to do anycast and/or loadbalancing it's not hard for you to put all three addresses onto one device. There are some protocols that anycasting doesn't work well for, they may require multiple instances. I personally would suggest getting a well known ULA-C allocation assigned to IANA, then use prefix::protocol assignment:1 prefix::protocol assignment:2 and prefix::protocol assignment:3, where protocol assignment could be 0035 for DNS, and 007b for NTP, and if you're feeling adventurous you could use 0019 for outgoing SMTP relay. IMHO non-hex-converted port numbers works cleanly ... ? Up to , if you want to announce a service port 30,000 you're in trouble. Also quite a few protocols don't have well known ports, so may want to get things assigned. If you're doing assignment you could do nice things like 0x53 for DNS and then ports and protocols that don't have well known ports could get an unused one assigned to them. ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of ULA port-based anycast allocation. (16bits would only reach w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious)) Thinking further, if simply based on port#s wouldn't even need a registry. Unless it was decided to implement the multiple-addresses-per-function mentioned above, then perhaps useful. In my humble opinion I'd have them registered, linking them to port numbers means that it's easier on the poor admins brain at 3am while diagnosing faults, but may cause various hassles in the future (see above).
Re: IPv6 Deployment for the LAN ... anycast
WRT Anycast DNS; Perhaps a special-case of ULA, FD00::53? You want to allow for more than one for obvious fault isolation and load balancing reasons. The draft suggested using prefix:::1 FWIW - I think simple anycast fits that bill. I think for very small/small networks anycast requires a lot of overhead and understanding. If your big enough to do anycast and/or loadbalancing it's not hard for you to put all three addresses onto one device. Anycast isn't really hard - same address, multiple places, routers see what appear to be multiple routes to same destination, they choose the least expensive. Only tricky part (for stateless things) is ensuring the route announcement is implicitly tied to service availability on that device ... There are some protocols that anycasting doesn't work well for, they may require multiple instances. Fair enough; could also standardize something like FD00::port number, FD00::1:port number, and FD00::2:port number ... is three addresses enough? (IIRC, the Site-Local based automagic DNS used 2 or three addresses ... ) I personally would suggest getting a well known ULA-C allocation assigned to IANA, then use prefix::protocol assignment:1 prefix::protocol assignment:2 and prefix::protocol assignment:3, where protocol assignment could be 0035 for DNS, and 007b for NTP, and if you're feeling adventurous you could use 0019 for outgoing SMTP relay. IMHO non-hex-converted port numbers works cleanly ... ? Up to , if you want to announce a service port 30,000 you're in trouble. Also quite a few protocols don't have well known ports, so may want to get things assigned. If you're doing assignment you could do nice things like 0x53 for DNS and then ports and protocols that don't have well known ports could get an unused one assigned to them. OK, so the non-hex converted as above (FD00::x:53; where x=[0,1,2] - reserving FD00::/96) covers us to port based on automatically using port numbers (or using automatically registered port numbers, see below). Maybe FD00:::/112 as a block within the above range to be used for manual assignment of automatic service (potentially anycast) addresses. ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of ULA port-based anycast allocation. (16bits would only reach w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious)) Thinking further, if simply based on port#s wouldn't even need a registry. Unless it was decided to implement the multiple-addresses-per-function mentioned above, then perhaps useful. In my humble opinion I'd have them registered, linking them to port numbers means that it's easier on the poor admins brain at 3am while diagnosing faults, but may cause various hassles in the future (see above). OK, so register them - but sign up some well-known ones at very comfortable addresses, like DNS at 53 :). (Or 35 if you prefer hex-conversion ...) And I am sure some would be concerned about hosts performing any sort of automatic service discovery anything, but this atleast has the advantage over multicast in that it doesn't require multicast routing or group membership / state maintenance, only delivers packets to the nearest (not all) instances, etc. /TJ
Re: IPv6 Deployment for the LAN ... anycast
On Oct 23, 2009, at 5:45 AM, TJ wrote: WRT Anycast DNS; Perhaps a special-case of ULA, FD00::53? You want to allow for more than one for obvious fault isolation and load balancing reasons. The draft suggested using prefix:::1 FWIW - I think simple anycast fits that bill. I think for very small/small networks anycast requires a lot of overhead and understanding. If your big enough to do anycast and/or loadbalancing it's not hard for you to put all three addresses onto one device. Anycast isn't really hard - same address, multiple places, routers see what appear to be multiple routes to same destination, they choose the least expensive. Only tricky part (for stateless things) is ensuring the route announcement is implicitly tied to service availability on that device ... Please remember that IPv6 DNS is OFTEN not stateless as the replies are commonly too large for UDP. There are some protocols that anycasting doesn't work well for, they may require multiple instances. Fair enough; could also standardize something like FD00::port number, FD00::1:port number, and FD00::2:port number ... is three addresses enough? (IIRC, the Site-Local based automagic DNS used 2 or three addresses ... ) That's what I meant by prefix::inst:ance:serv:ice instance would be a 32-bit instance value and service would be a 32 bit service value (probably port number in the low order bits initially). I personally would suggest getting a well known ULA-C allocation assigned to IANA, then use prefix::protocol assignment:1 prefix::protocol assignment:2 and prefix::protocol assignment:3, where protocol assignment could be 0035 for DNS, and 007b for NTP, and if you're feeling adventurous you could use 0019 for outgoing SMTP relay. IMHO non-hex-converted port numbers works cleanly ... ? Up to , if you want to announce a service port 30,000 you're in trouble. Also quite a few protocols don't have well known ports, so may want to get things assigned. If you're doing assignment you could do nice things like 0x53 for DNS and then ports and protocols that don't have well known ports could get an unused one assigned to them. OK, so the non-hex converted as above (FD00::x:53; where x=[0,1,2] - reserving FD00::/96) covers us to port based on automatically using port numbers (or using automatically registered port numbers, see below). Why use the non-hex converted? Is it really hard to realize that 0x35 = 53? Maybe FD00:::/112 as a block within the above range to be used for manual assignment of automatic service (potentially anycast) addresses. ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of ULA port-based anycast allocation. (16bits would only reach w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious)) Thinking further, if simply based on port#s wouldn't even need a registry. Unless it was decided to implement the multiple-addresses-per- function mentioned above, then perhaps useful. In my humble opinion I'd have them registered, linking them to port numbers means that it's easier on the poor admins brain at 3am while diagnosing faults, but may cause various hassles in the future (see above). OK, so register them - but sign up some well-known ones at very comfortable addresses, like DNS at 53 :). (Or 35 if you prefer hex-conversion ...) And I am sure some would be concerned about hosts performing any sort of automatic service discovery anything, but this atleast has the advantage over multicast in that it doesn't require multicast routing or group membership / state maintenance, only delivers packets to the nearest (not all) instances, etc. Agreed, but, since this mostly doesn't get typed by humans, I think that using 0x35 is much better in this case than using 0x53 - 53 stuff. Owen
Re: IPv6 Deployment for the LAN ... anycast
Once upon a time, Owen DeLong o...@delong.com said: Please remember that IPv6 DNS is OFTEN not stateless as the replies are commonly too large for UDP. Anything that supports IPv6 _should_ also support EDNS0. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: IPv6 Deployment for the LAN ... anycast
I think for very small/small networks anycast requires a lot of overhead and understanding. If your big enough to do anycast and/or loadbalancing it's not hard for you to put all three addresses onto one device. Anycast isn't really hard - same address, multiple places, routers see what appear to be multiple routes to same destination, they choose the least expensive. Only tricky part (for stateless things) is ensuring the route announcement is implicitly tied to service availability on that device ... I'm thinking for places like home users and the like which don't really run an IGP, can't correctly identify a router, and when you say anycast think that you might be talking about a new form of fishing. There are some protocols that anycasting doesn't work well for, they may require multiple instances. Fair enough; could also standardize something like FD00::port number, FD00::1:port number, and FD00::2:port number ... is three addresses enough? (IIRC, the Site-Local based automagic DNS used 2 or three addresses ... ) 3 seems to me to be plenty for most cases. For some things like NTP you might want to have 4 or more. OK, so the non-hex converted as above (FD00::x:53; where x=[0,1,2] - reserving FD00::/96) covers us to port based on automatically using port numbers (or using automatically registered port numbers, see below). Maybe FD00:::/112 as a block within the above range to be used for manual assignment of automatic service (potentially anycast) addresses. Seems sane to me. In my humble opinion I'd have them registered, linking them to port numbers means that it's easier on the poor admins brain at 3am while diagnosing faults, but may cause various hassles in the future (see above). OK, so register them - but sign up some well-known ones at very comfortable addresses, like DNS at 53 :). (Or 35 if you prefer hex-conversion ...) And I am sure some would be concerned about hosts performing any sort of automatic service discovery anything, but this atleast has the advantage over multicast in that it doesn't require multicast routing or group membership / state maintenance, only delivers packets to the nearest (not all) instances, etc. Yup, and it makes a sane default, if you want to override with DHCP, or some funky RA option, or manual configuration or whatever, then this gets out of your way and you don't have to care. It doesn't involve any code changes on hosts *or* routers to work today.
RE: IPv6 Deployment for the LAN ... anycast
WRT Anycast DNS; Perhaps a special-case of ULA, FD00::53? You want to allow for more than one for obvious fault isolation and load balancing reasons. The draft suggested using prefix:::1 FWIW - I think simple anycast fits that bill. I personally would suggest getting a well known ULA-C allocation assigned to IANA, then use prefix::protocol assignment:1 prefix::protocol assignment:2 and prefix::protocol assignment:3, where protocol assignment could be 0035 for DNS, and 007b for NTP, and if you're feeling adventurous you could use 0019 for outgoing SMTP relay. IMHO non-hex-converted port numbers works cleanly ... ? I thought ULA-C was dead... Did someone resurrect this unfortunate bad idea? Anything is dead until someone uses it. I was thinking FD00 just to have symmetry with anyone using ULAs today, so FC00::/8 could be outright blocked ... ? FC may make sense as they are, de facto, registered ... ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of ULA port-based anycast allocation. (16bits would only reach w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious)) Thinking further, if simply based on port#s wouldn't even need a registry. Unless it was decided to implement the multiple-addresses-per-function mentioned above, then perhaps useful. Easily identified, not globally routable, can be pre-programmed in implementations/applications ... ? Exactly, seems easy, straight forward, robust, reliable and allows for things like fate sharing and fail over. Why pull this out of ULA? Why not pull it out of /16 or one of the other reserved prefixes? ULAs are already defined as internally routable, but not globally routable - which is exactly how I would envision these being used. IOW, seemed to make sense to me! /TJ
