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. :) On Tue, Jun 27, 2017 at 4:36 PM, Job Snijders <job@instituut.net> wrote:

On Tue, 27 Jun 2017 at 22:29, Krunal Shah <KShah@primustel.ca> wrote:

...

Hello,

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.

Kind regards,

Job

...

On Wed, Jun 28, 2017 at 8:01 PM, Aaron Gould <aaron1@gvtc.com> wrote:

I think this is funny... I have (4) 10 gig internet connections and here's the maskings for my v6 dual stacking...

/126 - telia /64 - att /112 - cogent /127 - twc/charter/spectrum

112... Could be worse I suppose. They could have picked 113. -Bill -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>

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.

On 29 jun 2017 at 02:32, William Herrin <bill@herrin.us> wrote :

On Wed, Jun 28, 2017 at 8:01 PM, Aaron Gould <aaron1@gvtc.com> wrote:

...

I think this is funny... I have (4) 10 gig internet connections and here's the maskings for my v6 dual stacking...

/126 - telia /64 - att /112 - cogent /127 - twc/charter/spectrum

112... Could be worse I suppose. They could have picked 113.

On Wed, Jun 28, 2017 at 9:10 PM, Olivier Benghozi < olivier.benghozi@wifirst.fr> wrote:

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.

Hi Oliver, 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. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>

On Thu, Jun 29, 2017 at 12:51 AM, Aaron Gould <aaron1@gvtc.com> wrote:

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.

Good plan. -Bill -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>

I wouldn't use link-local in context of Inter-Domain Routing.

indeed randy

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2017-06-28 17:03, William Herrin wrote:

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? /Bellman -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJZVBsFAAoJEGqUdKqa3HTsoDEP/10rXGS7TN/3aEG+IfwyQ3bP +mvNu/uV8Jv8PGfXgjIdD8gr07MqxoGP0pLFB2bEGrQ9dLJVhkLIpksSx6Q6su3y Ym5wDpB/DZnQ1uESN69T4xJtt32Or6L7+/NhehnVfDvoHOd79t9sNuaOu+/z8c2K +OOyc8TwTX+HVhoGfHa4dG7BPh7rUgzZImuGsycpElbt4r75qByZyztPCgjWRTg1 f0/leuFVvIwTA5OY8ZX7WPzdLiOU3f0H6NlKKYZUSsZQCDQfp8DU2S85fj3ZWVB3 vRJKUT2hVF0/q13tK7C16QGpr28hue6xEnscE2GZ3xrjI1yteNZLvbRjQJbco8D0 Z8UHTiUSwdYZgKViVgmxFDS7mrTZCrwwrZMI44mPwub3txgLEEzXmkwMDSvRYVL9 9nAVzCvt3+QKrR1zNQD8ttt0Xg+QENTdTD0NI8iMMkFENXC82cuV1y3UnHYRORdJ r2Uupzps3eQlxa1Uk7SC4sDs17PmBEVpFCtbtEZjCFYdc3PlDmV6wu6/WuXutMox eVDTMgHN3m16ZOXY2U4V5PmW3xvqQ/J+vzE7WyKe5DP5bZPHlddupw4MPPz7+8IG 4O5wOqjAFX8HhNpPMZZjUHxrWvYLEYvGzn8GI06tLKb49+Wq3ux4i2HUUHm/jIf+ GMOQkPABxUntAaPjOzzX =IMMo -----END PGP SIGNATURE-----

On Wed, Jun 28, 2017 at 5:09 PM, Thomas Bellman <bellman@nsc.liu.se> wrote:

...

On 2017-06-28 17:03, William Herrin wrote:

...

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...

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

On 6/28/17 15:44, William Herrin wrote: there's a certain amount of style drift, I think the rfc series actually captures quite a bit of it. 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.

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.

Regards, Bill Herrin

In message <20170629150630.glfvte2ures27p2n@Vurt.local>, Job Snijders writes:

On Wed, Jun 28, 2017 at 11:09:25PM +0200, Thomas Bellman wrote:

...

On 2017-06-28 17:03, William Herrin wrote:

...

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.

Note: In the case of manual configuration, the Prefix and Interface Identifier can be any length as long as they add up to 128. """ source: https://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-08.txt full file: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-08

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.

Kind regards,

Job -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

if you don't need SLAAC, do whatever makes sense for you. And never be greedy: give your end-users a /48

i say give them a /129 just to piss off a certin bigot :)