What is the smallest IPv6 advertisement that organizations are going to honour- are we still looking at a minimum of a /48? -Don
On Mon, 28 May 2007, Donald Stahl wrote:
What is the smallest IPv6 advertisement that organizations are going to honour- are we still looking at a minimum of a /48?
Anything more specific than /32 is going to be filtered at some portion of the ISPs whether for the good or bad. There are some subsets of the v6 address space that have a higher chance of /48 working (for some definition of 'working') than other parts of the address space, though. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Tue, May 29, 2007 at 08:45:38AM +0300, Pekka Savola wrote:
On Mon, 28 May 2007, Donald Stahl wrote:
What is the smallest IPv6 advertisement that organizations are going to honour- are we still looking at a minimum of a /48?
Anything more specific than /32 is going to be filtered at some portion of the ISPs whether for the good or bad. There are some subsets of the v6 address space that have a higher chance of /48 working (for some definition of 'working') than other parts of the address space, though.
perhaps you might better phrase this as; " Anything more specific than a /3 is going to be filtered at some portion of the ISPS whether for the good or bad." just because you have a prefix of (any) size, does not assure that everyone will route it. --bill
Anything more specific than /32 is going to be filtered at some portion of the ISPs whether for the good or bad. There are some subsets of the v6 address space that have a higher chance of /48 working (for some definition of 'working') than other parts of the address space, though. More specific advertisements always stand a chance of being blocked. I was more interested in whether or not people know of places where they are actively being blocked and why.
That said- ARIN is handing out /48's- should we be blocking validly assigned networks? -Don
On Tue, 29 May 2007, Donald Stahl wrote:
That said- ARIN is handing out /48's- should we be blocking validly assigned networks?
your network might have to to protect it's valuable routing slots. There are places in the v4 world where /24's are not carried either. So, as Bill said just cause you get an allocation doesn't mean you can assure routability of it everywhere.
That said- ARIN is handing out /48's- should we be blocking validly assigned networks?
your network might have to to protect it's valuable routing slots. There are places in the v4 world where /24's are not carried either. So, as Bill said just cause you get an allocation doesn't mean you can assure routability of it everywhere. I understand the problems but I think there are clear cut cases where /48's make sense- a large scale anycast DNS provider would seem to be a good candidate for a /48 and I would hope it would get routed. Then again
that might be the only sensible reason... -Don
On Tue, 29 May 2007, Donald Stahl wrote:
That said- ARIN is handing out /48's- should we be blocking validly assigned networks?
your network might have to to protect it's valuable routing slots. There are places in the v4 world where /24's are not carried either. So, as Bill said just cause you get an allocation doesn't mean you can assure routability of it everywhere. I understand the problems but I think there are clear cut cases where /48's make sense- a large scale anycast DNS provider would seem to be a good candidate for a /48 and I would hope it would get routed. Then again that might be the only sensible reason...
vixie had a fun discussion about anycast and dns... something about him being sad/sorry about making everyone have to carry a /24 for f-root everywhere. I think there is a list of 'golden prefixes' or something, normally this is where Jeroen Masseur jumps in with GRH data and pointers. -Chris
vixie had a fun discussion about anycast and dns... something about him being sad/sorry about making everyone have to carry a /24 for f-root everywhere. Whether it's a /24 for f-root or a /20 doesn't really make a difference- it's a routing table entry either way- and why waste addresses.
I think there are a few services where these sorts of exceptions make sense and f-root is certainly one of them. -Don
On May 29, 2007, at 8:23 AM, Donald Stahl wrote:
vixie had a fun discussion about anycast and dns... something about him being sad/sorry about making everyone have to carry a /24 for f-root everywhere. Whether it's a /24 for f-root or a /20 doesn't really make a difference- it's a routing table entry either way- and why waste addresses.
I once suggested that due to the odd nature of the root name server addresses in the DNS protocol (namely, that they must be hardwired into every caching resolver out there and thus, are somewhat difficult to change), the IETF/IAB should designate a bunch of /32s as "root server addresses" as DNS protocol parameters. ISPs could then explicitly permit those /32s. However, the folks I mentioned this to (some root server operators) felt this would be inappropriate. Rgds, -drc
Should've clarified: this was in the context of IPv4... To be honest, I'm not sure what the appropriate equivalent would be in IPv6 (/128 or /64? Arguments can be made for both I suppose). Rgds, -drc On May 29, 2007, at 9:34 AM, David Conrad wrote:
On May 29, 2007, at 8:23 AM, Donald Stahl wrote:
vixie had a fun discussion about anycast and dns... something about him being sad/sorry about making everyone have to carry a /24 for f-root everywhere. Whether it's a /24 for f-root or a /20 doesn't really make a difference- it's a routing table entry either way- and why waste addresses.
I once suggested that due to the odd nature of the root name server addresses in the DNS protocol (namely, that they must be hardwired into every caching resolver out there and thus, are somewhat difficult to change), the IETF/IAB should designate a bunch of /32s as "root server addresses" as DNS protocol parameters. ISPs could then explicitly permit those /32s.
However, the folks I mentioned this to (some root server operators) felt this would be inappropriate.
Rgds, -drc
When I do IPv6 trainings, I always clearly state that it is, in principle, same secure as IPv4: IPsec is the same. However, you can *always* turn on IPsec with IPv6, which is not always true for IPv4 (NATs, no end-to-end, etc.). Also, port scanning is not "so simple", and while in IPv6 a /24 can be scanned in 5 minutes, a /64 takes 5.3 billion years, and of course, usually you will have a /48. So at the time being, it can be considered a bit more difficult to do a brute force DoS. Of course, attackers will try some other means, that's why I recommend not numbering the hosts manually in a consecutive way. One possible choice is to use autoconfiguration the *first* time you power-on a server, then manually configuring the autoconfigured address and using that one for the AAAA. This way, the possibility of consecutive addresses is very low, but at the same time if the interface get broken, you don't need to update the AAAA. Regards, Jordi
De: David Conrad <drc@virtualized.org> Responder a: <owner-nanog@merit.edu> Fecha: Tue, 29 May 2007 11:28:56 -0700 Para: Donald Stahl <don@calis.blacksun.org> CC: Nanog <nanog@nanog.org> Asunto: Re: IPv6 Advertisements
Should've clarified: this was in the context of IPv4...
To be honest, I'm not sure what the appropriate equivalent would be in IPv6 (/128 or /64? Arguments can be made for both I suppose).
Rgds, -drc
On May 29, 2007, at 9:34 AM, David Conrad wrote:
On May 29, 2007, at 8:23 AM, Donald Stahl wrote:
vixie had a fun discussion about anycast and dns... something about him being sad/sorry about making everyone have to carry a /24 for f-root everywhere. Whether it's a /24 for f-root or a /20 doesn't really make a difference- it's a routing table entry either way- and why waste addresses.
I once suggested that due to the odd nature of the root name server addresses in the DNS protocol (namely, that they must be hardwired into every caching resolver out there and thus, are somewhat difficult to change), the IETF/IAB should designate a bunch of /32s as "root server addresses" as DNS protocol parameters. ISPs could then explicitly permit those /32s.
However, the folks I mentioned this to (some root server operators) felt this would be inappropriate.
Rgds, -drc
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
On Tue, 29 May 2007, JORDI PALET MARTINEZ wrote:
However, you can *always* turn on IPsec with IPv6, which is not always true for IPv4 (NATs, no end-to-end, etc.).
security is not JUST ipsec, and ipsec is not actually included in all current ipv6 stacks :( (merike has some nice slides on this actually). Security often is related to the applications using the stack, or the stack itself. While I agree that in principle ipv6 with ipsec is nice, I've yet to see it work reliably in the field, and... it's never going to secure your communications with yahoo.com (maybe not 'never' but not for a very long time). So, having a sane discussion about 'security' and ipv6 ends up being: "Hey, you have the same facilities and issues in ipv4, only the stack is newer and slightly less baked, but if you have protections at multiple layers you are on the right track."
Also, port scanning is not "so simple", and while in IPv6 a /24 can be scanned in 5 minutes, a /64 takes 5.3 billion years, and of course, usually you will have a /48.
This assumes a single machine scanning, not a botnet of 1000 or even the 1.5m the dutch gov't collected 2 yrs ago. Again, a sane discussion is in order. Scanning isn't AS EASY, but it certainly is still feasible, especially if you can enumerate the targets with other methods first to cut down on the random other scanning efforts.
So at the time being, it can be considered a bit more difficult to do a brute force DoS. Of course, attackers will try some other means, that's why
what?? I can make packets in v6 just as fast as v4... how is it harder exactly? Given a host connected to gigabit ethernet on a direct native v6 pipe ... packets get made at line-rate... such hosts do exist.
This assumes a single machine scanning, not a botnet of 1000 or even the 1.5m the dutch gov't collected 2 yrs ago. Again, a sane discussion is in order. Scanning isn't AS EASY, but it certainly is still feasible, With 1.5 million hosts it will only take 3500 years... for a _single_ /64!
I'm not sure that's what I would call feasible. -Don
On May 29, 2007, at 8:28 PM, Donald Stahl wrote:
Scanning isn't AS EASY, but it certainly is still feasible, With 1.5 million hosts it will only take 3500 years... for a _single_ /64! I'm not sure that's what I would call feasible.
There are "smarter" ways to scan v6 address space than this approach. My favorite is "First, the attacker may rely on the administrator conveniently numbering their hosts from [prefix]::1 upward. This makes scanning trivial." Take a look at: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-scanning- implications-03.txt and http://www.cs.columbia.edu/~smb/papers/v6worms.pdf Dale
There are "smarter" ways to scan v6 address space than this approach. My favorite is "First, the attacker may rely on the administrator conveniently numbering their hosts from [prefix]::1 upward. This makes scanning trivial." Most definitely- but not doing that should be considered best practices.
-Don
This assumes a single machine scanning, not a botnet of 1000 or even the 1.5m the dutch gov't collected 2 yrs ago. Again, a sane discussion is in order. Scanning isn't AS EASY, but it certainly is still feasible, With 1.5 million hosts it will only take 3500 years... for a _single_ /64!
I'm not sure that's what I would call feasible.
I would call that not understanding today's security world. "Scanning" is not the primary mode of looking for vulnerabilities today. There are several more effective "come here and get infected" and "click on this attachment and get infected" techniques. What scanning that does go on today usually not the "lets scan the Internet." No money in it. You target your scans to the address ranges of the sites you are trying to mine (i.e. build BOTNETs) or go after.
I would call that not understanding today's security world. "Scanning" is not the primary mode of looking for vulnerabilities today. There are several more effective "come here and get infected" and "click on this attachment and get infected" techniques. I'm well aware of the modern security problems. All I said was: "There is something to be said for not being able to blindly spew worm
traffic and still expect to get a sensible hit ratio as with IPv4." and I stand behind that statement.
What scanning that does go on today usually not the "lets scan the Internet." No money in it. You target your scans to the address ranges of the sites you are trying to mine (i.e. build BOTNETs) or go after. I'm not sure I understand what you are saying- if you number based on hardware addresses then I have no idea what you mean by "address ranges." The hosts you are trying to compromise could be anywhere in the subnet- that's the 3500 years I was referring to above. That's 3500 years to scan a single /64 subnet- not the entire Internet- not even a tiny little fraction of it.
The problem will be people putting all their ducks in a row, so to speak. -Don
Thus spake "Donald Stahl" <don@calis.blacksun.org>
I'm not sure I understand what you are saying- if you number based on hardware addresses then I have no idea what you mean by "address ranges." The hosts you are trying to compromise could be anywhere in the subnet- that's the 3500 years I was referring to above. That's 3500 years to scan a single /64 subnet- not the entire Internet- not even a tiny little fraction of it.
If people use stateless autoconfig, you know what 16 of the bits are, and you can guess 24 of them from a relatively small set. If you're writing a worm that targets residential Wintel users, just scan the OUIs from Dell, HP, etc. Throw in Lenovo if you want to go after business folks. Looking at it another way, you can toss out OUIs from vendors whose gear you know your worm _doesn't_ work on (e.g. Apple, embedded manufacturers, etc.) or only include OUIs for vendors you want to make look bad (e.g. Dell might write a worm that only probes HP machines). (This is also mentioned in the draft Dale referenced, but I came up with it independently in a few seconds, so I think it falls in the "obvious" category for someone with the sk1llz needed to write a worm.) S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
On Tue, 29 May 2007, David Conrad wrote:
Should've clarified: this was in the context of IPv4...
To be honest, I'm not sure what the appropriate equivalent would be in IPv6 (/128 or /64? Arguments can be made for both I suppose).
There have been discussions of this sort made over the years. A good place to start would be the old (well, maybe not that old) 6Net site where there's a list of publications called 'Deliverables'. The info is buried in other, but amongst other things it contains deployment scenarios as well as cookbooks decumenting IPv6 deigns and roll-outs, and what they learned from it all. Lot's to read, but good info nonetheless: http://www.6net.org/publications/deliverables/
Rgds, -drc
On May 29, 2007, at 9:34 AM, David Conrad wrote:
On May 29, 2007, at 8:23 AM, Donald Stahl wrote:
vixie had a fun discussion about anycast and dns... something about him being sad/sorry about making everyone have to carry a /24 for f-root everywhere. Whether it's a /24 for f-root or a /20 doesn't really make a difference- it's a routing table entry either way- and why waste addresses.
I once suggested that due to the odd nature of the root name server addresses in the DNS protocol (namely, that they must be hardwired into every caching resolver out there and thus, are somewhat difficult to change), the IETF/IAB should designate a bunch of /32s as "root server addresses" as DNS protocol parameters. ISPs could then explicitly permit those /32s.
However, the folks I mentioned this to (some root server operators) felt this would be inappropriate.
Rgds, -drc
wfms
drc@virtualized.org (David Conrad) writes:
I once suggested that due to the odd nature of the root name server addresses in the DNS protocol (namely, that they must be hardwired into every caching resolver out there and thus, are somewhat difficult to change), the IETF/IAB should designate a bunch of /32s as "root server addresses" as DNS protocol parameters. ISPs could then explicitly permit those /32s.
However, the folks I mentioned this to (some root server operators) felt this would be inappropriate.
as one of the people who told drc that this was a bad idea, i ought to say that my reason is based on domain name universalism. if root name service addresses were protocol parameters (fixed everywhere) they'd be intercepted ("served locally") even more often by local ISP's and governments for the purpose of overloading the namespace with political or economic goals in mind. this would be great for local ISP's and governments with political or economic goals in mind, but bad for the end users, bad for the community, bad for the internet, and bad for the world. right now, the people who intercept f-root traffic for fun or profit could conceivably be in violation of law or treaty, could have the pleasure of receiving letters from ISC's attorney, and so on. if root name service addresses were unowned protocol parameters used only by convention (like port numbers or AS112 server addresses or RFC1918 addresses), then we'd see a far less universal namespace than we do now, and the coca cola company would probably see far fewer hits at COKE.COM than they see now. whether drc's idea is bad depends on what one thinks the internet is. -- Paul Vixie
Chris L. Morrow wrote: [..]
vixie had a fun discussion about anycast and dns... something about him being sad/sorry about making everyone have to carry a /24 for f-root everywhere. I think there is a list of 'golden prefixes' or something, normally this is where Jeroen Massar jumps in with GRH data and pointers.
*see cue* :) 3 years ago I did a presentation about that, see http://www.sixxs.net/presentations/ and then "IPv6 Golden Networks" for various formats, it is more or less still correct actually, but some things might have changed. The "best" way IMHO to figure out what prefixes you should be carrying and what you are missing out on is to make sure you at least receive all the allocated blocks. The lucky folks who are providing a BGP feed to GRH can simply do that by checking that here: http://www.sixxs.net/tools/grh/dfp/ Everybody else can of course either signup or do it manually. Every prefix in DFP shows how well connected they are at least per BGP, and we assume that reachability by BGP means that you can shove packets over a link. Of course this does not show if the actual link works vice-versa, or if it is a dsl link in the middle or not ;) Should I make an explicit "Golden IPv6 Networks" list available again? For IPv4 that was moreover done for dampening reasons, I don't know if that is still needed. In effect any Golden network is more the network that is most needed by your customers anyway, as such, the full list is more accurate. As for folks wanting "IPv6 Google", http://www.google.com.sixxs.org and then you even get the Dutch version, which is quite liberal :) Any <site>.sixxs.org or <sixxs>.ipv6.sixxs.org allos you to access that <site> over IPv6. Using <sixxs>.ipv4.sixxs.org one can access IPv6 sites when on IPv4 (which I used for some time when I didn't have IPv6 connectivity at work due to firewalls which didn't work, but now they do :). Of course see http://ipv6gate.sixxs.net for more details. Greets, Jeroen
On Tue, 29 May 2007 15:08:34 +0000 (GMT) "Chris L. Morrow" <christopher.morrow@verizonbusiness.com> wrote:
vixie had a fun discussion about anycast and dns... something about him being sad/sorry about making everyone have to carry a /24 for f-root everywhere. I think there is a list of 'golden prefixes' or something, normally this is where Jeroen Masseur jumps in with GRH data and pointers.
In lieu of missing protections for route hijacking there are arguments to be made for announcing more specifics. As will there be arguments over where that line should be drawn and who gets to draw it. :-) John
On Tue, 29 May 2007, Donald Stahl wrote:
That said- ARIN is handing out /48's- should we be blocking validly assigned networks?
your network might have to to protect it's valuable routing slots. There are places in the v4 world where /24's are not carried either. So, as Bill said just cause you get an allocation doesn't mean you can assure routability of it everywhere. I understand the problems but I think there are clear cut cases where /48's make sense- a large scale anycast DNS provider would seem to be a good candidate for a /48 and I would hope it would get routed. Then again that might be the only sensible reason...
f-root does this on the IPv6 side: 2001:500::/48 Whether that's available everywhere on IPv6 networks, is as Bill pointed-out, another question. wfms
I understand the problems but I think there are clear cut cases where /48's make sense- a large scale anycast DNS provider would seem to be a good candidate for a /48 and I would hope it would get routed. Then again that might be the only sensible reason...
f-root does this on the IPv6 side: 2001:500::/48
Whether that's available everywhere on IPv6 networks, is as Bill pointed-out, another question.
<http://www.arin.net/reference/micro_allocations.html> explains what's going on with that /48. <http://www.root-servers.org/> shows some other /48's. if the RIR community wants "critical infrastructure" to use a /48, then f-root's operator will comply. if the RIR community changes its mind, then f-root's operator will comply with that, too. -- Paul Vixie
f-root does this on the IPv6 side: 2001:500::/48
Whether that's available everywhere on IPv6 networks, is as Bill pointed-out, another question. One of the root servers not being available everywhere seems like a pretty lousy idea :)
On another note- are there any folks on the list who haven't at least started testing v6- either in a lab or on their home network? Is there a particular reason why? Does anyone have any horror stories about deploying v6? (Aside from problems with tunnels resulting from A and AAAA records for the same host). With rare exceptions every transition I've read about has been pretty painless. There seems to be so much resistance to v6 and a lot of it seems to be misunderstanding or misinformation regarding the complexity of the changes. -Don
Does anyone have any horror stories about deploying v6?
not horror, just had to back off. small site. so public servers provide multiple and diverse services. if a hostname has a v6 address, then all services must be v6 capable because clients do not retry the A record. and, as someone pointed out earlier, hostname hacks do not work; a referring link can not choose to yield v6.foo as opposed to foo depending on the abilities of the link follower. when i have copious spare time, i will try to sort services by v6 abilities and have another go. but spare time is like spare money these days, sigh. randy
On Tue, 29 May 2007, Randy Bush wrote:
Does anyone have any horror stories about deploying v6?
not horror, just had to back off.
small site. so public servers provide multiple and diverse services. if a hostname has a v6 address, then all services must be v6 capable because clients do not retry the A record.
what's interesting is some applications on the same platform reacting differently :( Safari works 'fine' but mail.app is 'broken' for some corner cases of v4/v6 naming/capabilities. Iljitsch pointed out mail.app, I've filed atleast one bug with apple... I'm positive there are others as well.
Thus spake "Randy Bush" <randy@psg.com>
small site. so public servers provide multiple and diverse services. if a hostname has a v6 address, then all services must be v6 capable because clients do not retry the A record.
This seems to argue for having "service" hostnames, which has been standard practice at many sites for a long, long time. For instance, if you have a single box which does mail and news, and you have v6 mail but only v4 news, then mail.example.com should have both A and AAAA records but news.example.com should have A records only. (Yes, this means you can't just CNAME the service hostname to the real hostname, but there are several other strategies.) S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
On Tue, May 29, 2007 at 01:10:17PM -0400, Donald Stahl wrote:
f-root does this on the IPv6 side: 2001:500::/48
Whether that's available everywhere on IPv6 networks, is as Bill pointed-out, another question. One of the root servers not being available everywhere seems like a pretty lousy idea :)
On another note- are there any folks on the list who haven't at least started testing v6- either in a lab or on their home network? Is there a particular reason why?
Does anyone have any horror stories about deploying v6? (Aside from problems with tunnels resulting from A and AAAA records for the same host). With rare exceptions every transition I've read about has been pretty painless.
I found that my bank had nameservers that did not work properly when asked for the AAAA record as well as the A record. A phone call to their whois contact data resolved it! I believe they had to turn on some ipv6 compatability mode even though they were not doing ipv6 themselves. I suspect some folks are still using older nameserver software that has this defect. But the majority of websites these days work properly as the Mozilla, Safari and other browser engines have been asking about AAAA for years now and i've not seen anyone broken in years now. I'm sure someone is broken, but nobody I've noticed. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
participants (15)
-
Barry Greene (bgreene) -
bmanning＠karoshi.com -
Chris L. Morrow -
Dale W. Carder -
David Conrad -
Donald Stahl -
Jared Mauch -
Jeroen Massar -
John Kristoff -
JORDI PALET MARTINEZ -
Paul Vixie -
Pekka Savola -
Randy Bush -
Stephen Sprunk -
William F. Maton Sotomayor