Hi, I am looking for the recommendation for core interfaces IP addressing schema for Ipv6. Some different views are (PE- P - PE, point to point link) as below - 1- Use Public Ipv6 with /122 and do not advertise to Internet 2- Use Public Ipv6 with /127 and do not advertise to Internet 3- Use Unique local ipv6 address 4- Use Public Ipv6 with /64 Also I am interested to understand the impact on TCAM ... Regards, Vikas
I am looking for the recommendation for core interfaces IP addressing schema for Ipv6. Some different views are (PE- P - PE, point to point link) as below -
1- Use Public Ipv6 with /122 and do not advertise to Internet 2- Use Public Ipv6 with /127 and do not advertise to Internet 3- Use Unique local ipv6 address 4- Use Public Ipv6 with /64
Also I am interested to understand the impact on TCAM ...
Regards, Vikas
I would use a /64 with ND turned off and static neighbors configured. TCAM impact will depend on vendor. Some vendors give you the option of storing the first 64 bits of a V6 IP or the entire address. Using a /64 means your CAM usage might be less depending on your vendor. If the addresses on the point-to-point links never accept or source direct traffic to/from outside your net, you can use whatever you want on them. ULA might be ok there. I am using public IPs but I filter traffic destined for them at the edge but to each their own choice. But if you use ULA you aren't going to be able to ping anything outside your net if you source the pings from the ULA interface. Just something to keep in mind. What you are asking is a matter of individual preference.
HI Geroge, Thanks for the input. Appreciate some more info wrt TCAM usuage if possible. Another thought, I agree ip schema is individual preference, but I want to know the best practise (vague term best practice). Personally even I am in favor of /64 p-t-p. Regards, Vikas On Wed, Feb 9, 2011 at 12:11 PM, George Bonser <gbonser@seven.com> wrote:
I am looking for the recommendation for core interfaces IP addressing schema for Ipv6. Some different views are (PE- P - PE, point to point link) as below -
1- Use Public Ipv6 with /122 and do not advertise to Internet 2- Use Public Ipv6 with /127 and do not advertise to Internet 3- Use Unique local ipv6 address 4- Use Public Ipv6 with /64
Also I am interested to understand the impact on TCAM ...
Regards, Vikas
I would use a /64 with ND turned off and static neighbors configured. TCAM impact will depend on vendor. Some vendors give you the option of storing the first 64 bits of a V6 IP or the entire address. Using a /64 means your CAM usage might be less depending on your vendor.
If the addresses on the point-to-point links never accept or source direct traffic to/from outside your net, you can use whatever you want on them. ULA might be ok there. I am using public IPs but I filter traffic destined for them at the edge but to each their own choice. But if you use ULA you aren't going to be able to ping anything outside your net if you source the pings from the ULA interface. Just something to keep in mind.
What you are asking is a matter of individual preference.
On Tue, Feb 8, 2011 at 10:24 PM, Vikas Sharma <vikassharmas@gmail.com> wrote:
Hi, > I am looking for the recommendation for core interfaces IP addressing schema for Ipv6. Some different views are (PE- P - PE, point to point link) as below - 1- Use Public Ipv6 with /122 and do not advertise to Internet 2- Use Public Ipv6 with /127 and do not advertise to Internet
/122 and /127 do not lie on a nibble boundary. Not recommended, try /124 or /120 instead. Especially if you intend to have multiple such PtP networks share the same /64.
3- Use Unique local ipv6 address
I recommend against non-public addressing for V6 point to point links, if these links are used directly for internet connectivity; there can be issues that creates for network diagnostics such as ping/traceroute. Especially in regards to sourcing pings from the PtP interface.
4- Use Public Ipv6 with /64
I would give that a provisional thumbs up: subnetting at the /64 boundary is what is indicated by RFC in regards to IPv6 addressing architecture; it doesn't matter that PtP links only have 2 hosts, the IPv6 addressing architecture calls for a 64-bit interface ID and 64-bit network ID, meaning /64. The provisional condition, is that there are other considerations besides consistent addressing. For now, there are reasons to configure a longer /120 prefix for those interfaces, even while addressing on /64 boundaries. Suggesting: set aside a dedicated /64, within public announced allocation, and pick some /120 inside that /64 for the actual link. /64 subnet, with /120 mask on the link. Recommendation is a combination of (1) and (4). For now, long configured netmasks for such links ensure SLAAC does not operate on them, and may head off some possible DoS risk in regards to sweep attacks / NDP table overflow, which can be of substantial concern for at least some devices. -- -JH
On 9 feb 2011, at 5:24, Vikas Sharma wrote:
I am looking for the recommendation for core interfaces IP addressing schema for Ipv6. Some different views are (PE- P - PE, point to point link) as below -
Is there a NANOG FAQ we can add this to?
1- Use Public Ipv6 with /122 and do not advertise to Internet 2- Use Public Ipv6 with /127 and do not advertise to Internet
The all zeros address is the all routers anycast address so on most non-Cisco routers you can't use it, ruling out /127. The top 128 addresses in any subnet are also reserved anycast addresses although they don't do much in practice. So the longest prefix length you should use is /120 and only use addresses 1 - 127. I recommend /112 because that way the part of the address after the last colon is the subnet.
3- Use Unique local ipv6 address
Not recommended, because now traceroute replies and, if applicable, much worse, PMTUD responses come from bogon space so some people will filter them. So absolutely do not do this if you have any non-1500-byte MTUs in your network.
4- Use Public Ipv6 with /64
/64 has the advantage that you can use EUI-64 addressing so you don't have to remember which exact address each router has, just let that be filled in from the MAC address. The IPv6 addressing architecture RFCs also say you must use /64 but no reason for this is given so I don't feel bound by that. But having a global scope address on your router-to-router interfaces is such IPv4 thinking. You don't need that with IPv6 unless you want to be able to ping individual interfaces. Routing protocols only use the link local addresses and when ICMP messages have to be generated a global scope address is borrowed from another interface, such as the loopback interface.
Is there a NANOG FAQ we can add this to?
1- Use Public Ipv6 with /122 and do not advertise to Internet 2- Use Public Ipv6 with /127 and do not advertise to Internet
The all zeros address is the all routers anycast address so on most non-Cisco routers you can't use it, ruling out /127. The top 128 addresses in any subnet are also reserved anycast addresses although they don't do much in practice. So the longest prefix length you should use is /120 and only use addresses 1 - 127.
A /127 mask is still the best way to handle real point-to-point links like SDH/SONET today, to avoid the ping-pong problem. Works fine with Cisco and Juniper, not tried with other vendors. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On 9 feb 2011, at 10:48, sthaug@nethelp.no wrote:
The all zeros address is the all routers anycast address so on most non-Cisco routers you can't use it, ruling out /127. The top 128 addresses in any subnet are also reserved anycast addresses although they don't do much in practice. So the longest prefix length you should use is /120 and only use addresses 1 - 127.
A /127 mask is still the best way to handle real point-to-point links like SDH/SONET today, to avoid the ping-pong problem. Works fine with Cisco and Juniper, not tried with other vendors.
I know it's immature, but I can't wait for some new hire at vendor C or vendor J to reread the RFCs and implement the all routers anycast address according to spect and then see sparks fly. Like I said, global scope addresses on your router-to-router interfaces is such IPv4 thinking.
A /127 mask is still the best way to handle real point-to-point links like SDH/SONET today, to avoid the ping-pong problem. Works fine with Cisco and Juniper, not tried with other vendors.
I know it's immature, but I can't wait for some new hire at vendor C or vendor J to reread the RFCs and implement the all routers anycast address according to spect and then see sparks fly.
Like I said, global scope addresses on your router-to-router interfaces is such IPv4 thinking.
Global scope addresses on router-to-router interfaces are necessary today for traceroute to work. Some ISPs are *requiring* working traceroute (without MPLS hiding of intermediate hops) in RFPs to transit providers. If you can get router ICMP handling changed such that the ICMP packet generated by traceroute is sent from the loopback address, we might be able to do without global scope addresses on router-to-router interfaces. But until then... Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On Wed, 9 Feb 2011, sthaug@nethelp.no wrote:
A /127 mask is still the best way to handle real point-to-point links like SDH/SONET today, to avoid the ping-pong problem. Works fine with Cisco and Juniper, not tried with other vendors.
I know it's immature, but I can't wait for some new hire at vendor C or vendor J to reread the RFCs and implement the all routers anycast address according to spect and then see sparks fly.
Like I said, global scope addresses on your router-to-router interfaces is such IPv4 thinking.
Global scope addresses on router-to-router interfaces are necessary today for traceroute to work. Some ISPs are *requiring* working traceroute (without MPLS hiding of intermediate hops) in RFPs to transit providers.
If you can get router ICMP handling changed such that the ICMP packet generated by traceroute is sent from the loopback address, we might be able to do without global scope addresses on router-to-router interfaces. But until then...
You can do it on C and J vendor. Without link-local ICMPv6 will use loopback0. Example on C: ipv6 unnumbered loopback0 Best Regards, Janos Mohacsi
Global scope addresses on router-to-router interfaces are necessary today for traceroute to work. Some ISPs are *requiring* working traceroute (without MPLS hiding of intermediate hops) in RFPs to transit providers.
If you can get router ICMP handling changed such that the ICMP packet generated by traceroute is sent from the loopback address, we might be able to do without global scope addresses on router-to-router interfaces. But until then...
You can do it on C and J vendor. Without link-local ICMPv6 will use loopback0. Example on C: ipv6 unnumbered loopback0
I'm afraid I don't consider this an alternative. I *like* global link addresses for our core routers - and so does our NOC. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On 9 feb 2011, at 11:16, sthaug@nethelp.no wrote:
If you can get router ICMP handling changed such that the ICMP packet generated by traceroute is sent from the loopback address, we might be able to do without global scope addresses on router-to-router interfaces. But until then...
I'm pretty sure this is standard behavior for routers, and especially Cisco routers. However, I can't find any documentation for this real quick, either in an RFC or Cisco documentation.
On 9 Feb 2011, at 09:48, sthaug@nethelp.no wrote:
Is there a NANOG FAQ we can add this to?
1- Use Public Ipv6 with /122 and do not advertise to Internet 2- Use Public Ipv6 with /127 and do not advertise to Internet
The all zeros address is the all routers anycast address so on most non-Cisco routers you can't use it, ruling out /127. The top 128 addresses in any subnet are also reserved anycast addresses although they don't do much in practice. So the longest prefix length you should use is /120 and only use addresses 1 - 127.
A /127 mask is still the best way to handle real point-to-point links like SDH/SONET today, to avoid the ping-pong problem. Works fine with Cisco and Juniper, not tried with other vendors.
Can you elaborate on this? What's the ping-pong problem? Sam (who's experience is pretty much mostly ethernet)
A /127 mask is still the best way to handle real point-to-point links like SDH/SONET today, to avoid the ping-pong problem. Works fine with Cisco and Juniper, not tried with other vendors.
Can you elaborate on this? What's the ping-pong problem?
This has been well covered in the past. See http://tools.ietf.org/html/draft-ietf-ipngwg-p2p-pingpong-00 http://tools.ietf.org/html/draft-kohno-ipv6-prefixlen-p2p-01 http://archive.apnic.net/meetings/26/program/apops/matsuzaki-ipv6-p2p.pdf It's a problem for real point-to-point links like SDH/SONET which don't use Neighbor Discovery. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
I think the solution to all of these problems is really to use public addressing but filter access to it at your edge (yes, even ICMP TOOBIG can be filtered safely if you have designed things in a sane way) Dave. -- David Freedman Group Network Engineering Claranet Group
On 9 feb 2011, at 18:30, David Freedman wrote:
(yes, even ICMP TOOBIG can be filtered safely if you have designed things in a sane way)
NO. Even if you run with 1280-byte MTUs everywhere so you'd think path MTU discovery wouldn't be needed, this can still cause problems with IPv6-to-IPv4 translators.
Iljitsch van Beijnum wrote:
On 9 feb 2011, at 18:30, David Freedman wrote:
(yes, even ICMP TOOBIG can be filtered safely if you have designed things in a sane way)
NO.
Even if you run with 1280-byte MTUs everywhere so you'd think path MTU discovery wouldn't be needed, this can still cause problems with IPv6-to-IPv4 translators.
Calm down, I think you misunderstand, I'm suggesting that you don't design your infrastructure in such a way that your backbone/infrastructure links ever have to receive TOOBIG messages from outside your AS and work with these, your backbone links are of course free to send TOOBIG out! Dave. -- David Freedman Group Network Engineering Claranet Group
On Feb 9, 2011, at 9:50 AM, David Freedman wrote:
Iljitsch van Beijnum wrote:
On 9 feb 2011, at 18:30, David Freedman wrote:
(yes, even ICMP TOOBIG can be filtered safely if you have designed things in a sane way)
NO.
Even if you run with 1280-byte MTUs everywhere so you'd think path MTU discovery wouldn't be needed, this can still cause problems with IPv6-to-IPv4 translators.
Calm down, I think you misunderstand,
I'm suggesting that you don't design your infrastructure in such a way that your backbone/infrastructure links ever have to receive TOOBIG messages from outside your AS and work with these, your backbone links are of course free to send TOOBIG out!
Dave.
--
David Freedman Group Network Engineering Claranet Group
Unless every packet you emit is ≤ the minimum MTU (1280), then, you need to be able to receive TOOBIG messages. Owen
Unless every packet you emit is ¾ the minimum MTU (1280), then, you need to be able to receive TOOBIG messages.
Can you think of a packet type I will emit from my publically numbered backbone interface which may solicit a TOOBIG that I'll have to care about? I can only think of three cases, all ICMP: 1. An unreachable of some kind (I don't care if this is delivered or not, and why would I be sending them from the backbone? Even rate-limited? If I send them at all this is the responsibility of the edge) 2. A Time Exceed, again, don't care if this is delivered or not 3. A TOOBIG, if I'm getting a TOOBIG in response to my TOOBIG then we all have bigger problems to worry about :) Dave.
Owen
-- David Freedman Claranet http://www.clara.net
On 10 feb 2011, at 0:26, David Freedman wrote:
Unless every packet you emit is ≤ the minimum MTU (1280), then, you need to be able to receive TOOBIG messages.
Can you think of a packet type I will emit from my publically numbered backbone interface which may solicit a TOOBIG that I'll have to care about?
What if you're trying to connect to your routers with 1500-byte+ POS, ATM, ethernet jumbo or what have you interfaces from some system with a big fat jumboframe MTU but some 100 Mbps ethernet firewall or office network in the middle? If you're willing to accept TCP or UDP from somewhere, it's a bad idea to filter ICMP coming in from that same place.
Iljitsch van Beijnum wrote:
On 10 feb 2011, at 0:26, David Freedman wrote:
Unless every packet you emit is ≤ the minimum MTU (1280), then, you need to be able to receive TOOBIG messages.
Can you think of a packet type I will emit from my publically numbered backbone interface which may solicit a TOOBIG that I'll have to care about?
What if you're trying to connect to your routers with 1500-byte+ POS, ATM, ethernet jumbo or what have you interfaces from some system with a big fat jumboframe MTU but some 100 Mbps ethernet firewall or office network in the middle?
If you're willing to accept TCP or UDP from somewhere, it's a bad idea to filter ICMP coming in from that same place.
I think the point I'm making is, that I'm not, I wont accept any traffic to these backbone interfaces from outside the AS, this means no management sessions from outside the network! (and in the rare, emergency cases where something does need to get in from the outside, policy may dictate acl hole-punching to support it) In the case of people having an unreachable core (i.e MPLS hidden or RFC1918/ULA/LinkLocal), this happens already, if they decide to expose this somehow (MPLS TTL propagation, and/or allowing the ICMP out) then it is only to assist troubleshooting (not that I accept RFC1918/ULA sourced traffic from such networks at my edge , anyway), these people are doing this by design, I think thats the point I'm trying to get across, if you will never need to process TOOBIG in your design, there is no need to accept it. -- David Freedman Group Network Engineering Claranet Group
On Thu, 10 Feb 2011 12:15:52 GMT, David Freedman said:
these people are doing this by design, I think thats the point I'm trying to get across, if you will never need to process TOOBIG in your design, there is no need to accept it.
And how many networks break PMTUD because their design says they never need to deal with ICMP so there's no need to accept it, or break DNS because TCP/53 is only used for zone transfers that should never happen, or...
On Feb 9, 2011, at 9:30 AM, David Freedman wrote:
I think the solution to all of these problems is really to use public addressing but filter access to it at your edge (yes, even ICMP TOOBIG can be filtered safely if you have designed things in a sane way)
Filtering ICMP TOOBIG is actually bad. No matter how sane your design is, you can't count on someone further down the road not having a smaller MTU (unless you're running a 1280 MTU). Owen
participants (10)
-
David Freedman -
George Bonser -
Iljitsch van Beijnum -
Jimmy Hess -
Mohacsi Janos -
Owen DeLong -
Sam Stickland -
sthaug＠nethelp.no -
Valdis.Kletnieks＠vt.edu -
Vikas Sharma