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 /64Also 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, > 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.
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 InternetThe 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
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
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
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.
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
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.
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:
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
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.
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:
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.