OK. I'm pretty sure I'm gonna get some flak for this but I'll share this question and it's background anyway. Please be gentle. In the past, with IPv4, we have used reserved or "non-routable" space Internally in production for segments that won't be seen anywhere else. Examples? A sync VLAN for some FWs to share state. An IBGP link between routers that will never be seen or advertised. In those cases, we have often used 192.0.2.0/24. It's reserved and never used and even if it did get used one day we aren't "routing" it internally. It's just on segments where we need some L3 that will never be seen. On to IPv6 I was considering taking the same approach. Maybe using 0100::/8 or 1000::/4 or A000::/3 as a space for this. Other than the usual "Hey, you shouldn't do that" can anyone give me some IPv6 specific reasons that I may not be forecasting that would make it worse doing this than in an IPv4 scenario. I know, not apples to apples but for this question they are close enough. Unless there is something IPv6 specific that is influencing this.... -- -Hammer- "I was a normal American nerd" -Jack Herer
Hammer wrote:
In the past, with IPv4, we have used reserved or "non-routable" space Internally in production for segments that won't be seen anywhere else. Examples? A sync VLAN for some FWs to share state. An IBGP link between routers that will never be seen or advertised. In those cases, we have often used 192.0.2.0/24. It's reserved and never used and even if it did get used one day we aren't "routing" it internally. It's just on segments where we need some L3 that will never be seen.
On to IPv6
I was considering taking the same approach. Maybe using 0100::/8 or 1000::/4 or A000::/3 as a space for this.
Why can't you just generate a ULA and use that? Regards, Leo
On 2012-07-13 16:38, -Hammer- wrote:
OK. I'm pretty sure I'm gonna get some flak for this but I'll share this question and it's background anyway. Please be gentle.
In the past, with IPv4, we have used reserved or "non-routable" space Internally in production for segments that won't be seen anywhere else.
There is this very nice concept called ULA (RFC4193), use it. If you want to be more sure about uniqueness, use http://www.sixxs.net/tools/grh/ula/ or you can also just use a chunk of your 'global' prefix and don't announce a route for it and firewall it off properly. Greets, Jeroen
Leo/Jeroen, Thank you both. That is the simple answer that I wasn't thinking of. I'm not as IPv6 savvy as I need to be (yet) so I haven't put all the pieces together when trying to look at the bigger picture. Thanks again. -Hammer- "I was a normal American nerd" -Jack Herer On 7/13/2012 9:41 AM, Jeroen Massar wrote:
On 2012-07-13 16:38, -Hammer- wrote:
OK. I'm pretty sure I'm gonna get some flak for this but I'll share this question and it's background anyway. Please be gentle.
In the past, with IPv4, we have used reserved or "non-routable" space Internally in production for segments that won't be seen anywhere else. There is this very nice concept called ULA (RFC4193), use it. If you want to be more sure about uniqueness, use http://www.sixxs.net/tools/grh/ula/ or you can also just use a chunk of your 'global' prefix and don't announce a route for it and firewall it off properly.
Greets, Jeroen
On Fri, Jul 13, 2012 at 10:38 AM, -Hammer- <bhmccie@gmail.com> wrote:
OK. I'm pretty sure I'm gonna get some flak for this but I'll share this question and it's background anyway. Please be gentle.
In the past, with IPv4, we have used reserved or "non-routable" space Internally in production for segments that won't be seen anywhere else. Examples? A sync VLAN for some FWs to share state. An IBGP link between routers that will never be seen or advertised. In those cases, we have often used 192.0.2.0/24. It's reserved and never used and even if it did get used one day we aren't "routing" it internally. It's just on segments where we need some L3 that will never be seen.
On to IPv6
I was considering taking the same approach. Maybe using 0100::/8 or 1000::/4 or A000::/3 as a space for this.
Would using "just" Link Locals not be sufficient? *(Failing that, as others noted, ULAs are the next "right" answer ... )* * * /TJ
I think they would. I'm just a bit too new to this. Thanks. -Hammer- "I was a normal American nerd" -Jack Herer On 7/13/2012 10:05 AM, TJ wrote:
On Fri, Jul 13, 2012 at 10:38 AM, -Hammer- <bhmccie@gmail.com <mailto:bhmccie@gmail.com>> wrote:
OK. I'm pretty sure I'm gonna get some flak for this but I'll share this question and it's background anyway. Please be gentle.
In the past, with IPv4, we have used reserved or "non-routable" space Internally in production for segments that won't be seen anywhere else. Examples? A sync VLAN for some FWs to share state. An IBGP link between routers that will never be seen or advertised. In those cases, we have often used 192.0.2.0/24 <http://192.0.2.0/24>. It's reserved and never used and even if it did get used one day we aren't "routing" it internally. It's just on segments where we need some L3 that will never be seen.
On to IPv6
I was considering taking the same approach. Maybe using 0100::/8 or 1000::/4 or A000::/3 as a space for this.
Would using "just" Link Locals not be sufficient? /(Failing that, as others noted, ULAs are the next "right" answer ... )/ / / /TJ
On Fri, 13 Jul 2012, Owen DeLong wrote:
On Jul 13, 2012, at 4:24 PM, Randy Bush wrote:
keep life simple. use global ipv6 space.
randy
Though it is rare, this is one time when I absolutely agree with Randy.
It's even more rare for me to agree with Randy AND Owen at the same time. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross
If it is a hostile lab environment, then pre decide on the address space to be used by the company and auto include that into all production routers policies to drop it like a hot potatoes covered in lava. Brandon Ross <bross@pobox.com> wrote: On Fri, 13 Jul 2012, Owen DeLong wrote:
On Jul 13, 2012, at 4:24 PM, Randy Bush wrote:
keep life simple. use global ipv6 space.
randy
Though it is rare, this is one time when I absolutely agree with Randy.
It's even more rare for me to agree with Randy AND Owen at the same time. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross
Guys, The whole purpose of this is that they do NOT need to be global. Security thru obscurity. It actually has a place in some worlds. Does that make sense? Or are such V4-centric approaches a bad thing in v6? On 7/13/12 8:41 PM, "Brandon Ross" <bross@pobox.com> wrote:
On Fri, 13 Jul 2012, Owen DeLong wrote:
On Jul 13, 2012, at 4:24 PM, Randy Bush wrote:
keep life simple. use global ipv6 space.
randy
Though it is rare, this is one time when I absolutely agree with Randy.
It's even more rare for me to agree with Randy AND Owen at the same time.
-- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross
They're a bad thing in IPv6. The only place for security through obscurity IMHO is a small round container that sits next to my desk. Besides, if you don't advertise it, a GUA prefix is just as obscure as a ULA prefix and provides a larger search space in which one has to hunt for it... Think /3 instead of /8. Owen On Jul 14, 2012, at 1:14 PM, -Hammer- wrote:
Guys, The whole purpose of this is that they do NOT need to be global. Security thru obscurity. It actually has a place in some worlds. Does that make sense? Or are such V4-centric approaches a bad thing in v6?
On 7/13/12 8:41 PM, "Brandon Ross" <bross@pobox.com> wrote:
On Fri, 13 Jul 2012, Owen DeLong wrote:
On Jul 13, 2012, at 4:24 PM, Randy Bush wrote:
keep life simple. use global ipv6 space.
randy
Though it is rare, this is one time when I absolutely agree with Randy.
It's even more rare for me to agree with Randy AND Owen at the same time.
-- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross
<bashes head against wall> Thank you all. It's not the protocol that hurts. It's rethinking the culture/philosophy around it. -Hammer- On 7/14/12 3:20 PM, "Owen DeLong" <owen@delong.com> wrote:
They're a bad thing in IPv6.
The only place for security through obscurity IMHO is a small round container that sits next to my desk.
Besides, if you don't advertise it, a GUA prefix is just as obscure as a ULA prefix and provides a larger search space in which one has to hunt for it... Think /3 instead of /8.
Owen
On Jul 14, 2012, at 1:14 PM, -Hammer- wrote:
Guys, The whole purpose of this is that they do NOT need to be global. Security thru obscurity. It actually has a place in some worlds. Does that make sense? Or are such V4-centric approaches a bad thing in v6?
On 7/13/12 8:41 PM, "Brandon Ross" <bross@pobox.com> wrote:
On Fri, 13 Jul 2012, Owen DeLong wrote:
On Jul 13, 2012, at 4:24 PM, Randy Bush wrote:
keep life simple. use global ipv6 space.
randy
Though it is rare, this is one time when I absolutely agree with Randy.
It's even more rare for me to agree with Randy AND Owen at the same time.
-- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross
Actually, that's one of the most insightful meta-points I've seen on NANOG in a long time. There is a HUGE difference between IPv4 and IPv6 thinking. We've all been living in an austerity regime for so long that we've completely forgotten how to leave parsimony behind. Even those of us who worked at companies that were summarily handed a Class B when we mumbled something about "internal subnetting" have a really hard time remembering how to act when we suddenly don't have to answer for every single host address and can design a network to conserve other things (like our brain cells). -r -Hammer- <bhmccie@gmail.com> writes:
<bashes head against wall>
Thank you all. It's not the protocol that hurts. It's rethinking the culture/philosophy around it.
-Hammer-
On 7/14/12 3:20 PM, "Owen DeLong" <owen@delong.com> wrote:
They're a bad thing in IPv6.
The only place for security through obscurity IMHO is a small round container that sits next to my desk.
Besides, if you don't advertise it, a GUA prefix is just as obscure as a ULA prefix and provides a larger search space in which one has to hunt for it... Think /3 instead of /8.
Owen
On Jul 14, 2012, at 1:14 PM, -Hammer- wrote:
Guys, The whole purpose of this is that they do NOT need to be global. Security thru obscurity. It actually has a place in some worlds. Does that make sense? Or are such V4-centric approaches a bad thing in v6?
On 7/13/12 8:41 PM, "Brandon Ross" <bross@pobox.com> wrote:
On Fri, 13 Jul 2012, Owen DeLong wrote:
On Jul 13, 2012, at 4:24 PM, Randy Bush wrote:
keep life simple. use global ipv6 space.
randy
Though it is rare, this is one time when I absolutely agree with Randy.
It's even more rare for me to agree with Randy AND Owen at the same time.
-- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross
On Sat, Jul 14, 2012 at 09:48:49PM -0400, Robert E. Seastrom wrote:
Actually, that's one of the most insightful meta-points I've seen on NANOG in a long time.
There is a HUGE difference between IPv4 and IPv6 thinking. We've all been living in an austerity regime for so long that we've completely forgotten how to leave parsimony behind. Even those of us who worked at companies that were summarily handed a Class B when we mumbled something about "internal subnetting" have a really hard time remembering how to act when we suddenly don't have to answer for every single host address and can design a network to conserve other things (like our brain cells).
Addresses no longer being scarce is a significant shift, but this thread is about a lot more than that. I didn't get the feeling that the original poster was wanting to use non-global addresses on his internal links because he was concerned about running out. He also wanted to do so for purposes of security. And that's not a paradigm shift between v4 and v6. Obscurity / non-global address "magic" was pretend security in v4 and it's pretend security in v6. People who used RFC1918 space where they didn't need global uniqueness in v4 often did so initially because of scarcity (and were often making a completely reasonable decision in doing so), but they then falsly imputed a security benefit to that. If we can leverage the v6 migraton to get out of the thinking that some addresses are magically more secure than others, then that's probably a win, but it's not a fundamental difference between v4 and v6. It's not that correct IPv4 thinking is "1918 is more secure" but the security model of v6 is different. 1918 was never more secure. -- Brett
On 7/14/12, Robert E. Seastrom <rs@seastrom.com> wrote:
Actually, that's one of the most insightful meta-points I've seen on NANOG in a long time.
There is a HUGE difference between IPv4 and IPv6 thinking. We've all been living in an austerity regime for so long that we've completely forgotten how to leave parsimony behind. Even those of us who worked at companies that were summarily handed a Class B when we mumbled something about "internal subnetting" have a really hard time remembering how to act when we suddenly don't have to answer for every single host address and can design a network to conserve other things (like our brain cells).
Suggestions? I feel like I should be able to do something really nice with an absurdly large address space. But lack of imagination or whatever.. I haven't come up with anything that really appeals to me. Thanks, Lee
-Hammer- <bhmccie@gmail.com> writes:
<bashes head against wall>
Thank you all. It's not the protocol that hurts. It's rethinking the culture/philosophy around it.
-Hammer-
On 7/14/12 3:20 PM, "Owen DeLong" <owen@delong.com> wrote:
They're a bad thing in IPv6.
The only place for security through obscurity IMHO is a small round container that sits next to my desk.
Besides, if you don't advertise it, a GUA prefix is just as obscure as a ULA prefix and provides a larger search space in which one has to hunt for it... Think /3 instead of /8.
Owen
On Jul 14, 2012, at 1:14 PM, -Hammer- wrote:
Guys, The whole purpose of this is that they do NOT need to be global. Security thru obscurity. It actually has a place in some worlds. Does that make sense? Or are such V4-centric approaches a bad thing in v6?
On 7/13/12 8:41 PM, "Brandon Ross" <bross@pobox.com> wrote:
On Fri, 13 Jul 2012, Owen DeLong wrote:
On Jul 13, 2012, at 4:24 PM, Randy Bush wrote:
> keep life simple. use global ipv6 space. > > randy
Though it is rare, this is one time when I absolutely agree with Randy.
It's even more rare for me to agree with Randy AND Owen at the same time.
-- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross
I feel like I should be able to do something really nice with an absurdly large address space. But lack of imagination or whatever.. I haven't come up with anything that really appeals to me.
Use a fresh IP for every HTTP request, email message, and IM. Just think of how well you can do error management. R's, John
On 7/15/12, John Levine <johnl@iecc.com> wrote:
I feel like I should be able to do something really nice with an absurdly large address space. But lack of imagination or whatever.. I haven't come up with anything that really appeals to me.
Use a fresh IP for every HTTP request, email message, and IM. Just think of how well you can do error management.
hrmm... nope, can't think of a single thing. Then again, I'm on the routing & switching team at work, so things like HTTP requests, email messages, and IM are just different types of user traffic that needs to be routed to me. Recall the message I was responding to:
There is a HUGE difference between IPv4 and IPv6 thinking. We've all been living in an austerity regime for so long that we've completely forgotten how to leave parsimony behind. Even those of us who worked at companies that were summarily handed a Class B when we mumbled something about "internal subnetting" have a really hard time remembering how to act when we suddenly don't have to answer for every single host address and can design a network to conserve other things (like our brain cells).
I read it as design a network >>addressing scheme<< to conserve other things & was hoping someone could share new ways of looking at it. I feel like I'm stuck in "IPv4 think" with an addressing plan that's basically Each site gets a /48. Even the ones with less than 200 people. Each subnet is assigned a /64 except for loopbacks & p2p subnets. First 256 subnets in each /48 are reserved for things like loopback addresses, p2p links, switch management subnets, etc. High order 4 bits of the site address are used for the subnet type. So a /52 tells you the site and if it's users, printers, servers, IP phones, or whatever. Which is *boring*. Nothing novel, no breaking out of "IPv4 think" aside from massively wasting address space. Which brings me back around to my original request for suggestions. What's the new way of looking at designing a network addressing scheme? Regards, Lee
On Mon, 2012-07-16 at 22:04 -0400, Lee wrote:
Each site gets a /48. Even the ones with less than 200 people. [...] Which is *boring*. Nothing novel, no breaking out of "IPv4 think" aside from massively wasting address space.
It's only a waste if you get nothing for it. By using /64 everywhere you get a more homogeneous network, easier to administer, manage, document, maintain... There are similar advantages, writ larger, to using /48 for every site. Whether you have 2, 20, 200, 2000 or 20,000 hosts in a /64 subnet, you have still only used 0% of it, to a dozen or more decimal places. IPv4-think says that's a waste. IPv6-think says "great - all my subnets are large enough". Resizing IPv4 subnets is common; resizing IPv6 subnets will be rare. IPv4-think is conserving addresses. IPv6-think is conserving subnets. We don't buy dining chairs based on the number of atoms in them - we buy enough to seat the people who need seating. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
On Jul 16, 2012, at 7:35 PM, Karl Auer wrote:
On Mon, 2012-07-16 at 22:04 -0400, Lee wrote:
Each site gets a /48. Even the ones with less than 200 people. [...] Which is *boring*. Nothing novel, no breaking out of "IPv4 think" aside from massively wasting address space.
It's only a waste if you get nothing for it. By using /64 everywhere you get a more homogeneous network, easier to administer, manage, document, maintain... There are similar advantages, writ larger, to using /48 for every site.
It's also a waste if you don't ever use the address and the protocol gets deprecated before a significant percentage of the addresses are allocated. Earlier in this thread, I did the math showing how it will likely, even with very liberal allocation policies, be 100 years or more before we allocate 1/40th of the total IPv6 space to RIRs.
Whether you have 2, 20, 200, 2000 or 20,000 hosts in a /64 subnet, you have still only used 0% of it, to a dozen or more decimal places. IPv4-think says that's a waste. IPv6-think says "great - all my subnets are large enough". Resizing IPv4 subnets is common; resizing IPv6 subnets will be rare.
IPv4-think is conserving addresses. IPv6-think is conserving subnets. We don't buy dining chairs based on the number of atoms in them - we buy enough to seat the people who need seating.
Exactly. Owen
You could try this: If you give a /48 to each site, then assign the sites primary and backup firewalls. Aggregate the /48s into larger blocks by primary firewall. Aggregate the primary firewall bocks into larger backup firewall aggregates. Advertise the firewall-specific aggregates and the less specific backup-firewall set aggregates. Owen On Jul 16, 2012, at 7:04 PM, Lee wrote:
On 7/15/12, John Levine <johnl@iecc.com> wrote:
I feel like I should be able to do something really nice with an absurdly large address space. But lack of imagination or whatever.. I haven't come up with anything that really appeals to me.
Use a fresh IP for every HTTP request, email message, and IM. Just think of how well you can do error management.
hrmm... nope, can't think of a single thing. Then again, I'm on the routing & switching team at work, so things like HTTP requests, email messages, and IM are just different types of user traffic that needs to be routed to me.
Recall the message I was responding to:
There is a HUGE difference between IPv4 and IPv6 thinking. We've all been living in an austerity regime for so long that we've completely forgotten how to leave parsimony behind. Even those of us who worked at companies that were summarily handed a Class B when we mumbled something about "internal subnetting" have a really hard time remembering how to act when we suddenly don't have to answer for every single host address and can design a network to conserve other things (like our brain cells).
I read it as design a network >>addressing scheme<< to conserve other things & was hoping someone could share new ways of looking at it. I feel like I'm stuck in "IPv4 think" with an addressing plan that's basically
Each site gets a /48. Even the ones with less than 200 people. Each subnet is assigned a /64 except for loopbacks & p2p subnets. First 256 subnets in each /48 are reserved for things like loopback addresses, p2p links, switch management subnets, etc. High order 4 bits of the site address are used for the subnet type. So a /52 tells you the site and if it's users, printers, servers, IP phones, or whatever.
Which is *boring*. Nothing novel, no breaking out of "IPv4 think" aside from massively wasting address space. Which brings me back around to my original request for suggestions. What's the new way of looking at designing a network addressing scheme?
Regards, Lee
There are multiple issues here. I understand most folks on these threads are beyond me but I'm pretty sure I'm not the only person in this position. 1) (This one is currently a personal issue) I am still building up a true IPv6 skillset. Yes, I understand it for the most part but now is the time to apply it. 2) All the reading you do doesn't prepare you for application and the vendors aren't necessarily helping. Feature parity across platforms and vendors beyond just "interface x/x/x" and "ipv6 address fe80:blah:blah::babe:1" seems to seriously be lacking. When I try to take what I understand and apply it beyond the basics I often see hurdles. Example? HSRP IPv6 global addressing on Cisco ASR platform. If it's working for you hit me offline. Example2? Any vendor product beyond a router or switch. CheckPoint FW? F5 LB? Netscaler LB or AF? The WAN guys may be rolling deep in IPv6 but not everyone else. I just got an EA this morning from CheckPoint for NAT66. This should have been ready for prime time years ago. I guess the vendors weren't getting the push from the customers so there was no need to make an effort.... 3) When I'm not preoccupied attempting to digest the fundamentals I am well aware of the retooling of the brain that is required for this in a network design. Last year I reached out to Team Cymru and attempted to build an IPv6 router template to match their IPv4 template. It was a completely different animal. Ironically most of the STIGs and NSA reference garbage I used was ten years old but still applied. After going thru all those docs my brain hurt trying to orient my ACLs properly and go thru all the different attributes you want to block where and when. Then I spent some time trying to work our design schemas for our ARIN space with the WAN design team. What I'm trying to say is that Roberts comments are spot on. It is a very different way of thinking on a small scale and a large scale and you can't take your IPv4 logic and apply it. I've tried and it's just slowing me down. -Hammer- "I was a normal American nerd" -Jack Herer On 7/15/2012 10:35 PM, Lee wrote:
On 7/14/12, Robert E. Seastrom <rs@seastrom.com> wrote:
Actually, that's one of the most insightful meta-points I've seen on NANOG in a long time.
There is a HUGE difference between IPv4 and IPv6 thinking. We've all been living in an austerity regime for so long that we've completely forgotten how to leave parsimony behind. Even those of us who worked at companies that were summarily handed a Class B when we mumbled something about "internal subnetting" have a really hard time remembering how to act when we suddenly don't have to answer for every single host address and can design a network to conserve other things (like our brain cells). Suggestions?
I feel like I should be able to do something really nice with an absurdly large address space. But lack of imagination or whatever.. I haven't come up with anything that really appeals to me.
Thanks, Lee
-Hammer- <bhmccie@gmail.com> writes:
<bashes head against wall>
Thank you all. It's not the protocol that hurts. It's rethinking the culture/philosophy around it.
-Hammer-
On 7/14/12 3:20 PM, "Owen DeLong" <owen@delong.com> wrote:
They're a bad thing in IPv6.
The only place for security through obscurity IMHO is a small round container that sits next to my desk.
Besides, if you don't advertise it, a GUA prefix is just as obscure as a ULA prefix and provides a larger search space in which one has to hunt for it... Think /3 instead of /8.
Owen
On Jul 14, 2012, at 1:14 PM, -Hammer- wrote:
Guys, The whole purpose of this is that they do NOT need to be global. Security thru obscurity. It actually has a place in some worlds. Does that make sense? Or are such V4-centric approaches a bad thing in v6?
On 7/13/12 8:41 PM, "Brandon Ross" <bross@pobox.com> wrote:
On Fri, 13 Jul 2012, Owen DeLong wrote:
> On Jul 13, 2012, at 4:24 PM, Randy Bush wrote: > >> keep life simple. use global ipv6 space. >> >> randy > Though it is rare, this is one time when I absolutely agree with > Randy. It's even more rare for me to agree with Randy AND Owen at the same time.
-- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross
On Jul 16, 2012, at 8:11 AM, -Hammer- wrote:
There are multiple issues here. I understand most folks on these threads are beyond me but I'm pretty sure I'm not the only person in this position.
1) (This one is currently a personal issue) I am still building up a true IPv6 skillset. Yes, I understand it for the most part but now is the time to apply it.
Frankly, IMHO, the best way to build up a truly useful IPv6 skill set is to start applying what you don't know and see what happens. For the most part, you will find that it is truly "96 more bits, no magic".
2) All the reading you do doesn't prepare you for application and the vendors aren't necessarily helping. Feature parity across platforms and vendors beyond just "interface x/x/x" and "ipv6 address fe80:blah:blah::babe:1" seems to seriously be lacking. When I try to take what I understand and apply it beyond the basics I often see hurdles. Example? HSRP IPv6 global addressing on Cisco ASR platform. If it's working for you hit me offline. Example2? Any vendor product beyond a router or switch. CheckPoint FW? F5 LB? Netscaler LB or AF? The WAN guys may be rolling deep in IPv6 but not everyone else. I just got an EA this morning from CheckPoint for NAT66. This should have been ready for prime time years ago. I guess the vendors weren't getting the push from the customers so there was no need to make an effort....
You probably meant 2001:db8:b1aa:b1aa::babe:1 ;-) (blah isn't hex and fe80::/10 is link local. 2001:db8::/16 is the example prefix) For the most part, HSRP really isn't even necessary or useful in IPv6 since ND should take care of what HSRP did for IPv4. I believe F5 has rolled out IPv6 in a subset of their products and that you need pretty recent versions to get IPv6 functionality from them. The ARIN Wiki (http://www.getipv6.info) may be a good source of information on various vendor statuses. Contribute what you know/find out there as well, please. Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being able to eliminate NAT. NAT was a necessary evil for IPv4 address conservation. It has no good use in IPv6.
3) When I'm not preoccupied attempting to digest the fundamentals I am well aware of the retooling of the brain that is required for this in a network design. Last year I reached out to Team Cymru and attempted to build an IPv6 router template to match their IPv4 template. It was a completely different animal. Ironically most of the STIGs and NSA reference garbage I used was ten years old but still applied. After going thru all those docs my brain hurt trying to orient my ACLs properly and go thru all the different attributes you want to block where and when. Then I spent some time trying to work our design schemas for our ARIN space with the WAN design team. What I'm trying to say is that Roberts comments are spot on. It is a very different way of thinking on a small scale and a large scale and you can't take your IPv4 logic and apply it. I've tried and it's just slowing me down.
Yes and no. If you have been doing IPv4 long enough to remember pre-NAT IPv4, then, you just need to remember some of the old ways of IPv4. If you have no recollection of IPv4 without NAT, then, you are correct, it is a huge paradigm shift to go back to the way the internet is supposed to have been before we ran out of addresses. Owen
-Hammer-
"I was a normal American nerd" -Jack Herer
On 7/15/2012 10:35 PM, Lee wrote:
On 7/14/12, Robert E. Seastrom <rs@seastrom.com> wrote:
Actually, that's one of the most insightful meta-points I've seen on NANOG in a long time.
There is a HUGE difference between IPv4 and IPv6 thinking. We've all been living in an austerity regime for so long that we've completely forgotten how to leave parsimony behind. Even those of us who worked at companies that were summarily handed a Class B when we mumbled something about "internal subnetting" have a really hard time remembering how to act when we suddenly don't have to answer for every single host address and can design a network to conserve other things (like our brain cells). Suggestions?
I feel like I should be able to do something really nice with an absurdly large address space. But lack of imagination or whatever.. I haven't come up with anything that really appeals to me.
Thanks, Lee
-Hammer- <bhmccie@gmail.com> writes:
<bashes head against wall>
Thank you all. It's not the protocol that hurts. It's rethinking the culture/philosophy around it.
-Hammer-
On 7/14/12 3:20 PM, "Owen DeLong" <owen@delong.com> wrote:
They're a bad thing in IPv6.
The only place for security through obscurity IMHO is a small round container that sits next to my desk.
Besides, if you don't advertise it, a GUA prefix is just as obscure as a ULA prefix and provides a larger search space in which one has to hunt for it... Think /3 instead of /8.
Owen
On Jul 14, 2012, at 1:14 PM, -Hammer- wrote:
Guys, The whole purpose of this is that they do NOT need to be global. Security thru obscurity. It actually has a place in some worlds. Does that make sense? Or are such V4-centric approaches a bad thing in v6?
On 7/13/12 8:41 PM, "Brandon Ross" <bross@pobox.com> wrote:
> On Fri, 13 Jul 2012, Owen DeLong wrote: > >> On Jul 13, 2012, at 4:24 PM, Randy Bush wrote: >> >>> keep life simple. use global ipv6 space. >>> >>> randy >> Though it is rare, this is one time when I absolutely agree with >> Randy. > It's even more rare for me to agree with Randy AND Owen at the same > time. > > -- > Brandon Ross Yahoo & AIM: > BrandonNRoss > +1-404-635-6667 ICQ: > 2269442 > Schedule a meeting: https://tungle.me/bross Skype: > brandonross >
Inline - -Hammer- "I was a normal American nerd" -Jack Herer 1) (This one is currently a personal issue) I am still building up a true IPv6 skillset. Yes, I understand it for the most part but now is the time to apply it. Frankly, IMHO, the best way to build up a truly useful IPv6 skill set is to start applying what you don't know and see what happens. For the most part, you will find that it is truly "96 more bits, no magic". ------- Completely agree. Been playing in GNS3 on the basics and we're starting to play in a full lab soon.
2) All the reading you do doesn't prepare you for application and the vendors aren't necessarily helping. Feature parity across platforms and vendors beyond just "interface x/x/x" and "ipv6 address fe80:blah:blah::babe:1" seems to seriously be lacking. When I try to take what I understand and apply it beyond the basics I often see hurdles. Example? HSRP IPv6 global addressing on Cisco ASR platform. If it's working for you hit me offline. Example2? Any vendor product beyond a router or switch. CheckPoint FW? F5 LB? Netscaler LB or AF? The WAN guys may be rolling deep in IPv6 but not everyone else. I just got an EA this morning from CheckPoint for NAT66. This should have been ready for prime time years ago. I guess the vendors weren't getting the push from the customers so there was no need to make an effort....
You probably meant 2001:db8:b1aa:b1aa::babe:1 (blah isn't hex and fe80::/10 is link local. 2001:db8::/16 is the example prefix) ------- I stand corrected. :) For the most part, HSRP really isn't even necessary or useful in IPv6 since ND should take care of what HSRP did for IPv4. ------- On the WAN? Sure. On my Internet facing equipment? I disagree. RAs and ND and all that fun stuff needs to be suppressed. I believe F5 has rolled out IPv6 in a subset of their products and that you need pretty recent versions to get IPv6 functionality from them. The ARIN Wiki (http://www.getipv6.info) may be a good source of information on various vendor statuses. Contribute what you know/find out there as well, please. ------- Yes they have and NetScaler is running solid as well. My issues are when you go beyond basic features of any product with IPv6 things get tricky. I need content switching with redirects and whatnot and based on the few efforts I've seen so far I'm not optimistic. Again, routers and switches seem to be further ahead than other products. They all have their limits in advanced features. Back to my ASR comment. Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being able to eliminate NAT. NAT was a necessary evil for IPv4 address conservation. It has no good use in IPv6. -------That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be there if there weren't enough customers asking for it. Are all the customers naive? I doubt it. They have their reasons. I agree with your "purist" definition and did not say I was using it. My point is that vendors are still rolling out baseline features even today.
3) When I'm not preoccupied attempting to digest the fundamentals I am well aware of the retooling of the brain that is required for this in a network design. Last year I reached out to Team Cymru and attempted to build an IPv6 router template to match their IPv4 template. It was a completely different animal. Ironically most of the STIGs and NSA reference garbage I used was ten years old but still applied. After going thru all those docs my brain hurt trying to orient my ACLs properly and go thru all the different attributes you want to block where and when. Then I spent some time trying to work our design schemas for our ARIN space with the WAN design team. What I'm trying to say is that Roberts comments are spot on. It is a very different way of thinking on a small scale and a large scale and you can't take your IPv4 logic and apply it. I've tried and it's just slowing me down.
Yes and no. If you have been doing IPv4 long enough to remember pre-NAT IPv4, then, you just need to remember some of the old ways of IPv4. If you have no recollection of IPv4 without NAT, then, you are correct, it is a huge paradigm shift to go back to the way the internet is supposed to have been before we ran out of addresses. ------- This isn't specific to you Owen, but the group in general. I have been around for a while. Not as long as some others here. NAT is a feature and it does have a place. Security. I'm sorry that this frustrates people but security is a layered approach and it starts off simple. If you have a network that doesn't need exposure to the Internet or to someone else you can get fancy with anything from a FW to control source and destination or AD controls so only the accounting team can get in. Sure. They all work. You can also NAT them. Make them invisible. Or null the traffic. The more fundamental the point of defense is the easier it is to understand and sometimes the more difficult it becomes to bypass. Complex security adds a greater potential for vulnerabilities. If you want to protect your car stereo you could lock a cover over it right? But if you could, wouldn't you also just lock the car doors when you leave it? I'm not going to tell you that NAT guarantees you anything. We all know nothing is foolproof. But it is a fundamental feature that works for that purpose. Do I plan on NATting our edge Internet traffic? No. Not for IPv6. Because the protocol was not designed for it. But have I ruled it out as an option for some environments? No. Bring on the flames. I know this is going to get people stirred up. I promise not to ignore the thread....
On Mon, 16 Jul 2012 11:09:28 -0500, -Hammer- said:
-------That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be there if there weren't enough customers asking for it. Are all the customers naive? I doubt it. They have their reasons. I agree with your "purist" definition and did not say I was using it. My point is that vendors are still rolling out base line features even today.
Sorry to tell you this, but the customers *are* naive and asking for stupid stuff. They think they need NAT under IPv6 because they suffered with it in IPv4 due to addressing issues or a (totally percieved) security benefit (said benefit being *entirely* based on the fact that once you get NAT working, you can build a stateful firewall for essentially free). The address crunch is gone, and stateful firewalls exist, so there's no *real* reason to keep pounding your head against the wall other than "we've been doing it for 15 years".
I agree. Most are naive. Not all. -Hammer- "I was a normal American nerd" -Jack Herer On 7/16/2012 11:34 AM, valdis.kletnieks@vt.edu wrote:
-------That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be there if there weren't enough customers asking for it. Are all the customers naive? I doubt it. They have their reasons. I agree with your "purist" definition and did not say I was using it. My point is that vendors are still rolling out base line features even today. Sorry to tell you this, but the customers *are* naive and asking for stupid stuff. They think they need NAT under IPv6 because they suffered with it in IPv4 due to addressing issues or a (totally percieved) security benefit (said benefit being *entirely* based on the fact that once you get NAT working, you can build a stateful firewall for essentially free). The address crunch is gone, and stateful firewalls exist, so there's no *real* reason to keep
On Mon, 16 Jul 2012 11:09:28 -0500, -Hammer- said: pounding your head against the wall other than "we've been doing it for 15 years".
""" Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being able to eliminate NAT. NAT was a necessary evil for IPv4 address conservation. It has no good use in IPv6. """ NAT still has its uses; virtualization and cloud infrastructure being one of the most legitimate. Certain kinds of NAT, such as RFC 6296, are very useful, and one of the best methods we have today of delivering IPv6 to smaller networks who wish to have private address space internally ... be it for consistency, ISP independence, multi-homing, or just downright operational parity. I really think all this focus on anti-NAT talk has held-back adoption (and FWIW I used to be one of the people banging the anti-NAT drum the loudest). Keep in mind the collective attitude in communities like this one about NAT for v6 trickles down into decisions made elsewhere; the Linux Netfilter team, for example, is met by a lot of hostility when they talk about including things like 6296 in ip6tables; and as a result it's been left out (even though it's functional). -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Hi, Op 16 jul 2012, om 18:34 heeft valdis.kletnieks@vt.edu het volgende geschreven:
On Mon, 16 Jul 2012 11:09:28 -0500, -Hammer- said:
-------That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be there if there weren't enough customers asking for it. Are all the customers naive? I doubt it. They have their reasons. I agree with your "purist" definition and did not say I was using it. My point is that vendors are still rolling out base line features even today.
Sorry to tell you this, but the customers *are* naive and asking for stupid stuff. They think they need NAT under IPv6 because they suffered with it in IPv4 due to addressing issues or a (totally percieved) security benefit (said benefit being *entirely* based on the fact that once you get NAT working, you can build a stateful firewall for essentially free). The address crunch is gone, and stateful firewalls exist, so there's no *real* reason to keep pounding your head against the wall other than "we've been doing it for 15 years".
To highlight what the current NAT66 is useful for, it's a RFC for Network Prefix translation. It has nothing do with obfuscation or hiding the network anymore. It's current application is multihoming for the poor. Example: You have a Cable and a DSL, they both provide IPv6 and you want to provide failover. You then use ULA or one of the Global Addresses on the LAN network, and set up NAT66 mappings for the secondary WAN, or both if you are using ULA. This will not hide *anything* as your machines will now be *visible* on 2 global prefixes at the same time. And yes, you still use the stateful firewall rules on each WAN for the incoming traffic. And you can redirect traffic as needed out each WAN. It's the closest thing to the existing Dual WAN that current routers support. Also note that this also works fine with 2 IPv6 tunnels. Bind each tunnel to a WAN and you have the same failover for IPv6 as IPv4. Cheers, Seth
On Jul 16, 2012, at 10:36 PM, Seth Mos wrote:
Hi,
Op 16 jul 2012, om 18:34 heeft valdis.kletnieks@vt.edu het volgende geschreven:
On Mon, 16 Jul 2012 11:09:28 -0500, -Hammer- said:
-------That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be there if there weren't enough customers asking for it. Are all the customers naive? I doubt it. They have their reasons. I agree with your "purist" definition and did not say I was using it. My point is that vendors are still rolling out base line features even today.
Sorry to tell you this, but the customers *are* naive and asking for stupid stuff. They think they need NAT under IPv6 because they suffered with it in IPv4 due to addressing issues or a (totally percieved) security benefit (said benefit being *entirely* based on the fact that once you get NAT working, you can build a stateful firewall for essentially free). The address crunch is gone, and stateful firewalls exist, so there's no *real* reason to keep pounding your head against the wall other than "we've been doing it for 15 years".
To highlight what the current NAT66 is useful for, it's a RFC for Network Prefix translation. It has nothing do with obfuscation or hiding the network anymore. It's current application is multihoming for the poor.
And it's a really poor way to do multihoming. You don't have to spend a lot of money to multihome properly.
Example: You have a Cable and a DSL, they both provide IPv6 and you want to provide failover. You then use ULA or one of the Global Addresses on the LAN network, and set up NAT66 mappings for the secondary WAN, or both if you are using ULA.
I have that and I use BGP with an ARIN prefix using the Cable and DSL as layer 2 substrates for dual-stack tunnels. Works pretty well and doesn't cost much more than the NAT66 based solution.
This will not hide *anything* as your machines will now be *visible* on 2 global prefixes at the same time. And yes, you still use the stateful firewall rules on each WAN for the incoming traffic. And you can redirect traffic as needed out each WAN. It's the closest thing to the existing Dual WAN that current routers support.
Also note that this also works fine with 2 IPv6 tunnels. Bind each tunnel to a WAN and you have the same failover for IPv6 as IPv4.
Once you go to tunnels, why not go all the way and put BGP across the tunnels? Owen
Op 17-7-2012 8:43, Owen DeLong schreef:
On Jul 16, 2012, at 10:36 PM, Seth Mos wrote:
Hi,
Op 16 jul 2012, om 18:34 heeft valdis.kletnieks@vt.edu het volgende geschreven: To highlight what the current NAT66 is useful for, it's a RFC for Network Prefix translation. It has nothing do with obfuscation or hiding the network anymore. It's current application is multihoming for the poor.
And it's a really poor way to do multihoming.
You don't have to spend a lot of money to multihome properly.
Did you see I mentioned poor? Poor as in unwilling to pay anything more then the cost for the 2 internet connections they already have. If you are a individual this likely applies. 3G stick anyone? If you are a business, see B for Business and B for BGP. Also, I hope Mobile Internet providers will be supporting DHCP6 and DHCP6-PD for hotspots. Another place where I can see cruft being made. On that note, the world of Mobile internet providers seems to be full of assumptions about the use of the devices and connection. It can probably never be saved anymore. If there ever was a mobile network that not respected the users/clients interests this would be it.
Example: You have a Cable and a DSL, they both provide IPv6 and you want to provide failover. You then use ULA or one of the Global Addresses on the LAN network, and set up NAT66 mappings for the secondary WAN, or both if you are using ULA.
I have that and I use BGP with an ARIN prefix using the Cable and DSL as layer 2 substrates for dual-stack tunnels.
So can any user just send them an email "Hey, I dual home, can I have a /48 please?". That's not even considering that I need to terminate the prefix on a BGP router somewhere that someone surely wants money for.
Works pretty well and doesn't cost much more than the NAT66 based solution.
It's in your words "doesn't cost much more" which translates to "too much", we're all cheapskates :-)
Once you go to tunnels, why not go all the way and put BGP across the tunnels?
Because by using 2 tunnels from 2 different providers you actually hope to increase redundancy, we are not talking 2 Hurricane Electric tunnels here. It's one /48 from HE.net and another /48 Sixxs. I've had a bit too much the past few months where a number of the HE.net tunnelbrokers have been the target for a DDoS attack. Nothing I can blame HE.net for, but it does illustrate my point that having 2 different "upstream" (tunnel) providers work best. Regards, Seth
On the HSRP/ND part , this all falls in the First Hop redundancy areana and can be achieved via any of the following and each has its merits and cons.. 1) Using ND -- need to tune the "IPv6 nd reachable time" to achieve the faster failover 2) Using any of the First hop redundancy protocol ( HSRP, VRRP , GLBP) 3) Default route selection. So depending on the network convergence need etc , any or combination of above can be looked at. Thx Rajendra On 7/16/12 9:09 AM, "-Hammer-" <bhmccie@gmail.com> wrote:
Inline -
-Hammer-
"I was a normal American nerd" -Jack Herer
1) (This one is currently a personal issue) I am still building up a true IPv6 skillset. Yes, I understand it for the most part but now is the time to apply it.
Frankly, IMHO, the best way to build up a truly useful IPv6 skill set is to start applying what you don't know and see what happens. For the most part, you will find that it is truly "96 more bits, no magic".
------- Completely agree. Been playing in GNS3 on the basics and we're starting to play in a full lab soon.
2) All the reading you do doesn't prepare you for application and the vendors aren't necessarily helping. Feature parity across platforms and vendors beyond just "interface x/x/x" and "ipv6 address fe80:blah:blah::babe:1" seems to seriously be lacking. When I try to take what I understand and apply it beyond the basics I often see hurdles. Example? HSRP IPv6 global addressing on Cisco ASR platform. If it's working for you hit me offline. Example2? Any vendor product beyond a router or switch. CheckPoint FW? F5 LB? Netscaler LB or AF? The WAN guys may be rolling deep in IPv6 but not everyone else. I just got an EA this morning from CheckPoint for NAT66. This should have been ready for prime time years ago. I guess the vendors weren't getting the push from the customers so there was no need to make an effort....
You probably meant 2001:db8:b1aa:b1aa::babe:1 (blah isn't hex and fe80::/10 is link local. 2001:db8::/16 is the example prefix)
------- I stand corrected. :)
For the most part, HSRP really isn't even necessary or useful in IPv6 since ND should take care of what HSRP did for IPv4.
------- On the WAN? Sure. On my Internet facing equipment? I disagree. RAs and ND and all that fun stuff needs to be suppressed.
I believe F5 has rolled out IPv6 in a subset of their products and that you need pretty recent versions to get IPv6 functionality from them. The ARIN Wiki (http://www.getipv6.info) may be a good source of information on various vendor statuses. Contribute what you know/find out there as well, please.
------- Yes they have and NetScaler is running solid as well. My issues are when you go beyond basic features of any product with IPv6 things get tricky. I need content switching with redirects and whatnot and based on the few efforts I've seen so far I'm not optimistic. Again, routers and switches seem to be further ahead than other products. They all have their limits in advanced features. Back to my ASR comment.
Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being able to eliminate NAT. NAT was a necessary evil for IPv4 address conservation. It has no good use in IPv6.
-------That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be there if there weren't enough customers asking for it. Are all the customers naive? I doubt it. They have their reasons. I agree with your "purist" definition and did not say I was using it. My point is that vendors are still rolling out baseline features even today.
3) When I'm not preoccupied attempting to digest the fundamentals I am well aware of the retooling of the brain that is required for this in a network design. Last year I reached out to Team Cymru and attempted to build an IPv6 router template to match their IPv4 template. It was a completely different animal. Ironically most of the STIGs and NSA reference garbage I used was ten years old but still applied. After going thru all those docs my brain hurt trying to orient my ACLs properly and go thru all the different attributes you want to block where and when. Then I spent some time trying to work our design schemas for our ARIN space with the WAN design team. What I'm trying to say is that Roberts comments are spot on. It is a very different way of thinking on a small scale and a large scale and you can't take your IPv4 logic and apply it. I've tried and it's just slowing me down.
Yes and no. If you have been doing IPv4 long enough to remember pre-NAT IPv4, then, you just need to remember some of the old ways of IPv4. If you have no recollection of IPv4 without NAT, then, you are correct, it is a huge paradigm shift to go back to the way the internet is supposed to have been before we ran out of addresses.
------- This isn't specific to you Owen, but the group in general. I have been around for a while. Not as long as some others here. NAT is a feature and it does have a place. Security. I'm sorry that this frustrates people but security is a layered approach and it starts off simple. If you have a network that doesn't need exposure to the Internet or to someone else you can get fancy with anything from a FW to control source and destination or AD controls so only the accounting team can get in. Sure. They all work. You can also NAT them. Make them invisible. Or null the traffic. The more fundamental the point of defense is the easier it is to understand and sometimes the more difficult it becomes to bypass. Complex security adds a greater potential for vulnerabilities. If you want to protect your car stereo you could lock a cover over it right? But if you could, wouldn't you also just lock the car doors when you leave it? I'm not going to tell you that NAT guarantees you anything. We all know nothing is foolproof. But it is a fundamental feature that works for that purpose. Do I plan on NATting our edge Internet traffic? No. Not for IPv6. Because the protocol was not designed for it. But have I ruled it out as an option for some environments? No.
Bring on the flames. I know this is going to get people stirred up. I promise not to ignore the thread....
On Monday 16 July 2012 18:26:08 Rajendra Chayapathi wrote:
On the HSRP/ND part , this all falls in the First Hop redundancy areana and can be achieved via any of the following and each has its merits and cons..
1) Using ND -- need to tune the "IPv6 nd reachable time" to achieve the faster failover 2) Using any of the First hop redundancy protocol ( HSRP, VRRP , GLBP) 3) Default route selection.
In all honesty, I think using ND as the failover method is a generally bad idea - you have no way of ensuring all endpoints take note of or honour the router preference flag. Additionally, having a 1 second validity lifetime is going to create a lot of ICMPv6 spam across the segment - big deal? perhaps not. But when contrasted with the fact that it can be wholly avoided using one of the aforementioned redundancy protocols, why would you do it? Additionally, as an alternative to RAs, you can simply point default at the all-routers anycast address. Regards, Oliver
True .. Your point of the ICMPv6 storm is on mark and is one of the drawbacks for this solution. On 7/16/12 12:39 PM, "Oliver" <olipro@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa> wrote:
On Monday 16 July 2012 18:26:08 Rajendra Chayapathi wrote:
On the HSRP/ND part , this all falls in the First Hop redundancy areana and can be achieved via any of the following and each has its merits and cons..
1) Using ND -- need to tune the "IPv6 nd reachable time" to achieve the faster failover 2) Using any of the First hop redundancy protocol ( HSRP, VRRP , GLBP) 3) Default route selection.
In all honesty, I think using ND as the failover method is a generally bad idea - you have no way of ensuring all endpoints take note of or honour the router preference flag.
Additionally, having a 1 second validity lifetime is going to create a lot of ICMPv6 spam across the segment - big deal? perhaps not. But when contrasted with the fact that it can be wholly avoided using one of the aforementioned redundancy protocols, why would you do it?
Additionally, as an alternative to RAs, you can simply point default at the all-routers anycast address.
Regards, Oliver
On Jul 16, 2012, at 15:40, Oliver <olipro@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa> wrote:
Additionally, as an alternative to RAs, you can simply point default at the all-routers anycast address.
Wouldn't this result in duplicate packets leaving your network if there were more than 1 router listening to 'all routers' and you (at the MAC layer) multicasted to those listeners?
On Mon, 2012-07-16 at 23:38 -0400, Matt Addison wrote:
Oliver <olipro@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa> wrote:
Additionally, as an alternative to RAs, you can simply point default at the all-routers anycast address.
Wouldn't this result in duplicate packets leaving your network if there were more than 1 router listening to 'all routers' and you (at the MAC layer) multicasted to those listeners?
I think Oliver meant the subnet router anycast address. Anycast gets you to one-of-many. The routers work out which of them is currently getting the subnet router anycast traffic. If that router drops out for any reason, another of the routers available on the link takes over. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
On 7/16/12, Karl Auer <kauer@biplane.com.au> wrote:
I think Oliver meant the subnet router anycast address. Anycast gets you to one-of-many. The routers work out which of them is
Just to reaffirm that. Rfc 4291 states packets sent to the subnet-router anycast will be delivered to one router on the subnet. That's fine for traffic with a destination IP of the anycast address; they'll land on one of the routers, and perhaps one of the routers will respond. But what about packets with a destination address on another network and trying to use the anycast address as a 'gateway'? The destination IP in the IP packet header of the forwarded packet won't be the anycast address; the last known hardware address for the IP, if it's unicast, may be down, so it's probably nonsensical to enter an anycast address as default gateway, unless using the subnet anycast address as a router/gateway has special behavior defined elsewhere? RFC 4291 S2.6.1 http://tools.ietf.org/html/rfc4291 " Packets sent to the Subnet-Router anycast address will be delivered to one router on the subnet. All routers are required to support the Subnet-Router anycast addresses for the subnets to which they have interfaces. " -- -JH
On Tue, 2012-07-17 at 00:10 -0500, Jimmy Hess wrote:
Just to reaffirm that. Rfc 4291 states packets sent to the subnet-router anycast will be delivered to one router on the subnet. [...] But what about packets with a destination address on another network and trying to use the anycast address as a 'gateway'? The destination IP in the IP packet header of the forwarded packet won't be the anycast address; the last known hardware address for the IP, if it's unicast, may be down, so it's probably nonsensical to enter an anycast address as default gateway, unless using the subnet anycast address as a router/gateway has special behavior defined elsewhere?
I'm not sure I follow the logic there. If the anycast router changes the packet will be resent to the new subnet anycast router eventually (assuming some layer cares enough about the packet to resend it). The "last known hardware address" doesn't matter any more or less in this scenario than it does in any other routing situation. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
On 7/17/12, Karl Auer <kauer@biplane.com.au> wrote: [snip
I'm not sure I follow the logic there. If the anycast router changes the packet will be resent to the new subnet anycast router eventually (assuming some layer cares enough about the packet to resend it). The "last known hardware address" doesn't matter any more or less in this scenario than it does in any other routing situation.
The pertinent discussion is not about "any other routing situation"; it's about first hop redundancy. The "last known hardware address" is in the NDP table, so the packet retransmissions likely wind up in the same place Another problem is the subnet anycast address may find unwanted routers that have to listen on it, including routers with only one interface and incomplete routing info, and including some unauthorized 5-port IPv6 router someone smuggled into the building and plugged in somewhere. By contrast, a real FHRP that implements failover either uses a virtual hardware address, or a 'gratuitous arp' type mechanism, so the packet retransmissions will go to the live failover partner. -- -JH
On Jul 16, 2012, at 11:16 PM, Jimmy Hess wrote:
On 7/17/12, Karl Auer <kauer@biplane.com.au> wrote: [snip
I'm not sure I follow the logic there. If the anycast router changes the packet will be resent to the new subnet anycast router eventually (assuming some layer cares enough about the packet to resend it). The "last known hardware address" doesn't matter any more or less in this scenario than it does in any other routing situation.
The pertinent discussion is not about "any other routing situation"; it's about first hop redundancy.
The "last known hardware address" is in the NDP table, so the packet retransmissions likely wind up in the same place
NUD should actually take care of that.
Another problem is the subnet anycast address may find unwanted routers that have to listen on it, including routers with only one interface and incomplete routing info, and including some unauthorized 5-port IPv6 router someone smuggled into the building and plugged in somewhere.
Yep.
By contrast, a real FHRP that implements failover either uses a virtual hardware address, or a 'gratuitous arp' type mechanism, so the packet retransmissions will go to the live failover partner.
The whole concept of gratuitous arp is strictly IPv4. Owen
On Mon, 2012-07-16 at 23:44 -0700, Owen DeLong wrote:
The whole concept of gratuitous arp is strictly IPv4.
Isn't an unsolicited neighbour advertisement pretty much the same thing? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
On Jul 16, 2012, at 9:40 PM, Karl Auer wrote:
On Mon, 2012-07-16 at 23:38 -0400, Matt Addison wrote:
Oliver <olipro@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa> wrote:
Additionally, as an alternative to RAs, you can simply point default at the all-routers anycast address.
Wouldn't this result in duplicate packets leaving your network if there were more than 1 router listening to 'all routers' and you (at the MAC layer) multicasted to those listeners?
I think Oliver meant the subnet router anycast address.
Anycast gets you to one-of-many. The routers work out which of them is currently getting the subnet router anycast traffic. If that router drops out for any reason, another of the routers available on the link takes over.
Reread the spec... It gets the packet to one or more of the routers and it may well lead to packet duplication. There may or may not be coordination between the routers. It isn't in the spec. Owen
On Mon, 2012-07-16 at 23:36 -0700, Owen DeLong wrote:
Reread the spec... [the subnet router anycast address] gets the packet to one or more of the routers and it may well lead to packet duplication. There may or may not be coordination between the routers. It isn't in the spec.
Which spec? Looking at RFC 4291, Section 2.6.1: Packets sent to the Subnet-Router anycast address will be delivered to one router on the subnet. All routers are required to support the Subnet-Router anycast addresses for the subnets to which they have interfaces. The Subnet-Router anycast address is intended to be used for applications where a node needs to communicate with any one of the set of routers. But I do not have an encylopaedic knowledge of all the RFCs, so perhaps this has been superseded, obsoleted or updated... Reading it with a squint: The phrase "packets [...] will be delivered to one router on the subnet" does not specifically exclude the possibility that packets will be delivered to more than one router on the subnet. Still, I do think it would be a little unreasonable to interpret it thus. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
On Jul 17, 2012, at 3:15, Karl Auer <kauer@biplane.com.au> wrote:
Reading it with a squint: The phrase "packets [...] will be delivered to one router on the subnet" does not specifically exclude the possibility that packets will be delivered to more than one router on the subnet. Still, I do think it would be a little unreasonable to interpret it thus.
After reading some more I see how using subnet-router anycast works. The anycast address is global in scope so the end host will only learn 1 potential next hop at a time (the routers randomize a delay when responding to ND for a subnet-router anycast), and perform NUD as needed to determine if their current router is up or down (RFC4861). So you can get failover with no FHRP by using subnet-router anycast. You just won't get sub-second failover.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 7/17/2012 12:15 AM, Karl Auer wrote:
But I do not have an encylopaedic knowledge of all the RFCs, so perhaps this has been superseded, obsoleted or updated...
This gets a lot easier if you use the tools site: https://tools.ietf.org/html/rfc4291 - -- If you're never wrong, you're not trying hard enough -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBCAAGBQJQBaQrAAoJEFzGhvEaGryEJ/0H/jB6EpjYE9XMvT0twx0VGql9 K9uAfF62rnQ8bnN3upVo12EcvMuhJkNIl4YNUMc1rNajHGcXzEUtEVb3Uz/2RFgy hxrgzjCi8mc8ykkacCE5aLwckNvw3UvViTijLs4mao1Eks885TnVXEjj6hgL/PNy pgXNoU43bmYiFv2IvL2o+16q3Y/PzWJYGBt6+EfbtfcTbX3W/TfqUNMEyAxpz0PC DDhMLM6Z8RZWD9BKbs4Qe5Z+4gOeu32fuxZ+5Au1Lxw9w4Z41cR4mEil697tQwUL Pg1QDHAAce7NKOuRzInotIG8iwWcQEjYxNo+MKQZFUUUSJJoID3BzvwQkYdr6Lc= =IX7u -----END PGP SIGNATURE-----
On Jul 16, 2012, at 12:39 PM, Oliver wrote:
On Monday 16 July 2012 18:26:08 Rajendra Chayapathi wrote:
On the HSRP/ND part , this all falls in the First Hop redundancy areana and can be achieved via any of the following and each has its merits and cons..
1) Using ND -- need to tune the "IPv6 nd reachable time" to achieve the faster failover 2) Using any of the First hop redundancy protocol ( HSRP, VRRP , GLBP) 3) Default route selection.
In all honesty, I think using ND as the failover method is a generally bad idea - you have no way of ensuring all endpoints take note of or honour the router preference flag.
Huh? Any host which doesn't is provably buggy. I'm not saying it can't or won't happen, but, seriously? If the host is that buggy, you can't count on it using the fake MAC either.
Additionally, having a 1 second validity lifetime is going to create a lot of ICMPv6 spam across the segment - big deal? perhaps not. But when contrasted with the fact that it can be wholly avoided using one of the aforementioned redundancy protocols, why would you do it?
You don't need a 1 second valid timer (that would be absurd). You need a 1 second keep alive (if you really care about 1 second fast fall-over) and you're going to get just as much SPAM with sub-second fallover from any of the other solutions as well. They all send multicast packets.
Additionally, as an alternative to RAs, you can simply point default at the all-routers anycast address.
The disadvantage to this is the high probability of packet duplication. For someone worried about ICMP spam on the subnet, I'm surprised you're not worried about what happens when 2 or more routers copy the same packet and route both copies on to the end destination. (Lather, rinse, repeat said duplication for any upstream segments using such tactics as well). Owen
On Monday 16 July 2012 21:11:18 you wrote:
The disadvantage to this is the high probability of packet duplication. For someone worried about ICMP spam on the subnet, I'm surprised you're not worried about what happens when 2 or more routers copy the same packet and route both copies on to the end destination. (Lather, rinse, repeat said duplication for any upstream segments using such tactics as well).
No. The all-routers anycast address is resolved and creates a single Layer 2 neighbor entry - it may change, but there's no packet duplication issue here because routing of an individual packet will only ever go to a single host at L2, There is a difference between Multicast and Anycast. Regards, Oliver
hurdles. Example? HSRP IPv6 global addressing on Cisco ASR platform. If HSRP is a legacy proprietary protocol; try VRRP. Stateless autoconfig and router advertisements can obviate (eliminate/reduce)
On 7/16/12, -Hammer- <bhmccie@gmail.com> wrote: the need in many cases; albeit, with a longer failure recovery duration.
this morning from CheckPoint for NAT66. This should have been ready for prime time years ago. I guess the vendors weren't getting the push from
NAT66; you're talking about something that is not a mainline feature, an experimental proposition; RFC6296 produced in 2011. Very few IPv6 deployments should require prefix translation or any kind of NAT technology with IPv6, other than the IPv4 transition technologies. So... NO.. they should not have had this ready "for prime time" years ago. There are other things they should have been working on, such as getting the base IPv6 implementation correct, V6 connectivity, V6-enabled protocols, support for the newer RA/DHCPv6 options, and support for the newer more fully baked IPv4 transition specs such as 6to4, NAT-PT, and bugfixing. I'll take the stable platform, that has the standards-specified features, over one with bells and whistles, and the latest experimental draft features such as 6to6, that are not required to deploy IPv6, thanks. -- -JH
hurdles. Example? HSRP IPv6 global addressing on Cisco ASR platform. If HSRP is a legacy proprietary protocol; try VRRP. Stateless autoconfig and router advertisements can obviate (eliminate/reduce)
On 7/16/12, -Hammer- <bhmccie@gmail.com> wrote: the need in many cases; albeit, with a longer failure recovery duration. This isn't PAGP vs LACP again is it? Can someone show me a sunset document for HSRP from Cisco? Yes, VRRP, I use it as well. But that's not the point. The point is that it's a feature from a vendor that lacks
this morning from CheckPoint for NAT66. This should have been ready for prime time years ago. I guess the vendors weren't getting the push from NAT66; you're talking about something that is not a mainline feature, an experimental proposition; RFC6296 produced in 2011. Very few IPv6 deployments should require prefix translation or any kind of NAT technology with IPv6, other than the IPv4 transition technologies.
So... NO.. they should not have had this ready "for prime time" years ago. I disagree. I was asking security vendors what they were doing about
-Hammer- "I was a normal American nerd" -Jack Herer On 7/16/2012 11:18 PM, Jimmy Hess wrote: parity across the product suites. Like most of the folks out there, I run IOS, NX-OS, IOS-XE, etc and that's just from Cisco. Feature parity is a big gripe that doesn't have an easy solution. I feel for the vendors but at the same time I'm frustrated when I read a document on a function and realize afterwards I can only deploy it on "some" of my up to date products. That's the point. these kinds of future needs years ago. Many years ago. They all conceded that they had had similar requests from other customers but the demand wasn't there yet. They should have had more vision on their road maps but they focused on basic functionality of the protocol and not features beyond that and now they are playing catch up. I understand, they were focused on what features were getting the attention. That's business. But everyone knew the depletion rates and everyone knew that whether the pompous USA wanted it or not IPv6 was coming in the late 2000s and early 2010s. So they should have been more diligent. You can pull up any marketing document from any vendor and they will tell you IPv6 is fully supported. But when you implement features (who the heck runs a default config these days?) you really test the functionality of the product.
There are other things they should have been working on, such as getting the base IPv6 implementation correct, V6 connectivity, V6-enabled protocols, support for the newer RA/DHCPv6 options, and support for the newer more fully baked IPv4 transition specs such as 6to4, NAT-PT, and bugfixing.
I'll take the stable platform, that has the standards-specified features, over one with bells and whistles, and the latest experimental draft features such as 6to6, that are not required to deploy IPv6, thanks. I agree. Stability. But a stable platform that doesn't have the features I need is not a stable platform I can invest in. Cart before horse.
-- -JH
I wonder who really believes there is no usage case for NAT66. Have these people seen non-trivial corporate networks? I'm sure many people in this list finance part of their lives with renumber projects costing MUSDs. For many companies just finding out where addresses have been punched in (your FWs, your software, partner FWs, partner software, configurations...) will take months, before even starting renumbering. If my enterprise customers don't have plan and ask my advice, I will recommend own PI, if they don't want (extra cost, extra clue needed) ULA and NAT66. If I recommend more specific from our PA, I know when they switch operators in few years time, some of them will decide renumbering is out-of-the-question[0] and will NAT my PA to new operator PA, essentially forcing me to never return any addresses to my free pool. I wonder if that is valid reason to ask more allocations? That address was once used? More specific from our PA is fine for small offices with trivial setup, residential networks and few niche shops who specifically design for renumbering (but I guess these most often already want PI+BGP) [0] I don't want NAT66 anywhere. I won't use NAT66 anywhere. But just because we have new protocol, does not mean we have new set of people, who share my ideologies and goals about network design. Only thing I can do, is protect myself from problems they would cause me. -- ++ytti
There's are routing and switching people and there are security people. And they look at things different. That, IMHO, is the root of the emotion on this thread. No one is actually wrong except me for stirring the pot as the OP. :) -Hammer- "I was a normal American nerd" -Jack Herer On 7/17/2012 7:47 AM, Saku Ytti wrote:
I wonder who really believes there is no usage case for NAT66. Have these people seen non-trivial corporate networks?
I'm sure many people in this list finance part of their lives with renumber projects costing MUSDs. For many companies just finding out where addresses have been punched in (your FWs, your software, partner FWs, partner software, configurations...) will take months, before even starting renumbering.
If my enterprise customers don't have plan and ask my advice, I will recommend own PI, if they don't want (extra cost, extra clue needed) ULA and NAT66. If I recommend more specific from our PA, I know when they switch operators in few years time, some of them will decide renumbering is out-of-the-question[0] and will NAT my PA to new operator PA, essentially forcing me to never return any addresses to my free pool. I wonder if that is valid reason to ask more allocations? That address was once used?
More specific from our PA is fine for small offices with trivial setup, residential networks and few niche shops who specifically design for renumbering (but I guess these most often already want PI+BGP)
[0] I don't want NAT66 anywhere. I won't use NAT66 anywhere. But just because we have new protocol, does not mean we have new set of people, who share my ideologies and goals about network design. Only thing I can do, is protect myself from problems they would cause me.
On 7/17/2012 5:47 AM, Saku Ytti wrote:
I wonder who really believes there is no usage case for NAT66. Have these people seen non-trivial corporate networks?
I'm sure many people in this list finance part of their lives with renumber projects costing MUSDs. For many companies just finding out where addresses have been punched in (your FWs, your software, partner FWs, partner software, configurations...) will take months, before even starting renumbering.
For those with PA space https://tools.ietf.org/html/rfc6144 should be a good solution. Doug -- If you're never wrong, you're not trying hard enough
With all due respect to Owen, I don't share the view that everyone should be jumping into BGP or getting an allocation from ARIN, but that's been a long-standing debate between us. NPT allows you to get prefixes from multiple ISPs without having to get an allocation to coordinate routing; or in the other example, without having to have host systems maintain multiple global prefixes (which quickly becomes a security nightmare for auditing; a troubleshooting nightmare for support, etc). As far as it being costly, I think too much of the mindset on list is the large network or ISP perspective; for the small network that NPT is targeting, all this would happen in some "Dual WAN" multi-function firewall appliance. Modern hardware is often powerful enough to vastly exceed transport capacity for these networks, so the performance "cost" is a non-issue. All these other methods place far too much control on the host system (and its implementation) to be ready for prime time yet; the reality is that without NPT being widely available, we won't see 99% of small businesses using IPv6 for a long time, so if our goal is IPv6 adoption maybe it's time we stop the holy war on anything "NAT". Hammer has echoed legitimate concerns and confusion that represents a very large portion of the user base out there. Maybe we should be asking why that is instead of telling him he doesn't understand anything and that NAT is "evil". -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On Sat, 14 Jul 2012 15:14:45 -0500, -Hammer- said:
The whole purpose of this is that they do NOT need to be global. Security thru obscurity. It actually has a place in some worlds. Does that make sense? Or are such V4-centric approaches a bad thing in v6?
The fact that your prefix is a Secret Sauce that isn't known to the rest of the world won't matter much to an attacker. One 'ifconfig' on whatever beachhead machine the attacker has inside your net, and it's not Secret Sauce anymore, it's just another bottle of Thousand Island dressing...
The fact that your prefix is a Secret Sauce that isn't known to the rest of the world won't matter much to an attacker. One 'ifconfig' on whatever beachhead machine the attacker has inside your net, and it's not Secret Sauce anymore, it's just another bottle of Thousand Island dressing...
security through obsurity is such tempting koolaid. people fall for it continually and repeatedly. i especially like the one where filtering ula at your border is thought to be any different than filtering a bit of global at your border. randy
Randy Bush wrote:
The fact that your prefix is a Secret Sauce that isn't known to the rest of the world won't matter much to an attacker. One 'ifconfig' on whatever beachhead machine the attacker has inside your net, and it's not Secret Sauce anymore, it's just another bottle of Thousand Island dressing...
security through obsurity is such tempting koolaid. people fall for it continually and repeatedly.
Some people have different Layer 8-9 requirements than others. I am not saying they are 'right', just that 'easier' is a relative term based on what part of the problem is generating the most heat at the moment.
i especially like the one where filtering ula at your border is thought to
be any
different than filtering a bit of global at your border.
There is no difference in the local filtering function, but *IF* all transit providers put FC00::/7 in bogon space and filter it at every border, there is a clear benefit when someone fat-fingers the config script and announces what should be a locally filtered prefix (don't we routinely see unintended announcements in the global BGP table). I realize that is a big IF, but bogon filtering happens fairly consistently in IPv4, so there is no reason to believe it will be less so in IPv6. Tony
i especially like the one where filtering ula at your border is thought to be any different than filtering a bit of global at your border. There is no difference in the local filtering function, but *IF* all transit providers put FC00::/7 in bogon space and filter it at every border
and this works so well with rfc 1918 space and other v4 bogons. not. randy
On 2012-07-15 00:45, Tony Hain wrote:
There is no difference in the local filtering function, but *IF* all transit providers put FC00::/7 in bogon space and filter it at every border, there is a clear benefit when someone fat-fingers the config script and announces what should be a locally filtered prefix (don't we routinely see unintended announcements in the global BGP table). I realize that is a big IF, but
There was also in the past fec0::/10. For BGP updates you should be safe to filter out FC00::/6. -- Grzegorz Janoszka
On 7/15/12 5:38 AM, Grzegorz Janoszka wrote:
On 2012-07-15 00:45, Tony Hain wrote:
There is no difference in the local filtering function, but *IF* all transit providers put FC00::/7 in bogon space and filter it at every border, there is a clear benefit when someone fat-fingers the config script and announces what should be a locally filtered prefix (don't we routinely see unintended announcements in the global BGP table). I realize that is a big IF, but There was also in the past fec0::/10. For BGP updates you should be safe to filter out FC00::/6.
Unless I've missed something, RFC4193 lays out FC00::/7, not the /6. So while FE00::/7 may yet be unallocated, I don't think I'd set filters in that fashion. Reasonably, wouldn't it be more likely to permit BGP advertisements within the 2000::/3 range as that's the "active" space currently? Scott
On Jul 15, 2012 9:30 AM, "Scott Morris" <swm@emanon.com> wrote:
On 7/15/12 5:38 AM, Grzegorz Janoszka wrote:
On 2012-07-15 00:45, Tony Hain wrote:
There is no difference in the local filtering function, but *IF* all
providers put FC00::/7 in bogon space and filter it at every border,
transit there
is a clear benefit when someone fat-fingers the config script and announces what should be a locally filtered prefix (don't we routinely see unintended announcements in the global BGP table). I realize that is a big IF, but There was also in the past fec0::/10. For BGP updates you should be safe to filter out FC00::/6.
Unless I've missed something, RFC4193 lays out FC00::/7, not the /6. So while FE00::/7 may yet be unallocated, I don't think I'd set filters in that fashion.
Reasonably, wouldn't it be more likely to permit BGP advertisements within the 2000::/3 range as that's the "active" space currently?
Scott
Yep. That's what we do, permit 2000::/3, with a deny statement for the documentation range and small prefixes. CB
On 2012-07-15 15:30, Scott Morris wrote:
There was also in the past fec0::/10. For BGP updates you should be safe to filter out FC00::/6. Unless I've missed something, RFC4193 lays out FC00::/7, not the /6. So while FE00::/7 may yet be unallocated, I don't think I'd set filters in that fashion. Reasonably, wouldn't it be more likely to permit BGP advertisements within the 2000::/3 range as that's the "active" space currently?
FF00::/8 are multicast, FE80::/10 are reserved for link-local. In the past you had FEC0::/10 as a kind of private addresses. Allowing 2000::/3 is fine as well. Btw - what are the estimates - how long are we going to be within 2000::/3? -- Grzegorz Janoszka
On 15 July 2012 16:58, Grzegorz Janoszka <Grzegorz@janoszka.pl> wrote:
Allowing 2000::/3 is fine as well. Btw - what are the estimates - how long are we going to be within 2000::/3?
I expect it to be long enough that we can enjoy lots of discussions about how to deal with broken route filtering and broken software that assumes only 2000::/3 is valid, and we can talk about how we should have seen this coming and done something differently to prevent it. - Mike
On Jul 15, 2012, at 8:58 AM, Grzegorz Janoszka wrote:
On 2012-07-15 15:30, Scott Morris wrote:
There was also in the past fec0::/10. For BGP updates you should be safe to filter out FC00::/6. Unless I've missed something, RFC4193 lays out FC00::/7, not the /6. So while FE00::/7 may yet be unallocated, I don't think I'd set filters in that fashion. Reasonably, wouldn't it be more likely to permit BGP advertisements within the 2000::/3 range as that's the "active" space currently?
FF00::/8 are multicast, FE80::/10 are reserved for link-local. In the past you had FEC0::/10 as a kind of private addresses.
Allowing 2000::/3 is fine as well. Btw - what are the estimates - how long are we going to be within 2000::/3?
Quite probably longer than anyone now reading this message will be alive. So far, I believe IANA has allocated 6 or 7 of the /12s from 2000::/3 to RIRs. That leaves at least 500+ /12s still to go. Even with ARIN's extremely liberal policies, I expect ARIN will be able to number all of their service region in its current state from 3 or 4 /12s. Assuming this somewhat follows world population, APNIC should require <=12 /12s, RIPE should need <= 6 /12s, AfriNIC should require <= 6 /12s, and LACNIC should require <= 4 /12s. Adding that up, I get 4+12+6+6+4 = 32 /12s if the entire world were to adopt ARIN's extremely liberal (which I think is a good thing) IPv6 allocation policies. Assuming that the world population (and thus address need) continues on a 1.5% per year growth trajectory, that would double the population every 46+ years. With a lifespan of ~100 years and assuming that everyone reading this is now over the age of 10, that's 4*32 = 128 /12s in the next 92 years, leaving us with 384 /12s still sitting on the shelf after the last of us now reading this message is dead. So, even if I'm wrong and it's 3 times what I anticipate, we still won't use up 2000::/3 in any of our lifetimes. Owen
On 7/15/12 11:58 AM, Grzegorz Janoszka wrote:
There was also in the past fec0::/10. For BGP updates you should be safe to filter out FC00::/6. Unless I've missed something, RFC4193 lays out FC00::/7, not the /6. So while FE00::/7 may yet be unallocated, I don't think I'd set filters in that fashion. Reasonably, wouldn't it be more likely to permit BGP advertisements within the 2000::/3 range as that's the "active" space currently? FF00::/8 are multicast, FE80::/10 are reserved for link-local. In the
On 2012-07-15 15:30, Scott Morris wrote: past you had FEC0::/10 as a kind of private addresses.
Allowing 2000::/3 is fine as well. Btw - what are the estimates - how long are we going to be within 2000::/3?
hehehhe.. Long enough for us to forget what prefix lists we put on to begin with and need to look them back up!
On 7/14/12, valdis.kletnieks@vt.edu <valdis.kletnieks@vt.edu> wrote: [snip]
The fact that your prefix is a Secret Sauce that isn't known to the rest of the world won't matter much to an attacker. One 'ifconfig' on whatever beachhead machine the attacker has inside your net, and it's not Secret Sauce anymore, it's just another bottle of Thousand Island dressing...
The good news is one 'ifconfig' just tells them what network address you're in. Unless the attacker can gain access to your host's NDP table or ARP table, they can't see what IPs are in use. You're Global or whatever /64 has ~18446744073709551615 possible IP addresses. If you want your addressing assignments to be "obscure", generate a random interface ID, and use that to assign your IPv6 addresses within your public /64, or just use stateless autoconfig. -- -JH
On Sat, 14 Jul 2012 17:37:37 -0500, Jimmy Hess said:
The good news is one 'ifconfig' just tells them what network address you're in. Unless the attacker can gain access to your host's NDP table or ARP table, they can't see what IPs are in use.
All it takes is one USB stick left out in the parking lot for an employee.. By the time they get enough access to do an 'ifconfig', rest assured that they can see the NDP/ARP tables and all the traffic on that network segment as well. (OK.. maybe for some reason they can't - but if you're betting your security model on somebody getting a beachhead on one of your machines and *not* having full access to the network segment, I'll be more than happy to take the other side of the bet).
On Fri, Jul 13, 2012 at 11:05 AM, TJ <trejrco@gmail.com> wrote:
On Fri, Jul 13, 2012 at 10:38 AM, -Hammer- <bhmccie@gmail.com> wrote:
OK. I'm pretty sure I'm gonna get some flak for this but I'll share this question and it's background anyway. Please be gentle.
In the past, with IPv4, we have used reserved or "non-routable" space Internally in production for segments that won't be seen anywhere else. Examples? A sync VLAN for some FWs to share state. An IBGP link between routers that will never be seen or advertised. In those cases, we have often used 192.0.2.0/24. It's reserved and never used and even if it did get used one day we aren't "routing" it internally. It's just on segments where we need some L3 that will never be seen.
On to IPv6
I was considering taking the same approach. Maybe using 0100::/8 or 1000::/4 or A000::/3 as a space for this.
Would using "just" Link Locals not be sufficient? *(Failing that, as others noted, ULAs are the next "right" answer ... )* * * /TJ
As an IPv6 newbie myself, I wonder how hosts handle link local, ULA and global addresses. For example, if you have some internal web traffic used for intranet use only, do you bind those servers to use only ULA addresses? This way your internal users with ULA addressing only have access to those servers? No need to give intranet-only servers a global address if they're not needed to be accessed globally. Is there a way for hosts to "prefer" or "attempt" to connect to a service by first trying a link-local scope, then a ULA and finally a global address if its off the AS? I really like the idea of ULA and think it makes much more sense than RFC1918 + NAT. I just don't have any deployment experience with it yet so I'm curious how the host would handle it. On the router side, I'm sure ULA and global routing just run as ships-in-the-night side-by-side anyways...right? -- Thomas Cooper
On 13 Jul 2012, at 17:11, Tom Cooper wrote:
On Fri, Jul 13, 2012 at 11:05 AM, TJ <trejrco@gmail.com> wrote:
As an IPv6 newbie myself, I wonder how hosts handle link local, ULA and global addresses. For example, if you have some internal web traffic used for intranet use only, do you bind those servers to use only ULA addresses? This way your internal users with ULA addressing only have access to those servers? No need to give intranet-only servers a global address if they're not needed to be accessed globally.
Is there a way for hosts to "prefer" or "attempt" to connect to a service by first trying a link-local scope, then a ULA and finally a global address if its off the AS?
There is an RFC that describes how hosts should select addresses in such situations, http://tools.ietf.org/html/rfc3484 As an side; it would be great if some more IPv6 questions could be put on http://ipv6exchange.net/ - I would love to see that become a useful resource for people starting out with IPv6. If you have an IPv6 question, please do post! Cheers, aid
I'm having similar thoughts and we are about to implement. Fortunately we are implementing in an isolated lab first for this exact reason. For us to figure things out first before attempting them elsewhere. I like the ULA approach. I'm not sure about link local being used as strategy for Internal services. I'm finally getting to the point where I'm looking past the vastness of the numbers and just focusing on subnets and masks and subnetting and whatnot. -Hammer- "I was a normal American nerd" -Jack Herer On 7/13/2012 11:11 AM, Tom Cooper wrote:
On Fri, Jul 13, 2012 at 11:05 AM, TJ <trejrco@gmail.com <mailto:trejrco@gmail.com>> wrote:
On Fri, Jul 13, 2012 at 10:38 AM, -Hammer- <bhmccie@gmail.com <mailto:bhmccie@gmail.com>> wrote:
> OK. I'm pretty sure I'm gonna get some flak for this but I'll share this > question and it's background anyway. Please be gentle. > > In the past, with IPv4, we have used reserved or "non-routable" space > Internally in production for segments that won't be seen anywhere else. > Examples? A sync VLAN for some FWs to share state. An IBGP link between > routers that will never be seen or advertised. In those cases, we have > often used 192.0.2.0/24 <http://192.0.2.0/24>. It's reserved and never used and even if it did > get used one day we aren't "routing" it internally. It's just on segments > where we need some L3 that will never be seen. > > On to IPv6 > > I was considering taking the same approach. Maybe using 0100::/8 or > 1000::/4 or A000::/3 as a space for this. >
Would using "just" Link Locals not be sufficient? *(Failing that, as others noted, ULAs are the next "right" answer ... )* * * /TJ
As an IPv6 newbie myself, I wonder how hosts handle link local, ULA and global addresses. For example, if you have some internal web traffic used for intranet use only, do you bind those servers to use only ULA addresses? This way your internal users with ULA addressing only have access to those servers? No need to give intranet-only servers a global address if they're not needed to be accessed globally.
Is there a way for hosts to "prefer" or "attempt" to connect to a service by first trying a link-local scope, then a ULA and finally a global address if its off the AS? I really like the idea of ULA and think it makes much more sense than RFC1918 + NAT. I just don't have any deployment experience with it yet so I'm curious how the host would handle it.
On the router side, I'm sure ULA and global routing just run as ships-in-the-night side-by-side anyways...right?
-- Thomas Cooper
Note that I meant using Link Locals for directly connected devices *(neighbors; e.g. - routing protocol neighborship formation)*. If they are not on-link with each other, Link Locals are a non-starter ... ULAs would be a possible solution for a completely disconnected network. Note that many are proponents of using Globals even in those situations, with judicious filtering stopping any inboud/outbound traffic. The benefit being that "it's never going to be connected " doesn't really, always mean "it's never going to be connected" :). *YMMV, as always!* /TJ On Fri, Jul 13, 2012 at 12:21 PM, -Hammer- <bhmccie@gmail.com> wrote:
I'm having similar thoughts and we are about to implement. Fortunately we are implementing in an isolated lab first for this exact reason. For us to figure things out first before attempting them elsewhere.
I like the ULA approach. I'm not sure about link local being used as strategy for Internal services. I'm finally getting to the point where I'm looking past the vastness of the numbers and just focusing on subnets and masks and subnetting and whatnot.
-Hammer-
"I was a normal American nerd" -Jack Herer
On 7/13/2012 11:11 AM, Tom Cooper wrote:
On Fri, Jul 13, 2012 at 11:05 AM, TJ <trejrco@gmail.com> wrote:
On Fri, Jul 13, 2012 at 10:38 AM, -Hammer- <bhmccie@gmail.com> wrote:
OK. I'm pretty sure I'm gonna get some flak for this but I'll share this question and it's background anyway. Please be gentle.
In the past, with IPv4, we have used reserved or "non-routable" space Internally in production for segments that won't be seen anywhere else. Examples? A sync VLAN for some FWs to share state. An IBGP link between routers that will never be seen or advertised. In those cases, we have often used 192.0.2.0/24. It's reserved and never used and even if it did get used one day we aren't "routing" it internally. It's just on segments where we need some L3 that will never be seen.
On to IPv6
I was considering taking the same approach. Maybe using 0100::/8 or 1000::/4 or A000::/3 as a space for this.
Would using "just" Link Locals not be sufficient? *(Failing that, as others noted, ULAs are the next "right" answer ... )* * * /TJ
As an IPv6 newbie myself, I wonder how hosts handle link local, ULA and global addresses. For example, if you have some internal web traffic used for intranet use only, do you bind those servers to use only ULA addresses? This way your internal users with ULA addressing only have access to those servers? No need to give intranet-only servers a global address if they're not needed to be accessed globally.
Is there a way for hosts to "prefer" or "attempt" to connect to a service by first trying a link-local scope, then a ULA and finally a global address if its off the AS? I really like the idea of ULA and think it makes much more sense than RFC1918 + NAT. I just don't have any deployment experience with it yet so I'm curious how the host would handle it.
On the router side, I'm sure ULA and global routing just run as ships-in-the-night side-by-side anyways...right?
-- Thomas Cooper
-Hammer- <bhmccie@gmail.com> a écrit sur 13/07/2012 12:21:13 PM :
I like the ULA approach.
Global and ULA are two approach, but there's a third one: GUA + ULA. We actually put a GUA on servers speaking publicly, a ULA on servers speaking in our domain only and *both* ULA and GUA on servers which talk both ways. Our datacenter firewalls are configured to enforce GUA-GUA and ULA-ULA connections only (just simple URPF over two interfaces). This setup works very well, surprisingly we've had very little source address selection problems so far (knock on wood). We're very happy that the separation between public and "private" networks is clear, it helps a lot with debugging and service separation. /JF
On Fri, Jul 13, 2012 at 1:56 PM, <Jean-Francois.TremblayING@videotron.com>wrote:
-Hammer- <bhmccie@gmail.com> a écrit sur 13/07/2012 12:21:13 PM :
I like the ULA approach.
Global and ULA are two approach, but there's a third one: GUA + ULA. We actually put a GUA on servers speaking publicly, a ULA on servers speaking in our domain only and *both* ULA and GUA on servers which talk both ways. Our datacenter firewalls are configured to enforce GUA-GUA and ULA-ULA connections only (just simple URPF over two interfaces).
This setup works very well, surprisingly we've had very little source address selection problems so far (knock on wood). We're very happy that the separation between public and "private" networks is clear, it helps a lot with debugging and service separation.
Of the top of my head, the first problem you might hit there is WRT multicast ... *(ULA might "win" some source address selections that you want GUA to win)* /TJ
TJ <trejrco@gmail.com> a écrit sur 13/07/2012 02:47:26 PM :
Of the top of my head, the first problem you might hit there is WRT multicast ... (ULA might "win" some source address selections that you want GUA to win) /TJ
Good point, thanks for pointing that out. We'll see when we deploy network-wide IPv6 multicast... not there (yet). /JF
On 2012-07-13 18:11, Tom Cooper wrote: [..]
As an IPv6 newbie myself
Play with it and get your ears wet, it is still not entirely too late to start to learn to swim ;)
, I wonder how hosts handle link local, ULA and global addresses. For example, if you have some internal web traffic used for intranet use only, do you bind those servers to use only ULA addresses? This way your internal users with ULA addressing only have access to those servers? No need to give intranet-only servers a global address if they're not needed to be accessed globally.
You could do that indeed, thus have clients have only a global (and link-local address) and only make a certain prefix, be that ULA or a specific chunk of your global prefix only available to your internal network that are used for your internal services. As long as the prefix is stable you likely do not care if it is global or ULA, this as when a misconfiguration happens in such a way that that prefix is not properly firewalled away or gets routed it happened. As can be clearly seen in various routing tables filtering is not happening everywhere, thus it won't buy you that much; proper policy, automation and verification will avoid fat fingers much better though. Also, not that a firewalled prefix only brings one that much security, the higher chance is that the client host gets infected or compromised.
Is there a way for hosts to "prefer" or "attempt" to connect to a service by first trying a link-local scope, then a ULA and finally a global address if its off the AS?
RFC3484, aka /etc/gai.conf and friends on other OSs. It is not easy to distribute this though.
I really like the idea of ULA and think it makes much more sense than RFC1918 + NAT. I just don't have any deployment experience with it yet so I'm curious how the host would handle it.
ULA is meant for non-internet connected devices. As such NAT does not come into play as one will have a unique ULA prefix that will not clash when you inter connect them privately with other networks. RFC1918 + NAT primarily makes sense as it allows one to hookup devices to the Internet without 'wasting' more public addresses, that problem does not exist with IPv6 though. Greets, Jeroen
On Jul 13, 2012, at 8:05 AM, TJ wrote:
On Fri, Jul 13, 2012 at 10:38 AM, -Hammer- <bhmccie@gmail.com> wrote:
OK. I'm pretty sure I'm gonna get some flak for this but I'll share this question and it's background anyway. Please be gentle.
In the past, with IPv4, we have used reserved or "non-routable" space Internally in production for segments that won't be seen anywhere else. Examples? A sync VLAN for some FWs to share state. An IBGP link between routers that will never be seen or advertised. In those cases, we have often used 192.0.2.0/24. It's reserved and never used and even if it did get used one day we aren't "routing" it internally. It's just on segments where we need some L3 that will never be seen.
On to IPv6
I was considering taking the same approach. Maybe using 0100::/8 or 1000::/4 or A000::/3 as a space for this.
Would using "just" Link Locals not be sufficient?
If they're on the same link, of course. My understanding of the question said "they're not on the same link".
*(Failing that, as others noted, ULAs are the next "right" answer ... )* * * /TJ
See RFC 3849 - http://tools.ietf.org/html/rfc3849 Which pre-scribed the range: 2001:DB8::/32 for use in Documentation. I suppose this could be used for lab testing. *ducks flames* * * *Skeeve Stevens, CEO - *eintellego Pty Ltd skeeve@eintellego.net ; www.eintellego.net Phone: 1300 753 383; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego ; <http://twitter.com/networkceoau> linkedin.com/in/skeeve twitter.com/networkceoau ; blog: www.network-ceo.net The Experts Who The Experts Call Juniper - Cisco – IBM On Sat, Jul 14, 2012 at 12:38 AM, -Hammer- <bhmccie@gmail.com> wrote:
OK. I'm pretty sure I'm gonna get some flak for this but I'll share this question and it's background anyway. Please be gentle.
In the past, with IPv4, we have used reserved or "non-routable" space Internally in production for segments that won't be seen anywhere else. Examples? A sync VLAN for some FWs to share state. An IBGP link between routers that will never be seen or advertised. In those cases, we have often used 192.0.2.0/24. It's reserved and never used and even if it did get used one day we aren't "routing" it internally. It's just on segments where we need some L3 that will never be seen.
On to IPv6
I was considering taking the same approach. Maybe using 0100::/8 or 1000::/4 or A000::/3 as a space for this.
Other than the usual "Hey, you shouldn't do that" can anyone give me some IPv6 specific reasons that I may not be forecasting that would make it worse doing this than in an IPv4 scenario. I know, not apples to apples but for this question they are close enough. Unless there is something IPv6 specific that is influencing this....
--
-Hammer-
"I was a normal American nerd" -Jack Herer
Le 13/07/12 16:38, -Hammer- a écrit :
In the past, with IPv4, we have used reserved or "non-routable"
I guess "non-routable IPv4" translates well to "non-routable IPv6", thus putting Link-Local addresses on top of the list. Thought you may use th auto-configured addresses for that purpose, you also may set LLAs to your liking. I use fe80::zone_ID:interface_ID , and set such LLA to every gateways to make routing tables more legible, those ID beeing arbitrary 16bit values. Any other address class will work well, but I'd rather not use reserved space outside of GUA, ULA our LLA scopes to avoid bug-hunting on poorly implemented IPv6 stacks. -- Jérôme Nicolle +33 6 19 31 27 14
On Jul 14, 2012, at 9:08 AM, Jérôme Nicolle wrote:
Le 13/07/12 16:38, -Hammer- a écrit :
In the past, with IPv4, we have used reserved or "non-routable"
I guess "non-routable IPv4" translates well to "non-routable IPv6", thus putting Link-Local addresses on top of the list.
Thought you may use th auto-configured addresses for that purpose, you also may set LLAs to your liking. I use fe80::zone_ID:interface_ID , and set such LLA to every gateways to make routing tables more legible, those ID beeing arbitrary 16bit values.
Given that zone_IDs in my environments consist of terms like: fxp0 en0 eth0 ge-0/0/0.0 etc. How, exactly, would you turn those into part of an IPv6 address?
Any other address class will work well, but I'd rather not use reserved space outside of GUA, ULA our LLA scopes to avoid bug-hunting on poorly implemented IPv6 stacks.
+1 However, I still think GUA is the best, most flexible choice. Owen
On Saturday 14 July 2012 09:18:48 Owen DeLong wrote:
Given that zone_IDs in my environments consist of terms like:
fxp0 en0 eth0 ge-0/0/0.0 etc.
How, exactly, would you turn those into part of an IPv6 address?
UTF-8? ASCII? if you go with a custom encoding and do 0-9,a-z, plus a few symbols you can get 6 bits per char for a grand total of 10 chars squeezed into 8 octets.
Any other address class will work well, but I'd rather not use reserved space outside of GUA, ULA our LLA scopes to avoid bug-hunting on poorly implemented IPv6 stacks.
+1
However, I still think GUA is the best, most flexible choice.
This brings up the question of "what is outside of LLA scope" - to my mind it's everything outside of fe80::/10 - in reality, there's that unfortunate tendency for it to be considered fe80::/64 when it comes down to implementation. Regards, Oliver
On Sat, 2012-07-14 at 09:18 -0700, Owen DeLong wrote:
On Jul 14, 2012, at 9:08 AM, Jérôme Nicolle wrote:
Le 13/07/12 16:38, -Hammer- a écrit :
In the past, with IPv4, we have used reserved or "non-routable"
I guess "non-routable IPv4" translates well to "non-routable IPv6", thus putting Link-Local addresses on top of the list.
Thought you may use th auto-configured addresses for that purpose, you also may set LLAs to your liking. I use fe80::zone_ID:interface_ID , and set such LLA to every gateways to make routing tables more legible, those ID beeing arbitrary 16bit values.
Given that zone_IDs in my environments consist of terms like:
fxp0 en0 eth0 ge-0/0/0.0 etc.
How, exactly, would you turn those into part of an IPv6 address?
Hi, We use LLA to "virtualize" interconnection to our users: their network configuration is always static default via fe80::nnnn and we route their /56 prefix to fe80::xxxx:yyyy where xxxx:yyyy is unique per user - if our user want to do some routing of course. Since we don't have GUA interconnections we don't have to manage them inside our AS and we can move user stuff around without having them changing anything to their static configuration. We give a /56 IPv6 per /32 IPv4 to our user which does /48 = /24 = 256 "IP", it's nice to have more than one /64 around for some uses. Is there any "mass" hoster around that does provide by default a pefix larger than /64 and that does route it to the user? It's quite simple to do in IPv6 and we have the address space for it. Sincerely, Laurent
On Jul 14, 2012, at 2:04 PM, Laurent GUERBY wrote:
On Sat, 2012-07-14 at 09:18 -0700, Owen DeLong wrote:
On Jul 14, 2012, at 9:08 AM, Jérôme Nicolle wrote:
Le 13/07/12 16:38, -Hammer- a écrit :
In the past, with IPv4, we have used reserved or "non-routable"
I guess "non-routable IPv4" translates well to "non-routable IPv6", thus putting Link-Local addresses on top of the list.
Thought you may use th auto-configured addresses for that purpose, you also may set LLAs to your liking. I use fe80::zone_ID:interface_ID , and set such LLA to every gateways to make routing tables more legible, those ID beeing arbitrary 16bit values.
Given that zone_IDs in my environments consist of terms like:
fxp0 en0 eth0 ge-0/0/0.0 etc.
How, exactly, would you turn those into part of an IPv6 address?
Hi,
We use LLA to "virtualize" interconnection to our users: their network configuration is always static default via fe80::nnnn and we route their /56 prefix to fe80::xxxx:yyyy where xxxx:yyyy is unique per user - if our user want to do some routing of course. Since we don't have GUA interconnections we don't have to manage them inside our AS and we can move user stuff around without having them changing anything to their static configuration.
We give a /56 IPv6 per /32 IPv4 to our user which does /48 = /24 = 256 "IP", it's nice to have more than one /64 around for some uses.
Is there any "mass" hoster around that does provide by default a pefix larger than /64 and that does route it to the user? It's quite simple to do in IPv6 and we have the address space for it.
Sincerely,
Laurent
Why not just give each end-site a /48? An end-site with a /24 may only need a single or a few subnets while an end-site with a /32 may have a host of subnets behind their IPv4 NAT gateway. Making IPv6 topological assumptions for your end-users based on their IPv4 presentation makes little sense to me and is likely a disservice to your end users. Owen
Hi, On Sat, 2012-07-14 at 17:02 -0700, Owen DeLong wrote:
Hi,
We use LLA to "virtualize" interconnection to our users: their network configuration is always static default via fe80::nnnn and we route their /56 prefix to fe80::xxxx:yyyy where xxxx:yyyy is unique per user - if our user want to do some routing of course. Since we don't have GUA interconnections we don't have to manage them inside our AS and we can move user stuff around without having them changing anything to their static configuration.
We give a /56 IPv6 per /32 IPv4 to our user which does /48 = /24 = 256 "IP", it's nice to have more than one /64 around for some uses.
Is there any "mass" hoster around that does provide by default a pefix larger than /64 and that does route it to the user? It's quite simple to do in IPv6 and we have the address space for it.
Why not just give each end-site a /48?
We give a /48 on request, a /56 by default (and we never give a /64).
An end-site with a /24 may only need a single or a few subnets while an end-site with a /32 may have a host of subnets behind their IPv4 NAT gateway. Making IPv6 topological assumptions for your end-users based on their IPv4 presentation makes little sense to me and is likely a disservice to your end users.
The /56 subnets we give are for single machine in a rack, virtual machine in a cluster or home router. http://www.tunnelbroker.net/ gives by default /64 to a home router and /48 on request we just decided to give /56 by default and /48 on request. Sorry if I wasn't clear in my first message. Is there an agreed upon definition of "end site"? Sincerely, Laurent
On Sun, Jul 15, 2012 at 09:50:39AM +0200, Laurent GUERBY wrote:
Sorry if I wasn't clear in my first message.
Is there an agreed upon definition of "end site"?
Sincerely,
Laurent
this might help. seems like these folks have general agreement on terms. NANOG-critters might have different points of view. http://www.cio.gov/documents/2012_IPv6_Roadmap_FINAL_20120712.pdf /bill
On Jul 15, 2012, at 12:50 AM, Laurent GUERBY wrote:
Hi,
On Sat, 2012-07-14 at 17:02 -0700, Owen DeLong wrote:
Hi,
We use LLA to "virtualize" interconnection to our users: their network configuration is always static default via fe80::nnnn and we route their /56 prefix to fe80::xxxx:yyyy where xxxx:yyyy is unique per user - if our user want to do some routing of course. Since we don't have GUA interconnections we don't have to manage them inside our AS and we can move user stuff around without having them changing anything to their static configuration.
We give a /56 IPv6 per /32 IPv4 to our user which does /48 = /24 = 256 "IP", it's nice to have more than one /64 around for some uses.
Is there any "mass" hoster around that does provide by default a pefix larger than /64 and that does route it to the user? It's quite simple to do in IPv6 and we have the address space for it.
Why not just give each end-site a /48?
We give a /48 on request, a /56 by default (and we never give a /64).
An end-site with a /24 may only need a single or a few subnets while an end-site with a /32 may have a host of subnets behind their IPv4 NAT gateway. Making IPv6 topological assumptions for your end-users based on their IPv4 presentation makes little sense to me and is likely a disservice to your end users.
The /56 subnets we give are for single machine in a rack, virtual machine in a cluster or home router.
http://www.tunnelbroker.net/ gives by default /64 to a home router and /48 on request we just decided to give /56 by default and /48 on request.
Sorry if I wasn't clear in my first message.
Is there an agreed upon definition of "end site"?
Not exactly, but, there is now an ARIN definition for ARIN address policy. An end site (IIRC since I wrote the ARIN definition) is a single building or structure or a single tenant in a multi-tenant building or structure. So, if you have a university campus with 23 buildings, that might be 23 end sites. However, if one of them is a dormitory which has 100 rental units, that would up the end-site count to 122. If one of those buildings houses the math department, the physics department, and the science department, that might bring the total up as high as 124. Make sense? Owen
On 7/13/12 7:38 AM, -Hammer- wrote:
OK. I'm pretty sure I'm gonna get some flak for this but I'll share this question and it's background anyway. Please be gentle.
In the past, with IPv4, we have used reserved or "non-routable" space Internally in production for segments that won't be seen anywhere else. Examples? A sync VLAN for some FWs to share state. An IBGP link between routers that will never be seen or advertised. In those cases, we have often used 192.0.2.0/24. It's reserved and never used and even if it did get used one day we aren't "routing" it internally. It's just on segments where we need some L3 that will never be seen.
On to IPv6
I was considering taking the same approach. Maybe using 0100::/8 or 1000::/4 or A000::/3 as a space for this.
Other than the usual "Hey, you shouldn't do that" can anyone give me some IPv6 specific reasons that I may not be forecasting that would make it worse doing this than in an IPv4 scenario. I know, not apples to apples but for this question they are close enough. Unless there is something IPv6 specific that is influencing this....
Don't, because there's already a /10 defined for such things. It's called ULA (unique local address) aka RFC 4193. ULAs are not globally routable. Here's a calculator that will generate a random one for you: http://bitace.com/ipv6calc/ ~Seth
On 2012-07-18 00:21, Seth Mattinen wrote: [..]
Don't, because there's already a /10 defined for such things. It's called ULA (unique local address) aka RFC 4193. ULAs are not globally routable.
Here's a calculator that will generate a random one for you:
A random one indeed, because the javascript for it is just: 8<----------------------------------------------------- var calc_private = function() { var str = "fd"; for(i = 0; i<10; i++) { str = str + toHex(Math.floor(Math.random()*16)); if (i % 4 == 1) str = str + ":"; } $("#private_subnet").html("Your private subnet is: <code>"+str+":/48</code>"); $("#multicast1").val(str+":/48"); calc_multicast1(); ------------------------------------------------------->8 does not follow RFC4193 in any way at all. A such do not use it. The original real RFC4193 ULA generator script can be found at: http://www.kame.net/~suz/gen-ula.html google(ipv6 ula) for another page, that has been referenced often enough on this very list already, if you want to 'register' it there to avoid another small chance of collision, that page also uses the script from the above site for a true RFC4193 prefix. Greets, Jeroen
On 7/17/12 3:34 PM, Jeroen Massar wrote:
On 2012-07-18 00:21, Seth Mattinen wrote: [..]
Don't, because there's already a /10 defined for such things. It's called ULA (unique local address) aka RFC 4193. ULAs are not globally routable.
Here's a calculator that will generate a random one for you:
A random one indeed, because the javascript for it is just: 8<----------------------------------------------------- var calc_private = function() {
var str = "fd";
for(i = 0; i<10; i++) { str = str + toHex(Math.floor(Math.random()*16)); if (i % 4 == 1) str = str + ":"; }
$("#private_subnet").html("Your private subnet is: <code>"+str+":/48</code>"); $("#multicast1").val(str+":/48"); calc_multicast1(); ------------------------------------------------------->8
does not follow RFC4193 in any way at all. A such do not use it.
The original real RFC4193 ULA generator script can be found at: http://www.kame.net/~suz/gen-ula.html
google(ipv6 ula) for another page, that has been referenced often enough on this very list already, if you want to 'register' it there to avoid another small chance of collision, that page also uses the script from the above site for a true RFC4193 prefix.
Oh well, so much for the googles. Still, don't make up your own squat range for "private" IPv6 space. Use ULA if you really want such a thing. ~Seth
On 2012-07-18 00:47, Seth Mattinen wrote: [..]
Here's a calculator that will generate a random one for you:
A random one indeed, because the javascript for it is just: [..] does not follow RFC4193 in any way at all. A such do not use it.
The original real RFC4193 ULA generator script can be found at: http://www.kame.net/~suz/gen-ula.html
google(ipv6 ula) for another page, that has been referenced often enough on this very list already, if you want to 'register' it there to avoid another small chance of collision, that page also uses the script from the above site for a true RFC4193 prefix.
Oh well, so much for the googles.
Yes, it is a shame that the bitace thing references RFC4193 and then does not use it. Lets Bcc: them and see if they act upon, you never know if they fix things or not, there are good guys still left on these Internets.
Still, don't make up your own squat range for "private" IPv6 space. Use ULA if you really want such a thing.
I am wondering what you meaning with 'squat', note that what I reference above is real full RFC4193 calculated ULA. The optional registration thingy is just optional for those that don't trust probability and want to have a little more security. Also lots of folks like to claim something as their own and well storage bits are cheap for that little amount of info and reassures a lot of folks. Greets, Jeroen
On 2012-07-18 00:57, Jeroen Massar wrote:
On 2012-07-18 00:47, Seth Mattinen wrote: [..]
Here's a calculator that will generate a random one for you:
http://bitace.com/ipv6calc/ [..] Yes, it is a shame that the bitace thing references RFC4193 and then does not use it. Lets Bcc: them and see if they act upon, you never know if they fix things or not, there are good guys still left on these Internets.
So much for gmail never fails: <info@bitace.com>: host aspmx.l.google.com[173.194.70.26] said: 550-5.1.1 The email account that you tried to reach does not exist. Please try 550-5.1.1 double-checking the recipient's email address for typos or 550-5.1.1 unnecessary spaces. Learn more at 550 5.1.1 http://support.google.com/mail/bin/answer.py?answer=6596 p20si34103229wiv.37 (in reply to RCPT TO command) If anybody does have a contact @bitace.com don't hesitate to forward them this discussion. Now also bcc'd to the contact in whois for the domain. Greets, Jeroen
On 7/17/12 3:57 PM, Jeroen Massar wrote:
I am wondering what you meaning with 'squat', note that what I reference above is real full RFC4193 calculated ULA.
By "squat" I meant take a random chunk of IPv6 space and use it as "private" address space. He said: On 7/13/12 7:38 AM, -Hammer- wrote:
I was considering taking the same approach. Maybe using 0100::/8 or 1000::/4 or A000::/3 as a space for this.
And I would say no, use ULA space instead since it's set aside for such things. ~Seth
In message <5005E87D.6060006@unfix.org>, Jeroen Massar writes:
On 2012-07-18 00:21, Seth Mattinen wrote: [..]
Don't, because there's already a /10 defined for such things. It's called ULA (unique local address) aka RFC 4193. ULAs are not globally routable.
Here's a calculator that will generate a random one for you:
A random one indeed, because the javascript for it is just: 8<----------------------------------------------------- var calc_private = function() {
var str = "fd";
for(i = 0; i<10; i++) { str = str + toHex(Math.floor(Math.random()*16)); if (i % 4 == 1) str = str + ":"; }
$("#private_subnet").html("Your private subnet is: <code>"+str+":/48</code>"); $("#multicast1").val(str+":/48"); calc_multicast1(); ------------------------------------------------------->8
does not follow RFC4193 in any way at all. A such do not use it.
If you have a true random number source you don't need to use the method in RFC4193. The method in RFC4193 is designed to get produce a good enough pseudo source of randomness.
The original real RFC4193 ULA generator script can be found at: http://www.kame.net/~suz/gen-ula.html
google(ipv6 ula) for another page, that has been referenced often enough on this very list already, if you want to 'register' it there to avoid another small chance of collision, that page also uses the script from the above site for a true RFC4193 prefix.
Greets, Jeroen
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On (2012-07-18 00:34 +0200), Jeroen Massar wrote:
Here's a calculator that will generate a random one for you:
does not follow RFC4193 in any way at all. A such do not use it.
Another silly oneliner, not RFC4193. ruby -e'p ("fd"+rand(2**40).to_s(16)).scan(/.{1,4}/).join(":")+"::/48"' I'm not sure if RFC4193 is best way to generate random part, it should be possible to incorporate RFC2777 verifiability to it. It would allow operators to prove people who got memorable addresses were not favoured and it would allow the people who generated them to prove they used accepted methods to generate them. However I'm not sure what would be good seed? ISO3166 alpha2 + domestic_business_id + 0..n (for nth block you needed) In practice I'm sure we'll notice bias in random numbers towards 0. As many people who've not been through painful enough M&A renumbers will opt for memorable addresses. -- ++ytti
On Wed, 18 Jul 2012 10:04:05 +0300, Saku Ytti said:
However I'm not sure what would be good seed? ISO3166 alpha2 + domestic_business_id + 0..n (for nth block you needed)
You want to roll in at some entropy by adding in the current date or something, so two "Joes' Burritos and Internet" in 2 different states don't generate the same value. There's a reason that 4193 recommends a 64bit timestamp and an EUI64.
On (2012-07-18 09:10 -0400), valdis.kletnieks@vt.edu wrote:
You want to roll in at some entropy by adding in the current date or something, so two "Joes' Burritos and Internet" in 2 different states don't generate the same value. There's a reason that 4193 recommends a 64bit timestamp and an EUI64.
I assume business ids are federal not state, as IRS is federal? Anyhow I'm not saying 'this is how it should be done', I'm saying maybe there is way to do this in a way which is verifiably random. 64b timestamp and EUI64 make it non-verifiable. I think it would be nice, that people who play by the rules are able to prove they did. Otherwise you can generate it any way you want and claim you did it the right way. -- ++ytti
On 18-Jul-12 08:25, Saku Ytti wrote:
On (2012-07-18 09:10 -0400), valdis.kletnieks@vt.edu wrote:
You want to roll in at some entropy by adding in the current date or something, so two "Joes' Burritos and Internet" in 2 different states don't generate the same value. There's a reason that 4193 recommends a 64bit timestamp and an EUI64. I assume business ids are federal not state, as IRS is federal? Anyhow I'm not saying 'this is how it should be done', I'm saying maybe there is way to do this in a way which is verifiably random.
US EINs/SSNs, and various state-level ID numbers, are not random; given our problems with identity theft, they're not guaranteed to be unique, either. I assume the same is true for identification numbers in most other countries.
64b timestamp and EUI64 make it non-verifiable.
If you publish the numbers you used, then others can verify that those values are reasonable. I doubt anyone would sift through billions of reasonable timestamps combined with the thousands of EUI64s at their site just to find a result that was "memorable". And, if they did, who cares? It's not like it hurts me for them to do so--unless I'm dumb enough to do the same thing, happened to get the same result /and/ happened to merge with them--all of which are still unlikely events. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On (2012-07-18 08:47 -0500), Stephen Sprunk wrote:
And, if they did, who cares? It's not like it hurts me for them to do so--unless I'm dumb enough to do the same thing, happened to get the same result /and/ happened to merge with them--all of which are still unlikely events.
In which case, you could prove you did the right thing. I'm not disagreeing with you that benefits are marginal (I think most 'randomly' choose 0 anyhow). I'm asking, what would the recommend method lose by being verifiable? -- ++ytti
On 07/18/2012 06:10 AM, valdis.kletnieks@vt.edu wrote:
On Wed, 18 Jul 2012 10:04:05 +0300, Saku Ytti said:
However I'm not sure what would be good seed? ISO3166 alpha2 + domestic_business_id + 0..n (for nth block you needed) You want to roll in at some entropy by adding in the current date or something, so two "Joes' Burritos and Internet" in 2 different states don't generate the same value. There's a reason that 4193 recommends a 64bit timestamp and an EUI64.
ulamart.com is available for the enterprising amongst us... Mike
On 18-Jul-12 02:04, Saku Ytti wrote:
On (2012-07-18 00:34 +0200), Jeroen Massar wrote:
Here's a calculator that will generate a random one for you: does not follow RFC4193 in any way at all. A such do not use it. I'm not sure if RFC4193 is best way to generate random part,
It's not claimed to be the "best" way, just one of many possible good ways. If you can demonstrate that your way is at least as good, go for it.
it should bepossible to incorporate RFC2777 verifiability to it.
There is no need for that, since your failure to use a good source of randomness hurts nobody except yourself. If you're too lazy to come up with a good method yourself, as most people are, there are several online RFC 4193-compliant prefix generators that will save you the effort. At least one even includes the ability to record your results and be assured (within the margin of best-effort service) that you will not collide with anyone else who does so. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On (2012-07-18 08:37 -0500), Stephen Sprunk wrote:
it should bepossible to incorporate RFC2777 verifiability to it.
There is no need for that, since your failure to use a good source of randomness hurts nobody except yourself.
I think you're making fact out of opinion. Maybe SP is generating ULAs for their customers. Maybe they'd like to be able to prove in case of dispute that other customer with memorable ULA was not favoured. Maybe someone claims I'm not using BCP methods for ULA selection, and I'd like to be able to falsify those claims. Obviously I could come up with some own RRFC2777 style algo to generate ULA, but if it would be internally documented it would hardly be provable, as I couldn't prove I haven't come up with the algo after generating the prefix. Maybe this is not practical enough concern, but I'm wondering, what is the downside? What is the benefit of recommending method which is not testable/provable. -- ++ytti
Sent from my iPad On Jul 18, 2012, at 8:48 AM, Saku Ytti <saku@ytti.fi> wrote:
On (2012-07-18 08:37 -0500), Stephen Sprunk wrote:
it should bepossible to incorporate RFC2777 verifiability to it.
There is no need for that, since your failure to use a good source of randomness hurts nobody except yourself.
I think you're making fact out of opinion. Maybe SP is generating ULAs for their customers. Maybe they'd like to be able to prove in case of dispute that other customer with memorable ULA was not favoured. Maybe someone claims I'm not using BCP methods for ULA selection, and I'd like to be able to falsify those claims.
SP should never do that. SP should provide GUA. ULA should be local to the customer and not used between customers unless the customers specifically agree to do so. In that case, the customers can handle the coordination and there is no need for the SP to be involved in any dispute. Owen
On 18-Jul-12 08:48, Saku Ytti wrote:
On (2012-07-18 08:37 -0500), Stephen Sprunk wrote:
There is no need for [RFC2777 verifiability], since your failure to use a good source of randomness hurts nobody except yourself.
I think you're making fact out of opinion. Maybe SP is generating ULAs for their customers.
Why would they do that? SPs should only be assigning (and routing) GUAs. ULAs are for /local/ use within the customer site, so customers can and should generate their own locally. An SP should never see those addresses and can safely ignore their existence, aside from a generic filter on the entire ULA range.
Maybe this is not practical enough concern, but I'm wondering, what is the downside? What is the benefit of recommending method which is not testable/provable.
Those were not considered requirements for the algorithm in RFC 4193 since there is no scenario /where RFC 4193 addresses are a valid solution in the first place/ for which testability or provability of the algorithm's results are important or even useful. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On (2012-07-18 11:39 -0500), Stephen Sprunk wrote:
On 18-Jul-12 08:48, Saku Ytti wrote:
Why would they do that? SPs should only be assigning (and routing) GUAs.
Because SP might be tasked to provide network plan for customers L3 MPLS VPN and customer might get INET from different SP and might not want those to be used for L3 MPLS VPN.
ULAs are for /local/ use within the customer site, so customers can and should generate their own locally. An SP should never see those
You make assumption that customer does not buy everything as service. RFC1918 is local, yet often IP plan comes as a service from someone who does it for many companies.
Those were not considered requirements for the algorithm in RFC 4193 since there is no scenario /where RFC 4193 addresses are a valid solution in the first place/ for which testability or provability of the algorithm's results are important or even useful.
If collision occurs, if dispute occurs, provability that one party did not use BCP method can be useful to solve dispute and decide who renumbers. Other potential problem with RFC, if you have software to generate two, if software runs parallel, it may generate same prefixes. IEEE decided 2008 or 2009 to start allocation OUIs randomly, since some cheapskates were assigning themselves 'free' OUIs from end of the space, confident it'll never collide. So duplicate OUIs can happen. Also some NIC vendors ship with non-unique MAC. What makes RFC method good? Would provability make it worse? Would simply drawing 40b of random from known implementation (openssl?) be worse or better? Random as generated by some known/common implementation wouldn't suffer risk of collisions as described above. -- ++ytti
In message <20120718180735.GA11403@pob.ytti.fi>, Saku Ytti writes:
On (2012-07-18 11:39 -0500), Stephen Sprunk wrote:
On 18-Jul-12 08:48, Saku Ytti wrote:
Why would they do that? SPs should only be assigning (and routing) GUAs.
Because SP might be tasked to provide network plan for customers L3 MPLS VPN and customer might get INET from different SP and might not want those to be used for L3 MPLS VPN.
ULAs are for /local/ use within the customer site, so customers can and should generate their own locally. An SP should never see those
You make assumption that customer does not buy everything as service. RFC1918 is local, yet often IP plan comes as a service from someone who does it for many companies.
Those were not considered requirements for the algorithm in RFC 4193 since there is no scenario /where RFC 4193 addresses are a valid solution in the first place/ for which testability or provability of the algorithm's results are important or even useful.
If collision occurs, if dispute occurs, provability that one party did not use BCP method can be useful to solve dispute and decide who renumbers. Other potential problem with RFC, if you have software to generate two, if software runs parallel, it may generate same prefixes. IEEE decided 2008 or 2009 to start allocation OUIs randomly, since some cheapskates were assigning themselves 'free' OUIs from end of the space, confident it'll never collide. So duplicate OUIs can happen. Also some NIC vendors ship with non-unique MAC.
What makes RFC method good? Would provability make it worse? Would simply drawing 40b of random from known implementation (openssl?) be worse or better? Random as generated by some known/common implementation wouldn't suffer risk of collisions as described above.
-- ++ytti
The point of the algorithm was to have something which would do a reasonable job in a CPE router without a hardware source of randomness. CPE devices have access to a EUI-64/EUI-48 and often have ntp support or a way of setting the current time. Combining the two gives enough uniqueness. Just the EUI-64/EUI-48 should be enough but duplicates have been known to occur so adding in a timestamp accounts for that rare case. It is a "SAMPLE" routinue. It is not "YOU MUST DO IT THIS WAY OR ELSE". Anything that meets the requirements of RFC 4086 is fine. /dev/random on by laptop meets the requirements of RFC 4086. I read 40 bits from /dev/random and converted them hex them appended them to fd to produce my prefix. dd bs=5 count=1 if=/dev/random | od -txC | \ awk 'NF == 6 {print "fd" $2 ":" $3 $4 ":" $5 $6}' and a sample of prefixes generated this way: fd3d:6385:e4b3 fdf8:462a:6474 fd7b:2bdf:7ed6 fd75:b2b0:9ba2 fd04:4c74:87c0 fd77:948a:2c39 fde5:41f9:95f6 fd00:74a5:e5ad fd36:827f:ee5f fd39:d806:5994 fd23:d147:8ff9 fd36:a032:8a09 fde8:6992:d8f9 There is no "I used this method so I win". As long as you choose a random value, using a method that uniformly covers the entire space, you meet the requirements. Toss a coin for each bit. Heads = 1, tails = 0. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 7/18/12, Mark Andrews <marka@isc.org> wrote: [snip]
space, you meet the requirements. Toss a coin for each bit. Heads = 1, tails = 0. Sure... and if someone says they just happened to toss a coin 128 times, and got "0" all 128 times, therefore legitimately assigned ULA ID is all zeros, I don't believe them.
(1 / 2)^128 * ([128 : 128]) for α = 0.0000000002 H_0: fair coin Observation: 128 heads out of 128 flips (or 128 tails out of 128 flips) For H_0, Prob given >= 128 heads or >= tails = 2*(1 - Prob(<128) ) = < 0.000000000000000000000000000000000006% Reject H_0. Perhaps the world would be well served if the RFC called for routers to apply some [very lenient] randomness tests to the sequence of bits proposed to be configured as a ULA ID.... :) -- -JH
On Wed, 2012-07-18 at 22:00 -0500, Jimmy Hess wrote:
Sure... and if someone says they just happened to toss a coin 128 times, and got "0" all 128 times, therefore legitimately assigned ULA ID is all zeros, I don't believe them.
Um - 40 times, not 128. The first 8 are set, the last 80 are yours to do with as you please, and the remaining 40 should be random. BUT: The whole idea of ULA is that it is for internal use only. If you want to use 00:0000:0000 as your 40 bits, go for it. Just be aware that you expose yourself to the risk of pain if, somewhere down the track, you need to merge your network with someone else who cleverly chose 00:0000:0000 as well. You can't stop people being making that choice and taking that risk. You can, however, protect *yourself* by choosing something that is genuinely random and thus minimising the chance that, come the day when you have to merge your network with another (including with someone who chose non-randomly), you will be able to do so relatively painlessly. I don't understand the professed need for provable randomness. Without a number *space* to provide context, randomness is inherently non-provable. The whole point of the randomness of those 40 bits of ULA infix is that any number is as likely as any other number. Someone, somewhere, is eventually going to get 10:0000:0000, someone else will eventually get 20:0000:0000 and so on. And they are just as likely to get them now as in ten years time. Because of the likelihood that many people will opt for immediate convenience at the cost of one-day-maybe-never pain, I would suggest that you avoid ULA prefixes that *look* non-random to the naked eye. So if your RNG thows up 00:0000:0001, run it again :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
On 7/18/12, Karl Auer <kauer@biplane.com.au> wrote:
I don't understand the professed need for provable randomness. Without a number *space* to provide context, randomness is inherently non-provable. The whole point of the randomness of those 40 bits of ULA infix is that any number is as likely as any other number. Someone,
When numbers are selected by choosing a random value; certain ratios of bits set to "1" are more likely to occur than other ratios of bits set to "1". A random generator that is operating correctly, is much more likely to emit a number with 50% of the bits set to 1, than it is to emit a number with 0% of the bits set to 1, given a sufficient number of bits. If the ratio is inconsistent by a sufficient margin, and your sample of the bits is large enough in number, you can show with high confidence that the number is not random; a 1 in 10 billion chance of the number being randomly generated, would be pretty convincing, for example. Removing the temptation by excluding the small number of choices with 90% - 95% of the bits set to 1 may eliminate future problems caused by an early "accident"/"error" in assigning the initial ULA, compared to the minor inconvenience of needing to run the ULA generator one more time to get an actual usable range.
somewhere, is eventually going to get 10:0000:0000, someone else will eventually get 20:0000:0000 and so on. And they are just as likely to get them now as in ten years time.
That is extremely improbable. If you generate a million ULA IDs a day, every day, it is expected to be over 1000 years before you generate one of those two. -- -JH
On Wed, 2012-07-18 at 23:40 -0500, Jimmy Hess wrote:
When numbers are selected by choosing a random value; certain ratios of bits set to "1" are more likely to occur than other ratios of bits set to "1".
True. But you cannot tell, from a sample of one number, whether that number was chosen randomly. You can only test it statistically within a series. A particular number may be random in one sequence, non-random in another.
somewhere, is eventually going to get 10:0000:0000 That is extremely improbable.
Yes. It's just exactly as improbable as *any other prefix* thrown up by your favourite RNG.
If you generate a million ULA IDs a day, every day, it is expected to be over 1000 years before you generate one of those two.
The same is true of *every prefix generated*, yet amazingly, people are generating new, unique random prefixes every day, and each and every one of them was just as improbable. Fancy that! It might be that long before you *expect* to see one, but that doesn't mean you will definitely have to wait that long. It could come along tomorrow. That's what "random" means. Let people choose and use whatever ULA prefixes they like. That is the *point* of ULA. If they choose poorly, then they choose poorly - it's no skin off anyone's nose but theirs. If *I* have to choose, I will choose a random prefix, so that in the unlikely event that I have to deal with them, my pain will be minimised. But the best way to win is not to play the game - use PI address space instead of ULA. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
On (2012-07-19 15:16 +1000), Karl Auer wrote:
True. But you cannot tell, from a sample of one number, whether that number was chosen randomly. You can only test it statistically within a series. A particular number may be random in one sequence, non-random in another.
RFC2777 deals with this problem to a degree. If you define algorithm and define how to choose seed, then you can later verify that this particular algorithm was used to generate the number. -- ++ytti
In message <CAAAwwbXh1wS_9aX4FwGrqmSBJmKGJ0nWHRi9EN53HtL36VhSSg@mail.gmail.com> , Jimmy Hess writes:
On 7/18/12, Karl Auer <kauer@biplane.com.au> wrote:
I don't understand the professed need for provable randomness. Without a number *space* to provide context, randomness is inherently non-provable. The whole point of the randomness of those 40 bits of ULA infix is that any number is as likely as any other number. Someone,
When numbers are selected by choosing a random value; certain ratios of bits set to "1" are more likely to occur than other ratios of bits set to "1".
A random generator that is operating correctly, is much more likely to emit a number with 50% of the bits set to 1, than it is to emit a number with 0% of the bits set to 1, given a sufficient number of bits. If the ratio is inconsistent by a sufficient margin, and your sample of the bits is large enough in number, you can show with high confidence that the number is not random; a 1 in 10 billion chance of the number being randomly generated, would be pretty convincing, for example.
Actually you can't. fdaa:aaaa:aaaa has 20/20 0/1 bits but is entirely non random. fdf0:f0f0:f0f0 has 20/20 0/1 bits but is entirely non random. The ratio of the number of bits doesn't tell you anything about whether the number was random or not.
Removing the temptation by excluding the small number of choices with 90% - 95% of the bits set to 1 may eliminate future problems caused by an early "accident"/"error" in assigning the initial ULA, compared to the minor inconvenience of needing to run the ULA generator one more time to get an actual usable range.
somewhere, is eventually going to get 10:0000:0000, someone else will eventually get 20:0000:0000 and so on. And they are just as likely to get them now as in ten years time.
That is extremely improbable. If you generate a million ULA IDs a day, every day, it is expected to be over 1000 years before you generate one of those two.
improbable != impossible
-- -JH
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
If i may summarize this thread as a method to conclude it. 1. Some people like GUA the most. 2. Smart network operators understand the facts and make decisions based on facts (ULA exist, and it meets a need in some scenarios. NAT and lack of addresses are not reasons to use ULA). 3. Most FUD around ULA comes from an over-reaction to ipv4 NAT sins, misunderstandings about how security policy works in the real world , and deficiencies in mathmatical education. CB On Jul 19, 2012 5:48 AM, "Mark Andrews" <marka@isc.org> wrote:
In message < CAAAwwbXh1wS_9aX4FwGrqmSBJmKGJ0nWHRi9EN53HtL36VhSSg@mail.gmail.com> , Jimmy Hess writes:
On 7/18/12, Karl Auer <kauer@biplane.com.au> wrote:
I don't understand the professed need for provable randomness. Without a number *space* to provide context, randomness is inherently non-provable. The whole point of the randomness of those 40 bits of ULA infix is that any number is as likely as any other number. Someone,
When numbers are selected by choosing a random value; certain ratios of bits set to "1" are more likely to occur than other ratios of bits set to "1".
A random generator that is operating correctly, is much more likely to emit a number with 50% of the bits set to 1, than it is to emit a number with 0% of the bits set to 1, given a sufficient number of bits. If the ratio is inconsistent by a sufficient margin, and your sample of the bits is large enough in number, you can show with high confidence that the number is not random; a 1 in 10 billion chance of the number being randomly generated, would be pretty convincing, for example.
Actually you can't.
fdaa:aaaa:aaaa has 20/20 0/1 bits but is entirely non random. fdf0:f0f0:f0f0 has 20/20 0/1 bits but is entirely non random.
The ratio of the number of bits doesn't tell you anything about whether the number was random or not.
Removing the temptation by excluding the small number of choices with 90% - 95% of the bits set to 1 may eliminate future problems caused by an early "accident"/"error" in assigning the initial ULA, compared to the minor inconvenience of needing to run the ULA generator one more time to get an actual usable range.
somewhere, is eventually going to get 10:0000:0000, someone else will eventually get 20:0000:0000 and so on. And they are just as likely to get them now as in ten years time.
That is extremely improbable. If you generate a million ULA IDs a day, every day, it is expected to be over 1000 years before you generate one of those two.
improbable != impossible
-- -JH
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Thu, 19 Jul 2012 07:40:31 -0700, Cameron Byrne said:
3. Most FUD around ULA comes from an over-reaction to ipv4 NAT sins, misunderstandings about how security policy works in the real world , and deficiencies in mathmatical education.
I'll add on that said security policies are *themselves* often based on misunderstandings.
On 19-Jul-12 07:47, Mark Andrews wrote:
In message <CAAAwwbXh1wS_9aX4FwGrqmSBJmKGJ0nWHRi9EN53HtL36VhSSg@mail.gmail.com>, Jimmy Hess writes:
When numbers are selected by choosing a random value; certain ratios of bits set to "1" are more likely to occur than other ratios of bits set to "1".
A random generator that is operating correctly, is much more likely to emit a number with 50% of the bits set to 1, than it is to emit a number with 0% of the bits set to 1, given a sufficient number of bits. If the ratio is inconsistent by a sufficient margin, and your sample of the bits is large enough in number, you can show with high confidence that the number is not random; a 1 in 10 billion chance of the number being randomly generated, would be pretty convincing, for example. Actually you can't.
fdaa:aaaa:aaaa has 20/20 0/1 bits but is entirely non random. fdf0:f0f0:f0f0 has 20/20 0/1 bits but is entirely non random.
The ratio of the number of bits doesn't tell you anything about whether the number was random or not.
He oversimplified the real entropy test, which covers those cases. For a sufficiently long stream of random bits, there should be twice as many runs of length 1 as runs of length 2, twice as many runs of length 2 as runs of length 3, etc. And for each length, they should be evenly divided between runs of 0s and runs of 1s. Of course, 40 bits is nowhere near "sufficiently long", but you can score the entropy and set a lower bound for acceptability. The two examples above would get very low entropy scores, far below any sensible lower bound.
That is extremely improbable. If you generate a million ULA IDs a day, every day, it is expected to be over 1000 years before you generate one of those two. improbable != impossible
All RFC 4193 ever claimed to offer was improbability. If that's not good enough, get a GUA from your RIR. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On 7/19/12, Mark Andrews <marka@isc.org> wrote:
Actually you can't. fdaa:aaaa:aaaa has 20/20 0/1 bits but is entirely non random. fdf0:f0f0:f0f0 has 20/20 0/1 bits but is entirely non random. [snip] The ratio of the number of bits doesn't tell you anything about whether the number was random or not. [snip]
Sure it does. A ratio of 1s to 0s of a sufficient deviation, is a sufficient but not a necessarily condition, for establishing that a sequence of binary numbers shown almost certainly was not chosen randomly. As for whether "fdf0:f0f0:f0f0" is a random number or not, I cannot say, not without a valid test for randomness on the sequence of bits that were chosen, and there are multiple appropriate tests available; use any reasonable test you like, they do exist, and 40 random bits is an amply large sample size. Despite that it is also definitely possible to manually construct strings that are not produced randomly, which nevertheless by design pass any specific test for randomness; intentional 'malice' cannot really be eliminated. However, there _are_ many non-random strings that exist which a 'lazy' or broken ULA ID generator might pick, that can be very easily detected as non-random with sufficient confidence, to tell the user "Hey, sorry, you can't use that. Please generate a new ULA ID".
improbable != impossible
Improbable with a sufficiently small probability is equal to impossible intents and purposes. The probability of generating any specific decimal number you pick a priori, constructed out of 40 bits, is essentially zero, no matter what number you pick; there are _a very large number_ of possible ULA IDs you can exclude, before you have excluded enough that it actually matters.. Rejecting ULA IDs on equipment that have less than a 10^-11 chance of being a random sequence of bits; is less likely to reject a valid ID, than there is to be a collision on a ULA ID, and it would have a high probability of preventing future collisions caused by accident, misconfiguration, etc. Which means that it may be a large improvement on the "honor system" for picking ULA IDs with no verification. "The collision doesn't happen" is a better scenario than "I know who to blame.... the guy before me who just picked zero.. and some former employee in the other company that just picked a ULA ID of zero." -- -JH
On Thu, 2012-07-19 at 19:30 -0500, Jimmy Hess wrote:
The ratio of the number of bits doesn't tell you anything about whether the number was random or not.
Sure it does. A ratio of 1s to 0s of a sufficient deviation, is a sufficient but not a necessarily condition, for establishing that a sequence of binary numbers shown almost certainly was not chosen randomly.
A *sequence*, yes. A single number in isolation, no. Whether the bits within a single value are distributed randomly or not is irrelevant. You seem to be confusing the randomness of a sequence of bits (i.e., within a particular prefix) with the randomness of a sequence of prefixes. You have the entire bit sequence of a particular prefix available to inspect, so you can make a call on the randomness of the bits, but you do NOT have the entire prefix sequence, so CANNOT make a call on the randomness of the prefix. You can say, for a sufficient number of bits, whether the bits are distributed randomly. Agreed. But given a specific bit, without knowing the other bits, you cannot tell whether that specific bit was chosen randomly. If my prefix generating algorithm is to choose 39 bits completely randomly but always set bit 7, you cannot tell that bit 7 has been set non-randomly by inspecting only one prefix, because in a certain number of genuinely random prefixes, bit 7 will be set anyway. Maybe the one you happen to be looking at is such a one. The same is true of any two bits, and any three bits - and so on, all the way out to 40 bits.
However, there _are_ many non-random strings that exist which a 'lazy' or broken ULA ID generator might pick, that can be very easily detected as non-random with sufficient confidence, to tell the user "Hey, sorry, you can't use that. Please generate a new ULA ID".
You can pick them against human criteria; you can't pick them against mathematical criteria unless you have the sequence as well as the value. All zeros is exactly as likely as insert-any-prefix-here. But: IANAS (I Am Not A Statistician :-) so I think I'll stop now. I am either flogging a dead horse or digging an embarrassing hole for myself :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
On 18-Jul-12 22:57, Karl Auer wrote:
I don't understand the professed need for provable randomness.
I think his concern is that if an SP generates a ULA prefix for a customer, and that prefix happens to collide with someone else's ULA prefix, the SP may wish to prove that it was a true collision rather than a result of the SP's laziness or incompetence. However, that concern does /not/ apply to those interested in ULAs in general. For the very limited community it does apply to, use a provable RNG instead of the one in RFC 4193. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
In message <CAAAwwbXn_zfk86YfD9myg6-HcnwSW2pMUQ6yXwpR6B8V4FOVMw@mail.gmail.com> , Jimmy Hess writes:
On 7/18/12, Mark Andrews <marka@isc.org> wrote: [snip]
space, you meet the requirements. Toss a coin for each bit. Heads =3D 1, tails =3D 0. Sure... and if someone says they just happened to toss a coin 128 times, and got "0" all 128 times, therefore legitimately assigned ULA ID is all zeros, I don't believe them.
Given it is 40 bits not 128 bits the chance of getting all zero/all ones is < 0.000000000001%.
(1 / 2)^128 * ([128 : 128])
for =E1 =3D 0.0000000002 H_0: fair coin Observation: 128 heads out of 128 flips (or 128 tails out of 128 flips)
For H_0, Prob given >=3D 128 heads or >=3D tails =3D 2*(1 - Prob(<1= 28) ) =3D < 0.000000000000000000000000000000000006%
Reject H_0.
Perhaps the world would be well served if the RFC called for routers to app= ly some [very lenient] randomness tests to the sequence of bits proposed to be configured as a ULA ID.... :)
Given there is no such possible test I fail to see how you could expect anyone to implement it. You can't examine a single value to determine if it was randomally choosen or not. Even with multiple values you can't determine if there were randomally or systematically choosen as there are a inifinite number of systems that will produce a randomally choosen sequence. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On (2012-07-19 10:25 +1000), Mark Andrews wrote:
The point of the algorithm was to have something which would do a reasonable job in a CPE router without a hardware source of randomness.
In that context it very much makes sense.
It is a "SAMPLE" routinue. It is not "YOU MUST DO IT THIS WAY OR ELSE". Anything that meets the requirements of RFC 4086 is fine. /dev/random on by laptop meets the requirements of RFC 4086. I
Good to know, earlier in this thread, when fully 40b random (method I've been also using, which I've always thought to be superior to RFC) was suggested, it was met with cold shoulder 'does not follow RFC4086 ... do not use'. I guess I'll keep on using my 40b random instead of 'exactly RFC', and keep verifiability in wish-list. -- ++ytti
On 18-Jul-12 13:07, Saku Ytti wrote:
On (2012-07-18 11:39 -0500), Stephen Sprunk wrote:
Those were not considered requirements for the algorithm in RFC 4193 since there is no scenario /where RFC 4193 addresses are a valid solution in the first place/ for which testability or provability of the algorithm's results are important or even useful. If collision occurs, if dispute occurs, provability that one party did not use BCP method can be useful to solve dispute and decide who renumbers.
In my experience, pointing at RFCs is rarely how disputes are resolved in the real world.
Other potential problem with RFC, if you have software to generate two, if software runs parallel, it may generate same prefixes.
It is incredibly unlikely, and that is all RFC 4193 claims to offer: /statistically /unique addresses. If you want /provably/ unique addresses, use GUAs--or lobby for ULA-C, which to date has been soundly rejected for lack of usefulness.
IEEE decided 2008 or 2009 to start allocation OUIs randomly, since some cheapskates were assigning themselves 'free' OUIs from end of the space, confident it'll never collide. So duplicate OUIs can happen. Also some NIC vendors ship with non-unique MAC.
You'd still need two systems with duplicate MACs to run the algorithm at exactly the same timestamp, which IIRC has a resolution of 2^-32 seconds.
What makes RFC method good?
RFC 4193 doesn't mandate any particular algorithm; it just provides an example that was designed to be easily implemented and used. You can use another RNG if you wish. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On Wed, 18 Jul 2012 21:07:35 +0300, Saku Ytti said:
If collision occurs, if dispute occurs, provability that one party did not use BCP method can be useful to solve dispute and decide who renumbers.
Looking at actual numbers out of RFC4193: 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 10000 4.54*10^-05 OK? So even if you merge and re-merge, and go on a massive buying spree and accumulate a network where you have to interoperate 1,000 ULAs, you're *still* looking at a literally million-to-one shot. And if you only have a mess of 100 ULAs, it's a billion-to-one. Now, compare that to the chances that you'll acquire 2 companies, both of whom had an employee who didn't actually generate a proper random number, but did this sort of thing instead: http://www.spinics.net/lists/linux-driver-devel/msg26431.html A lot of people are worrying about the wrong problem.
On (2012-07-19 14:29 -0400), valdis.kletnieks@vt.edu wrote:
OK? So even if you merge and re-merge, and go on a massive buying spree and accumulate a network where you have to interoperate 1,000 ULAs, you're *still* looking at a literally million-to-one shot. And if you only have a mess of 100 ULAs,
My point was, earlier in this thread 40b random method was suggested, which was deemed non RFC compliant. And I've viewed it superior to strictly RFC. But on later post, another author pointed out that 40b random is in conformance to the RFC. To me 40b random is simpler to implement and does not have either of the risks I described (however unlikely, why should I make implementation in given domain more complex and less strong) -- ++ytti
participants (39)
-
-Hammer- -
Adrian Bool -
bmanning＠vacation.karoshi.com -
Brandon Ross -
Brett Frankenberger -
Cameron Byrne -
Doug Barton -
Fred Baker (fred) -
Grzegorz Janoszka -
Jean-Francois.TremblayING＠videotron.com -
Jeroen Massar -
Jimmy Hess -
John Levine -
joseph.snyder＠gmail.com -
Jérôme Nicolle -
Karl Auer -
Laurent GUERBY -
Lee -
Leo Vegoda -
Mark Andrews -
Matt Addison -
Michael Thomas -
Mike Jones -
Oliver -
Owen DeLong -
Rajendra Chayapathi (rchayapa) -
Randy Bush -
Ray Soucy -
Robert E. Seastrom -
Saku Ytti -
Scott Morris -
Seth Mattinen -
Seth Mos -
Skeeve Stevens -
Stephen Sprunk -
TJ -
Tom Cooper -
Tony Hain -
valdis.kletnieks＠vt.edu