What subnet mask you are people using for point to point IPs between two ASes? Specially with IPv6, We have a transit provider who wants us to use /64 which does not make sense for this purpose. isn’t it recommended to use /127 as per RFC 6164 like /30 and /31 are common for IPv4.
I was thinking, if someone is using RFC7404 for point to point IP between two ASes and establish BGP over link local addresses. This way you have your own IP space on your router and transit provider does not have to allocate IP space for point to point interface between two ASes. In traceroutes you would see only loopback IP address with GUA assigned from your allocated routable address space. Remotely DDoS to this link isn’t possible this way. Thoughts?
* KShah@primustel.ca (Krunal Shah) [Tue 27 Jun 2017, 22:28 CEST]:
What subnet mask you are people using for point to point IPs between two ASes? Specially with IPv6, We have a transit provider who wants us to use /64 which does not make sense for this purpose. isn’t it recommended to use /127 as per RFC 6164 like /30 and /31 are common for IPv4.
Whatever you want.
I was thinking, if someone is using RFC7404 for point to point IP between two ASes and establish BGP over link local addresses. This way you have your own IP space on your router and transit provider does not have to allocate IP space for point to point interface between two ASes. In traceroutes you would see only loopback IP address with GUA assigned from your allocated routable address space. Remotely DDoS to this link isn’t possible this way. Thoughts?
If you can protect the loopback IP from DDoS you can equally protect linknet IPs.
What subnet mask you are people using for point to point IPs between two
ASes? Specially with IPv6, We have a transit provider who wants us to use
/64 which does not make sense for this purpose. isn’t it recommended to use
/127 as per RFC 6164 like /30 and /31 are common for IPv4.
Yes, "longer than /64" subnets are fine for point2point. If the equipment
on both sides supports RFC 6164 I'd use a /127, otherwise a /126.
I was thinking, if someone is using RFC7404 for point to point IP between
two ASes and establish BGP over link local addresses. This way you have
your own IP space on your router and transit provider does not have to
allocate IP space for point to point interface between two ASes. In
traceroutes you would see only loopback IP address with GUA assigned from
your allocated routable address space. Remotely DDoS to this link isn’t
possible this way. Thoughts?
I wouldn't use link-local in context of Inter-Domain Routing. Too hard to
troubleshoot, many networks expect globally unique IP addresses for their
BGP neighbors, you want to be able to call a NOC and have the IPs function
as semaphore for the circuit ID.
What you could do is set aside a block which you blackhole or tarpit
through ingress ACLs, and use linknets from that "globally unusable ip
space". Some providers can offer you a router2router linknet from such
unreachable IP space so you don't have to set it apart.
You should be using /126 or /127 for point to point links that touch
external networks unless you like extraneous NS messages and full neighbor
cache tables.
The common recommendations for IPv6 point to point interface numbering are:
/64
/124
/126
/127
/64:
Advantages: conforms to IPv6 standard for a LAN link
Disadvantages: DOS threats against this design. Looping on a true ptp
circuit. Neighbor discovery issues.
/124:
Advantages: supports multiple routers on each end of the circuit. Conforms
to nibble assignment boundary that helps keep address assignments clean and
comprehensible.
Disadvantages: ancient hardware that barely supports IPv6 may have trouble
efficiently handling routes longer than /64.
/126:
Advantages: equivalent to an IPv4 /30 with exactly the same functionality.
Disadvantages: equivalent to an IPv4 /30 with exactly the same
functionality.
/127:
Advantages: saves that extra pair of IP addresses.
Disadvantages: complicates configuration just to save two IPv6 addresses.
Enhancements:
For /124, /126 and /127: allocate all of your addresses for every router in
the system from the same /64. Use router ACLs to control entry of packets
directed to that /64. Nice clean way to stop hackers from poking at your
routers.
What subnet mask you are people using for point to point IPs between two
ASes? Specially with IPv6, We have a transit provider who wants us to use
/64 which does not make sense for this purpose. isn’t it recommended to use
/127 as per RFC 6164 like /30 and /31 are common for IPv4.
You can just ignore that and configure it as a /126 from your end. Does not
matter if they configure their end as a /64 assuming the actual assigned
addresses fit in a /126.
I thought the only allowed subnet prefix lengths for IPv6 were /64 and
/127. RFC 4291 states:
For all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format.
(and addresses starting with 000 are only used for special things,
like the localhost address ::1). And then RFC 6164 adds /127 to
the allowed prefix lengths.
I know that many devices allow you to configure any subnet size,
but is there any RFC allowing you to use e.g. /124 or /126?
AFAICT, the IETF has not caught up with operations practice... and
operations practice itself is still in flux. I do see some discussion of
longer-than-/64 prefixes in RFC 7421.
The difference between theory and practice? In theory, there is no
difference.
IPv6 overall is designed to support CIDR addressing at any netmask. Correct
implementations may not assume that any given interface will host a /64.
Some specific protocols (like SLAAC) intentionally do not work if the
interface ID is not exactly 64 bits. Others become more difficult than
necessary if the prefix is not on a nibble boundary (the /CIDR number is
not evenly divisible by 4).
In the mean time, the options that have come out of OPERATIONS activity for
point to point connections have converged on the above 4.
Once upon a time, William Herrin <bill@herrin.us> said:
112... Could be worse I suppose. They could have picked 113.
A /112 means you can always use ::1 and ::2 for you endpoints. Of
course, you could allocate at /112 boundary and still use a /126 (or
even a /127 and use ::0 and ::1).
Well, /112 is not a stupid option (and is far smarter than /64): it contains the whole last nibble of an IPv6, that is x:x:x:x:x:x:x:1234.
You always put 1 or 2 at the end, and if needed you are still able to address additional stuff would the point-to-point link become a LAN.
And you don't throw away billions of addresses like with /64.
Well, /112 is not a stupid option (and is far smarter than /64): it contains the whole last nibble of an IPv6, that is x:x:x:x:x:x:x:1234.
You always put 1 or 2 at the end, and if needed you are still able to address additional stuff would the point-to-point link become a LAN.
And you don't throw away billions of addresses like with /64.
If you were subnetting down from /64 for the purposes of preventing ndp
exhaustion or to protect the control plane on either yours or your
customers platforms then a /112 is pretty useless because 16 bits is
harmful enough.
The common recommendations for IPv6 point to point interface numbering
are:
/64
/124
/126
/127
I thought the only allowed subnet prefix lengths for IPv6 were /64 and
/127. RFC 4291 states:
For all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format.
(and addresses starting with 000 are only used for special things,
like the localhost address ::1). And then RFC 6164 adds /127 to
the allowed prefix lengths.
I know that many devices allow you to configure any subnet size,
but is there any RFC allowing you to use e.g. /124 or /126?
Hi Thomas,
AFAICT, the IETF has not caught up with operations practice...
there's a certain amount of style drift, I think the rfc series actually
captures quite a bit of it.
and
operations practice itself is still in flux. I do see some discussion of
longer-than-/64 prefixes in RFC 7421.
I'm not so sure about that, While operators have a variety of
preferences some of which I fix quixotic; which were formed as much as 2
decades ago. it's been about 6 years since we had a standards track
consensus describing the rational for numbering point-to-point links out
of /127s (6164). Which is long enough for text books to have been
updated, silicon implemntations of tcams to use exact match instead of
longest match lookups for your connected neighbor on a /127 and so on.
likewise mitigations for ND exhaustion attacks exist even if they are
not universally implemented or perfect so some if not all the motivation
for short prefixes has been ameliorated. one can argue that concern in
rfc3627 (subnet router anycast) is entirely irrelevant for point to
point links (the rfc is now historic for that reason) which was the
major motivation for /126 vs /127 14 years ago.
in other news isps that apparently haven't run out of ipv4 addresses are
still assigning me /30 point-to-point links.
You can always put 1 and 2 at the end on a /124 as well and add additional
devices. These are the same advantages of /124 over /126. And /124 doesn't
suffer from ND exhaustion attacks like /112 might. The only thing /112 buys
you (that I can see) is a single colon in front of the final digit. I don't
see how /112 would be a good choice.
Breaking the law! Some IETFers will come hunt you do, be aware!
Here is some historical perspective looking at the IETF standarsd and
current Internet-Drafts:
RFC 3513 "only /64 is valid"
RFC 3627 "don't use /127, use /126 if you must"
RFC 4291 "reaffirming: only /64 is valid"
RFC 6164 "a /127 is OK to use too"
RFC 6583 "there are problems with /64"
RFC 7421 "/64 is the best!"
RFC 7608 "every prefix length must be forward-able"
RFC 4291bis-07 "fine, /64 and /127 are valid, but nothing else!"
draft-bourbaki-6man-classless-ipv6-00 "IPv6 is classless FFS"
RFC 4291bis-08 "fine, /64 and /127 are valid, and anything defined in future standards, and anything configured manually"
Quoting from 4291bis-08:
"""
Interface Identifiers are 64 bit long except if the first three bits
of the address are 000, or when the addresses are manually
configured, or by exceptions defined in standards track documents.
The rationale for using 64 bit Interface Identifiers can be found in
[RFC7421]. An example of a standards track exception is [RFC6164]
that standardises 127 bit prefixes on inter-router point-to-point
links.
So, what it boils down to: if you want to use SLAAC, you should use a
/64, if you don't need SLAAC, do whatever makes sense for you. And never
be greedy: give your end-users a /48, there is plenty of space to go
around.
Thanks Bill, I thought with ipv6 it was a sin to subnet on bit boundaries
and not on nibble boundaries.
Hi Aaron,
Not a sin but you're making more work for yourself if you subnet on
other-than four-bit nibble boundaries. Each character in the hexadecimal
printed version of the IPv6 address is 4 bits, aka 1 nibble. So subnetting
on a nibble boundary means that each character in the address is either
part of the network portion of the address or part of the host portion of
the address, never both.
Conveniently, IPv6 reverse DNS also delegates on the nibble boundary.
Heck, I’m gonna do whatever it takes to NOT subnet on bits with my v6
deployment. Hopefully with v6, gone are the days of binary subnetting math.
I hedged my bets when I laid out our v6 space at my previous $dayjob. We used /126s for point-to-point links, but carved out a /64 for each point-to-point link in our IPAM system. That way, if we ever encountered a device that wouldn't play nicely with a /126 on a point-to-point link, we could just change the mask to /64 (or something else, if the device requires a byte or nibble boundary) on the interface and any relevant ACLs and not have to re-provision addresses for the link.
I seem to recall that our upstreams generally standardized on /126s for point-to-point interconnects to us. We had one interconnect that was a /64, but that also wasn't a point-to-point link.
> > The common recommendations for IPv6 point to point interface numbering are:
> >
> > /64
> > /124
> > /126
> > /127
>
> I thought the only allowed subnet prefix lengths for IPv6 were /64 and
> /127. RFC 4291 states:
>
> For all unicast addresses, except those that start with the binary
> value 000, Interface IDs are required to be 64 bits long and to be
> constructed in Modified EUI-64 format.
>
> (and addresses starting with 000 are only used for special things,
> like the localhost address ::1). And then RFC 6164 adds /127 to the
> allowed prefix lengths.
>
> I know that many devices allow you to configure any subnet size, but
> is there any RFC allowing you to use e.g. /124 or /126?
Breaking the law! Some IETFers will come hunt you do, be aware!
Here is some historical perspective looking at the IETF standarsd and
current Internet-Drafts:
RFC 3513 "only /64 is valid"
RFC 3627 "don't use /127, use /126 if you must"
RFC 4291 "reaffirming: only /64 is valid"
RFC 6164 "a /127 is OK to use too"
RFC 6583 "there are problems with /64"
RFC 7421 "/64 is the best!"
RFC 7608 "every prefix length must be forward-able"
RFC 4291bis-07 "fine, /64 and /127 are valid, but nothing else!"
draft-bourbaki-6man-classless-ipv6-00 "IPv6 is classless FFS"
RFC 4291bis-08 "fine, /64 and /127 are valid, and anything defined in future standards, and anything configured manually"
Quoting from 4291bis-08:
"""
Interface Identifiers are 64 bit long except if the first three bits
of the address are 000, or when the addresses are manually
configured, or by exceptions defined in standards track documents.
The rationale for using 64 bit Interface Identifiers can be found in
[RFC7421]. An example of a standards track exception is [RFC6164]
that standardises 127 bit prefixes on inter-router point-to-point
links.
So, what it boils down to: if you want to use SLAAC, you should use a
/64, if you don't need SLAAC, do whatever makes sense for you. And never
be greedy: give your end-users a /48, there is plenty of space to go
around.
And that should apply to cell phones as well. A single /64 from a
ISP to a customer is a stop gap assignment. 3GPP supports DHCP-PD
it should be enabled in the back ends.
