Re: Question about IPAM tools for v6

On 3 Feb 2014, at 11:58, Tim Chown wrote: > > On 3 Feb 2014, at 11:32, Sam Wilson wrote: > >> >> On 3 Feb 2014, at 11:17, Nick Hilliard wrote: >> >>> On 03/02/2014 11:11, Sam Wilson wrote: Let me de-lurk and make the obvious point that using standard Ethernet addressing would lim

Re: Question about IPAM tools for v6

On 3 Feb 2014, at 11:32, Sam Wilson wrote: > > On 3 Feb 2014, at 11:17, Nick Hilliard wrote: > >> On 03/02/2014 11:11, Sam Wilson wrote: >>> Let me de-lurk and make the obvious point that using standard Ethernet >>> addressing would limit the number of nodes on a single link to 2^47, and >>>

Re: Question about IPAM tools for v6

On 3 Feb 2014, at 11:17, Nick Hilliard wrote: > On 03/02/2014 11:11, Sam Wilson wrote: >> Let me de-lurk and make the obvious point that using standard Ethernet >> addressing would limit the number of nodes on a single link to 2^47, and >> that would require every unicast address assigned to eve

Re: Question about IPAM tools for v6

On 03/02/2014 11:11, Sam Wilson wrote: > Let me de-lurk and make the obvious point that using standard Ethernet > addressing would limit the number of nodes on a single link to 2^47, and > that would require every unicast address assigned to every possible > vendor. Using just the Locally Administ

Re: Question about IPAM tools for v6

On 31 Jan 2014, at 15:26, Alexandru Petrescu wrote: > Speaking of scalability - is there any link layer (e.g. Ethernet) that > supports 2^64 nodes in the same link? Any deployed such link? I doubt so. > > I suppose the largest number of nodes in a single link may reach somewhere in > the tho

Re: Question about IPAM tools for v6

>> /64 netmask opens up nd cache exhaustion as a DoS vector. > > FUD. I probably should have qualified this statement a little better before posting it. Large locally-connected connected l2 domains can open up nd cache exhaustion and many other problems as DoS vectors if the operating systems co

Re: Question about IPAM tools for v6

Le 31/01/2014 18:13, Fernando Gont a écrit : Alex, On 01/31/2014 01:47 PM, Alexandru Petrescu wrote: It's as straightforward as this: whenever you're coding something, enforce limits. And set it to a sane default. And allow the admin to override it when necessary. I tend to agree, but I think

Re: Question about IPAM tools for v6

Messages cités pour référence (si rien alors fin de message) : Le 31/01/2014 16:59, Fernando Gont a écrit : On 01/31/2014 12:26 PM, Alexandru Petrescu wrote: And it's not just the NC. There are implementations that do not limit the number of addresses they configure, that do not limit the number

Re: Question about IPAM tools for v6

Le 31/01/2014 17:35, Fernando Gont a écrit : On 01/31/2014 01:12 PM, Alexandru Petrescu wrote: This is not a problem of implementation, it is a problem of unspoken assumption that the subnet prefix is always 64. Do you know what they say assumptions? -- "It's the mother of all f* ups". It's

Re: Question about IPAM tools for v6

Messages cités pour référence (si rien alors fin de message) : Le 31/01/2014 16:59, Fernando Gont a écrit : On 01/31/2014 12:26 PM, Alexandru Petrescu wrote: And it's not just the NC. There are implementations that do not limit the number of addresses they configure, that do not limit the number

Re: Question about IPAM tools for v6

Messages cités pour référence (si rien alors fin de message) : Le 31/01/2014 16:13, Fernando Gont a écrit : On 01/31/2014 10:59 AM, Aurélien wrote: I personnally verified that this type of attack works with at least one major firewall vendor, provided you know/guess reasonably well the network b

Re: Question about IPAM tools for v6

Messages cités pour référence (si rien alors fin de message) : Le 31/01/2014 14:07, Ole Troan a écrit : Consensus around here is that we support DHCPv6 for non-/64 subnets (particularly in the context of Prefix Delegation), but the immediate next question is "Why would you need that?" /64 netmas

RE: Question about IPAM tools for v6

t; Subject: Re: Question about IPAM tools for v6 > > On 31 January 2014 10:22, Templin, Fred L wrote: > >> Not if you route a /64 to each host (the way 3GPP/LTE does for mobiles). > >> :-) > > > > A /64 for each mobile is what I would expect. It is then up to

RE: Question about IPAM tools for v6

> Not if you route a /64 to each host (the way 3GPP/LTE does for mobiles). :-) A /64 for each mobile is what I would expect. It is then up to the mobile to manage the /64 responsibly by either black-holing the portions of the /64 it is not using or by assigning the /64 to a link other than the se

Re: Question about IPAM tools for v6

On 01/31/2014 02:30 PM, Alexandru Petrescu wrote: > I tend to agree, but I think you talk about a different kind of limit. > This kind of limit to avoid memory overflow, thrashing, is not the > same > as to protect against security attacks. What's the difference between th

Re: Question about IPAM tools for v6

Alex, On 01/31/2014 01:47 PM, Alexandru Petrescu wrote: It's as straightforward as this: whenever you're coding something, enforce limits. And set it to a sane default. And allow the admin to override it when necessary. >>> >>> I tend to agree, but I think you talk about a different

Re: Question about IPAM tools for v6

