Re: IPv6 RA vs DHCPv6 - The chosen one?
On 12/23/11 12:52, Masataka Ohta wrote: Michael Sinatra wrote: The only time you need to perform extra steps is when you want to run DHCPv6. You need to enable the M and/or O flags and turn off the 'autonomous' flag (if you don't want a host to get both SLAAC addresses and DHCPv6 addresses. That's a configuration of RA, not DHCPv6. So? If DHCPv6 had default route capability you wouldn't need RA at all. The point is, you have to do more work to run DHCPv6 than SLAAC. Then you need to turn on relaying unless you are putting the DHCPv6 server on the same wire. As I wrote: Just as most, if not all, NAT boxes have preconfigured DHCPv4 service to offer part of preconfigured private address space, home IPv6 routers may have preconfigured DHCPv6 service to offer part of configured public address space. local DHCPv6 server should be running locally by default. If you're talking about a little CPE router, maybe. If you're talking about an enterprise core router, then no. Ideally, nothing should be on by default, and services you wish to run should be configured explicitly. (Currently not the case with SLAAC, which is on by default when you configure IPv6 on some routers.)
Re: IPv6 RA vs DHCPv6 - The chosen one?
On 12/23/11 13:00, Masataka Ohta wrote: Tomas Podermanski wrote: It sounds good, but according to RFC 6434 ( IPv6 Node Requirements) SLAAC is required, Not at all. SLAAC is required only if ND is supported, which is optional. Note that ND works poorly over link layers such as 802.11 where multicast is unreliable. but DHCPv6 is only optional. DHCPv6 works over link layers with unreliable multicast better than ND. You still need ND to provide the link-layer address resolution (i.e. the IPv6 equivalent of ARP), even with DHCPv6. Moreover, how do you come to the conclusion that DHCPv6, which uses multicast for the solicitation, is more reliable over links where multicast is unreliable? FYI, I have been using SLAAC over 802.11 for many years, and have supported large 802.11 installations with SLAAC and have never had a problem related to unreliable multicast on that medium. Other problems, yes. But not that one. michael
Re: IPv6 RA vs DHCPv6 - The chosen one?
Michael Sinatra wrote: That's a configuration of RA, not DHCPv6. So? If DHCPv6 had default route capability you wouldn't need RA at all. According to the end to end principle that hosts do everything, default router is a bad idea and you should better snoop IGP, which is the only solution for multihomed cases. local DHCPv6 server should be running locally by default. If you're talking about a little CPE router, maybe. If you're talking about an enterprise core router, then no. The context of the thread is: Glen Kent wrote: While in some environments, typically with small number of devices, its indispensable. Small businesses may not want the complexity of setting up a central server (for DHCP) - SLAAC works very well in such environments. Masataka Ohta
Re: IPv6 RA vs DHCPv6 - The chosen one?
Michael Sinatra wrote: DHCPv6 works over link layers with unreliable multicast better than ND. You still need ND to provide the link-layer address resolution (i.e. the IPv6 equivalent of ARP), even with DHCPv6. Not necessarily. You can use ARP and DHCPv6 and you don't have to waste time and power for DAD. Moreover, how do you come to the conclusion that DHCPv6, which uses multicast for the solicitation, is more reliable over links where multicast is unreliable? DHCPv6 (and ARP) uses a lot less multicast/broadcast than ND. FYI, I have been using SLAAC over 802.11 for many years, and have supported large 802.11 installations with SLAAC and have never had a problem related to unreliable multicast on that medium. Other problems, yes. But not that one. That's because your 802.11 is not congested. Masataka Ohta
Re: subnet prefix length 64 breaks IPv6?
Ok. So does SLAAC break with masks 64? Glen On Sat, Dec 24, 2011 at 12:38 PM, sth...@nethelp.no wrote: I am not sure if this is the reason as this only applies to the link local IP address. One could still assign a global IPv6 address. So, why does basic IPv6 (ND process, etc) break if i use a netmask of say /120? As long as you assign addresses statically, IPv6 works just fine with a netmask 64. We've been using this for several years now. No problem. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: subnet prefix length 64 breaks IPv6?
On Sat, 2011-12-24 at 15:37 +0530, Glen Kent wrote: Ok. So does SLAAC break with masks 64? Break is not the right word. SLAAC only works with /64, But that is by design. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 signature.asc Description: This is a digitally signed message part
Re: IPv6 RA vs DHCPv6 - The chosen one?
On Sat, 2011-12-24 at 17:58 +0900, Masataka Ohta wrote: Not necessarily. You can use ARP and DHCPv6 and you don't have to waste time and power for DAD. IPv6 does not do ARP, it does ND. Even if you use DHCv6, you still need ND. DAD is still performed on addresses assigned via DHCPv6. DHCPv6 (and ARP) uses a lot less multicast/broadcast than ND. ARP uses no multicast at all. However, ARP is an IPv4 protocol, not an IPv6 protocol. DHCPv6 uses multicast a lot - *every* client message is multicast. Relay messages to servers are multicast by default (though it seems most actual deployments configure the relays to use unicast). Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 signature.asc Description: This is a digitally signed message part
Re: subnet prefix length 64 breaks IPv6?
Le 24/12/2011 11:58, Karl Auer a écrit : On Sat, 2011-12-24 at 15:37 +0530, Glen Kent wrote: Ok. So does SLAAC break with masks 64? Break is not the right word. SLAAC only works with /64, But that is by design. SLAAC only works with /64 - yes - but only if it runs on Ethernet-like Interface ID's of 64bit length (RFC2464). SLAAC could work ok with /65 on non-Ethernet media, like a point-to-point link whose Interface ID's length be negotiated during the setup phase. Other non-64 Interface IDs could be constructed for 802.15.4 links, for example a 16bit MAC address could be converted into a 32bit Interface ID. SLAAC would thus use a /96 prefix in the RA and a 32bit IID. IP-over-USB misses an Interface ID altogether, so one is free to define its length. Alex Regards, K.
Re: subnet prefix length 64 breaks IPv6?
SLAAC only works with /64 - yes - but only if it runs on Ethernet-like Interface ID's of 64bit length (RFC2464). Ok, the last 64 bits of the 128 bit address identifies an Interface ID which is uniquely derived from the 48bit MAC address (which exists only in ethernet). SLAAC could work ok with /65 on non-Ethernet media, like a point-to-point link whose Interface ID's length be negotiated during the setup phase. If we can do this for a p2p link, then why cant the same be done for an ethernet link? Glen Other non-64 Interface IDs could be constructed for 802.15.4 links, for example a 16bit MAC address could be converted into a 32bit Interface ID. SLAAC would thus use a /96 prefix in the RA and a 32bit IID. IP-over-USB misses an Interface ID altogether, so one is free to define its length. Alex Regards, K.
Re: subnet prefix length 64 breaks IPv6?
it only breaks the auto configure crap which you don't want to use anyway. (unless you want to have any computer on your network be able to tell any other computer oh hai i'm a router, please route all your packets through me so i can intercept them and/or flood its route table ;) we use all kinds of things from /126'es to /112 (but hardly any /64 crap) works perfectly fine. as long as its nibble aligned (for other reasons ;) -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. Co. KG = Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration:HRA 42834 B BERLINPhone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE:CBSK1-RIPEe-Mail: s...@cb3rob.net = penpen C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob = Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Sat, 24 Dec 2011, Glen Kent wrote: Hi, I am trying to understand why standards say that using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], .. [reference RFC 5375] Or A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes. Is it because the 128 bits are divided into two 64 bit halves, where the latter identifies an Interface ID which is uniquely derived from the 48bit MAC address. I am not sure if this is the reason as this only applies to the link local IP address. One could still assign a global IPv6 address. So, why does basic IPv6 (ND process, etc) break if i use a netmask of say /120? I know that several operators use /120 as a /64 can be quite risky in terms of ND attacks. So, how does that work? I tried googling but couldnt find any references that explain how IPv6 breaks with using a netmask other than 64. Glen
Re: subnet prefix length 64 breaks IPv6?
On Sat, Dec 24, 2011 at 6:48 AM, Glen Kent glen.k...@gmail.com wrote: SLAAC only works with /64 - yes - but only if it runs on Ethernet-like Interface ID's of 64bit length (RFC2464). Ok, the last 64 bits of the 128 bit address identifies an Interface ID which is uniquely derived from the 48bit MAC address (which exists only in ethernet). SLAAC could work ok with /65 on non-Ethernet media, like a point-to-point link whose Interface ID's length be negotiated during the setup phase. If we can do this for a p2p link, then why cant the same be done for an ethernet link? I think by point-to-point, Alexandru was referring to PPP-signalled links. In the case of Ethernet and SLAAC, the standards define a way to turn a globally unique 48-bit 802.3 MAC-48 address into an EUI-64 identifier by flipping and adding some bits. This uniquely maps conventional MAC-48 addresses into EUI-64 addresses. I imagine this was chosen because the IEEE is encouraging new standards and numbering schemes to use the 64-bit schemes over the older 48-bit ones. Presumably to avoid exhaustion in the future (like we're seeing with IPv4). The result of which is that with the standards we've got today, we can easily map a piece of hardware's globally unique MAC address into a globally unique 64-bit identifier -- which happens to cleanly fit into the second half of the v6 address space. I suppose one could make an argument to use /80 networks and just use the MAC-48 identifier for the address portion, but given the vastness of v6 space I don't think it's really worth the extra savings of bit space. So, to address your original question, in v6 networks with netmask lengths greater than 64 bits nothing breaks per se, but some of the conventional standards and ideas about what a network is in that context are broken. While it's not possible to have hosts uniquely pick addresses for themselves, one can use other addressing mechanisms like DHCPv6 or static addresses. --j
Re: subnet prefix length 64 breaks IPv6?
things that -do- break on ipv6 a lot (not nessesarily related to the /64 thing) are premature protocols like ospf6 and ripng that for some magic reason refuse to work on point-to-point (as opposed to putting the interface in broadcast mode, like ethernet) interfaces without (additional) link-local addresses, despite the option to clearly specify the interface and/or address of the peer and/or address ranges they should work on (these do not nessesarily have to be /64, but they do need to be scope link local and start with a multicast prefix). also various bgp implementations will send the autoconfigure crap ip as the next-hop instead of the session ip, resulting in all kinds of crap in your route table (if not fixed with nasty hacks on your end ;) which doesn't exactly make it easy to figure out which one belongs to which peer all the more reason not to use that autoconfigure crap ;) on the whole, ipv6 simply still needs a -lot- of work. for those that do want autoconfigure (workstations?) , a proper dhcp implementation would be preferred over keeping that RA stuff around in future implementations of the v6 stack, as far as we're concerned, it can go the way of the dinosaur (already ;) On Sat, 24 Dec 2011, Sven Olaf Kamphuis wrote: it only breaks the auto configure crap which you don't want to use anyway. (unless you want to have any computer on your network be able to tell any other computer oh hai i'm a router, please route all your packets through me so i can intercept them and/or flood its route table ;) we use all kinds of things from /126'es to /112 (but hardly any /64 crap) works perfectly fine. as long as its nibble aligned (for other reasons ;) -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. Co. KG = Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration:HRA 42834 B BERLINPhone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE:CBSK1-RIPEe-Mail: s...@cb3rob.net = penpen C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob = Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Sat, 24 Dec 2011, Glen Kent wrote: Hi, I am trying to understand why standards say that using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], .. [reference RFC 5375] Or A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes. Is it because the 128 bits are divided into two 64 bit halves, where the latter identifies an Interface ID which is uniquely derived from the 48bit MAC address. I am not sure if this is the reason as this only applies to the link local IP address. One could still assign a global IPv6 address. So, why does basic IPv6 (ND process, etc) break if i use a netmask of say /120? I know that several operators use /120 as a /64 can be quite risky in terms of ND attacks. So, how does that work? I tried googling but couldnt find any references that explain how IPv6 breaks with using a netmask other than 64. Glen
Re: subnet prefix length 64 breaks IPv6?
Your understanding of IPv6 is poor if you think by not using a 64-bit prefix you will be protected against rogue RA. The prefix length you define on your router will have no impact on a rogue RA sent out. IPv6 hosts can have addresses from multiple prefixes on the same link. Choosing to make use of a 120-bit prefix (for example) will do nothing to protect against a rogue RA announcing its own 64-bit prefix with the A flag set. You can use a 64-bit prefix and not use SLAAC as well. SLAAC is used only when the A flag is set. It just so happens that the majority of router implementations have it set by default. You still need to filter RA from unauthorized hosts. Currently, many switches can accomplish this using a PACL on access ports. In the near future, we will begin to see the RA Guard feature become standard on enterprise switches. Mind you, you should be filtering out rogue RA regardless if whether or not you have deployed IPv6. Windows ICS sending RA is a widespread problem (honestly wish Microsoft would remove ICS from the default install). There are some things that will break by not using a 64-bit prefix. SLAAC can't function without it. Privacy Extensions for SLAAC can't either (obviously). If you make use of a longer prefix, then you need to use either manual configuration or DHCPv6 for address assignment. All standards-compliant implementations of IPv6 will work with prefixes longer than 64-bit. In production, we make use of 126-bit prefixes for link networks, and common use of 120 (and similar) prefixes for host networks and they work perfectly. That said, the only reason we don't make use of 64-bit prefixes for host networks is in an effort (which may be futile) to mitigate neighbor table exhaustion attacks. We still reserve a full 64-bit prefix, allowing us to expand the prefix in the future without disrupting service. The long term plan is to migrate to 64-bit prefixes when routing equipment is better able to handle neighbor table exhaustion attacks. As for the comments on the use of multicast; multicast is a good thing. On most devices is is no different than broadcast, but it adds the information needed for more advanced hardware (e.g. managed switches with MLD snooping) to only replicate the traffic to interested parties. The elimination of broadcast traffic in IPv6 is a good thing, and doesn't introduce any problem. The (related) other comment made was using ARP with IPv6 instead of ND. This also shows a poor understanding of how IPv6 works. ARP is for IPv4, ND is for IPv6. There is no ARP for IPv6. ND has the advantage that it actually happens over IPv6, rather than a lower level or parallel protocol. This makes filtering such traffic and designing hardware that is aware of it significantly easier. It will be nice to reach a point where non-IPv6 traffic can be filtered and dropped completely. Other than making use of the link-local scope and using a multicast group instead of broadcast, ND is pretty much the same thing as ARP. On Sat, Dec 24, 2011 at 10:30 AM, Sven Olaf Kamphuis s...@cb3rob.net wrote: it only breaks the auto configure crap which you don't want to use anyway. (unless you want to have any computer on your network be able to tell any other computer oh hai i'm a router, please route all your packets through me so i can intercept them and/or flood its route table ;) we use all kinds of things from /126'es to /112 (but hardly any /64 crap) works perfectly fine. as long as its nibble aligned (for other reasons ;) -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. Co. KG = Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: s...@cb3rob.net = penpen C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob = Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Sat, 24 Dec 2011, Glen Kent wrote: Hi, I am trying to understand why standards say that using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], .. [reference RFC 5375] Or A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes. Is it
Merry Chrismafestihanukwanzstice
Merry Chrismafestihanukwanzstice to everyone reading NANOG on this holiday weekend. And now, for some On Topic technical content, I bring you RFC 1882 (it's an RFC, by definition it must have some relevant content for network operators :-): http://www.ietf.org/rfc/rfc1882.txt Network Working Group B. Hancock Request for Comments: 1882 Network-1 Software and Technology, Inc. Category: InformationalDecember 1995 The 12-Days of Technology Before Christmas Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Discussion On the first day of Christmas, technology gave to me: A database with a broken b-tree (what the hell is a b-tree anyway?) On the second day of Christmas, technology gave to me: Two transceiver failures (CRC errors? Collisions? What is going on?) And a database with a broken b-tree (Rebuild WHAT? It's a 10GB database!) On the third day of Christmas, technology gave to me: Three French users (who, of course, think they know everything) Two transceiver failures (which are now spewing packets all over the net) And a database with a broken b-tree (Backup? What backup?) On the fourth day of Christmas, technology gave to me: Four calls for support (playing the same Christmas song over and over) Three French users (Why do they like to argue so much over trivial things?) Two transceiver failures (How the hell do I know which ones they are?) And a database with a broken b-tree (Pointer error? What's a pointer error?) Hancock Informational [Page 1] RFC 1882 12-Days of Technology Before ChristmasDecember 1995 On the fifth day of Christmas, technology gave to me: Five golden SCSI contacts (Of course they're better than silver!) Four support calls (Ever notice how time stands still when on hold? Three French users (No, we don't have footpedals on PC's. Why do you ask?) Two transceiver failures (If I knew which ones were bad, I would know which ones to fix!) And a database with a broken b-tree (Not till next week? Are you nuts?!?!) On the sixth day of Christmas, technology gave to me: Six games a-playing (On the production network, of course!) Five golden SCSI contacts (What do you mean not terminated!) Four support calls (No, don't transfer me again - do you HEAR? Damn!) Three French users (No, you cannot scan in by putting the page to the screen...) Two transceiver failures (I can't look at the LEDs - they're in the ceiling!) And a database with a broken b-tree (Norway? That's where this was written?) On the seventh day of Christmas, technology gave to me: Seven license failures (Expired? When?) Six games a-playing (Please stop tying up the PBX to talk to each other!) Five golden SCSI contacts (What do you mean I need wide SCSI?) Four support calls (At least the Muzak is different this time...) Three French Users (Well, monsieur, there really isn't an any key, but...) Two transceiver failures (SQE? What is that? If I knew I would set it myself!) And a database with a broken b-tree (No, I really need to talk to Lars - NOW!) Hancock Informational [Page 2] RFC 1882 12-Days of Technology Before ChristmasDecember 1995 On the eighth day of Christmas, technology gave to me: Eight MODEMs dialing (Who bought these? They're a security violation!) Seven license failures (How many WEEKS to get a license?) Six games a-playing (What do you mean one pixel per packet on updates?!?) Five golden SCSI contacts (Fast SCSI? It's supposed to be fast, isn't it?) Four support calls (I already told them that! Don't transfer me back - DAMN!) Three French users (No, CTL-ALT-DEL is not the proper way to end a program) Two transceiver failures (What do you mean babbling transceiver?) And a database with a broken b-tree (Does anyone speak English in Oslo?) On the ninth day of Christmas, technology gave to me: Nine lady executives with attitude (She said do WHAT with the servers?) Eight MODEMs dialing (You've been downloading WHAT?)
Re: IPv6 RA vs DHCPv6 - The chosen one?
Karl Auer wrote: Not necessarily. You can use ARP and DHCPv6 and you don't have to waste time and power for DAD. IPv6 does not do ARP, it does ND. First of all, ND use is optional and, if ND is used, RA must be used. It means that, if RA is not used, ND can't be used. Then, the only reasonable protocol for address resolution is ARP. Even if you use DHCv6, you still need ND. DAD is still performed on addresses assigned via DHCPv6. That is a requirement by SLAAC because SLAAC has distributed states, which can be inconsistent. If RA is not used, there is no such requirement. Masataka Ohta
Re: IPv6 RA vs DHCPv6 - The chosen one?
On 12/24/11 15:33 , Masataka Ohta wrote: Karl Auer wrote: Not necessarily. You can use ARP and DHCPv6 and you don't have to waste time and power for DAD. IPv6 does not do ARP, it does ND. First of all, ND use is optional and, if ND is used, RA must be used. It means that, if RA is not used, ND can't be used. Finding and maintaining the l2 address for a device on a subnet where RA is not used is a pretty common activity so I'm not sure how your would conclude that. 2461/4861/5942 certainly don't preclude that. Then, the only reasonable protocol for address resolution is ARP. Even if you use DHCv6, you still need ND. DAD is still performed on addresses assigned via DHCPv6. That is a requirement by SLAAC because SLAAC has distributed states, which can be inconsistent. If RA is not used, there is no such requirement. Masataka Ohta
Re: IPv6 RA vs DHCPv6 - The chosen one?
Joel jaeggli wrote: First of all, ND use is optional and, if ND is used, RA must be used. It means that, if RA is not used, ND can't be used. Finding and maintaining the l2 address for a device on a subnet where RA is not used is a pretty common activity so I'm not sure how your would conclude that. 2461/4861/5942 certainly don't preclude that. RFC6434 has contradictory statements: Neighbor Discovery SHOULD be supported. and Hosts MUST support IPv6 Stateless Address Autoconfiguration as defined in [RFC4862]. and a reasonable interpretation is SLAAC MUST be supported if ND is supported. Or, we shouldn't expect IPv6 specifications reasonable, which means reasonable operation is impossible. Masataka Ohta