On 01/31/2014 01:02 PM, Alexandru Petrescu wrote: >>> Speaking of scalability - is there any link layer (e.g. Ethernet) that >>> supports 2^64 nodes in the same link? Any deployed such link? I >>> doubt so. >> Scan Google's IPv6 address space, and you'll find one. (scan6 of >>

Re: Question about IPAM tools for v6

On 01/31/2014 01:12 PM, Alexandru Petrescu wrote: > >>> This is not a problem of implementation, it is a problem of unspoken >>> assumption that the subnet prefix is always 64. >> Do you know what they say assumptions? -- "It's the mother of all f* >> ups". >> >> It's as straightforward as this: w

Re: Question about IPAM tools for v6

On 01/31/2014 12:26 PM, Alexandru Petrescu wrote: >> >> And it's not just the NC. There are implementations that do not limit >> the number of addresses they configure, that do not limit the number of >> entries in the routing table, etc. > > There are some different needs with this limitation. >

Re: Neighbor Cache Exhaustion, was Re: Question about IPAM tools for v6

On 01/31/2014 11:16 AM, Enno Rey wrote: > Hi Guillaume, > > willing to share your lab setup / results? We did some testing > ourselves in a Cisco-only setting and couldn't cause any problems. > [for details see here: > http://www.insinuator.net/2013/03/ipv6-neighbor-cache-exhaustion-attacks-risk-a

Re: Question about IPAM tools for v6

On 01/31/2014 09:33 AM, Mohacsi Janos wrote: > >> On 29/01/2014 22:19, Cricket Liu wrote: >>> Consensus around here is that we support DHCPv6 for non-/64 subnets >>> (particularly in the context of Prefix Delegation), but the immediate >>> next question is "Why would you need that?" >> >> /64 netm

Re: Question about IPAM tools for v6

On 01/31/2014 10:59 AM, Aurélien wrote: > > I personnally verified that this type of attack works with at least one > major firewall vendor, provided you know/guess reasonably well the > network behind it. (I'm not implying that this is a widespread attack type). > > I also found this paper: http

Neighbor Cache Exhaustion, was Re: Question about IPAM tools for v6

Hi Guillaume, willing to share your lab setup / results? We did some testing ourselves in a Cisco-only setting and couldn't cause any problems. [for details see here: http://www.insinuator.net/2013/03/ipv6-neighbor-cache-exhaustion-attacks-risk-assessment-mitigation-strategies-part-1/] After th

Re: Question about IPAM tools for v6

On Fri, Jan 31, 2014 at 2:07 PM, Ole Troan wrote: > >> Consensus around here is that we support DHCPv6 for non-/64 subnets > >> (particularly in the context of Prefix Delegation), but the immediate > >> next question is "Why would you need that?" > > > > /64 netmask opens up nd cache exhaustion a

Re: Question about IPAM tools for v6

>> Consensus around here is that we support DHCPv6 for non-/64 subnets >> (particularly in the context of Prefix Delegation), but the immediate >> next question is "Why would you need that?" > > /64 netmask opens up nd cache exhaustion as a DoS vector. FUD. cheers, Ole signature.asc Descriptio

Re: Question about IPAM tools for v6

On Fri, 31 Jan 2014, Nick Hilliard wrote: On 29/01/2014 22:19, Cricket Liu wrote: Consensus around here is that we support DHCPv6 for non-/64 subnets (particularly in the context of Prefix Delegation), but the immediate next question is "Why would you need that?" /64 netmask opens up nd ca

Re: Question about IPAM tools for v6

On 29/01/2014 22:19, Cricket Liu wrote: > Consensus around here is that we support DHCPv6 for non-/64 subnets > (particularly in the context of Prefix Delegation), but the immediate > next question is "Why would you need that?" /64 netmask opens up nd cache exhaustion as a DoS vector. Nick

Re: Question about IPAM tools for v6

Hi Mark. On Jan 29, 2014, at 11:07 AM, Mark Boolootian wrote: >> Can anyone say whether existing IP Address Management tools that >> support IPv6 have built-in assumptions or dependencies on the >> /64 subnet prefix length, or whether they simply don't care about >> subnet size? > > We use Info

Re: Question about IPAM tools for v6

On 30/01/2014 11:19, Cricket Liu wrote: > Hi Mark. > > On Jan 29, 2014, at 11:07 AM, Mark Boolootian wrote: > >>> Can anyone say whether existing IP Address Management tools that >>> support IPv6 have built-in assumptions or dependencies on the >>> /64 subnet prefix length, or whether they simpl

Re: [ipv6-ops] Re: Question about IPAM tools for v6

As one of the founders of 6connect, we had initially, years ago, only allowed for delegation down to the /64. Client demand dictated support down to the /128 and has been that way for a couple of years. People still implement v6 in very odd ways. A common example I have seen is where someone use

Re: Question about IPAM tools for v6

Hi Brian, On Wed, Jan 29, 2014 at 7:54 PM, Brian E Carpenter < brian.e.carpen...@gmail.com> wrote: > Hi, > > We're working on the next version of > http://tools.ietf.org/html/draft-carpenter-6man-why64 > > Can anyone say whether existing IP Address Management tools that > support IPv6 have built-

Re: Question about IPAM tools for v6

> Can anyone say whether existing IP Address Management tools that > support IPv6 have built-in assumptions or dependencies on the > /64 subnet prefix length, or whether they simply don't care about > subnet size? We use Infoblox's IPAM. There aren't any limitations of which I'm aware in terms of

Question about IPAM tools for v6

Hi, We're working on the next version of http://tools.ietf.org/html/draft-carpenter-6man-why64 Can anyone say whether existing IP Address Management tools that support IPv6 have built-in assumptions or dependencies on the /64 subnet prefix length, or whether they simply don't care about subnet si