/127 for point to point links
Hello. We've stumbled across a problem with a router manufacturer, which won't implement support for /127 prefix lengths. Now, we do have peering/transit partners using /127 on their p2p links. The result is that we either cannot peer with them, or will have to get new routers. RFC 3627 states that /127 is considered harmful, however I do feel this RFC confuse people since it doesn't propose a definite solution. It suggests a number of solutions and indicates using /64 is the right thing. I must say I strongly disagree on that conclusion. Wasting so much address space on point to point links just makes no sense to me. So I'm not sure what to do here. I have to convince someone; either our partners or the router manufacturer. I have the impression that /127 is used widely out there. -- Vegard Svanberg <vegard@svanberg.no> [*Takapa@IRC (EFnet)]
On Fri, 12 Feb 2010, Vegard Svanberg wrote:
Hello. We've stumbled across a problem with a router manufacturer, which won't implement support for /127 prefix lengths. Now, we do have peering/transit partners using /127 on their p2p links. The result is that we either cannot peer with them, or will have to get new routers.
RFC 3627 states that /127 is considered harmful, however I do feel this RFC confuse people since it doesn't propose a definite solution. It suggests a number of solutions and indicates using /64 is the right thing. I must say I strongly disagree on that conclusion. Wasting so much address space on point to point links just makes no sense to me.
The argument about wasting address space is not useful. However, there are other arguments for using /127, especially if you're using e.g. SDH technology (the interface is "point-to-point" media). http://tools.ietf.org/html/draft-kohno-ipv6-prefixlen-p2p-00 describes these to some degree. (The draft is being revised.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Vegard,
Hello. We've stumbled across a problem with a router manufacturer, which won't implement support for /127 prefix lengths. Now, we do have peering/transit partners using /127 on their p2p links. The result is that we either cannot peer with them, or will have to get new routers.
RFC 3627 states that /127 is considered harmful, however I do feel this RFC confuse people since it doesn't propose a definite solution. It suggests a number of solutions and indicates using /64 is the right thing. I must say I strongly disagree on that conclusion. Wasting so much address space on point to point links just makes no sense to me.
So I'm not sure what to do here. I have to convince someone; either our partners or the router manufacturer. I have the impression that /127 is used widely out there.
let's be clear that you are not wasting address space by using a /64 on a point to point link. IPv6 address space is as close to an infinite resource when it comes to the number of /64s. a point to point link uses 2 addresses out of 2^64 a random multi-access link doesn't use a significantly larger proportion in any case. the argument for using /127 is for example that there is no confusion what the address on the other end is. or that you will have no problem with looping to unassigned addresses within the prefix. if you have an implementation which doesn't support /127 you can just use a /128 on each end. cheers, Ole
On Fri, 12 Feb 2010, Vegard Svanberg wrote:
Hello. We've stumbled across a problem with a router manufacturer, which won't implement support for /127 prefix lengths. Now, we do have peering/transit partners using /127 on their p2p links. The result is that we either cannot peer with them, or will have to get new routers.
RFC 3627 states that /127 is considered harmful, however I do feel this RFC confuse people since it doesn't propose a definite solution. It suggests a number of solutions and indicates using /64 is the right thing. I must say I strongly disagree on that conclusion. Wasting so much address space on point to point links just makes no sense to me.
So I'm not sure what to do here. I have to convince someone; either our partners or the router manufacturer. I have the impression that /127 is used widely out there.
RFC 3627 is informational RFC. Does not describe any strict rules. Read the RFC and understand /127 is harmful only in certain cases: poin-to-point link + usage of subnet anycast. Other problems might exist as described in section 5. Also Have a look at: http://www.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
RFC 3627 is informational RFC. Does not describe any strict rules. Read the RFC and understand /127 is harmful only in certain cases: poin-to-point link + usage of subnet anycast. Other problems might exist as described in section 5.
Chaos is harmful. Following consistent best practice on peering links is a good idea.
http://www.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt
Yes, perhaps saying that /64 on all peering links is a bit too simplistic. Nevertheless, I do believe that everyone should follow best practice on peering links. This WG seems like a good place to agree on the specifics of what that best practice is since RFC 3627 is a bit too general for this. What do others think of drafting an IPv6 best practices document in this WG that is specifically for network operators? --Michael Dillon
On Friday 12 February 2010 06:21:39 pm michael.dillon@bt.com wrote:
What do others think of drafting an IPv6 best practices document in this WG that is specifically for network operators?
BCP documents (as in Best Current or Common Practices) I believe should be a target outcome of any RIPE WG. The more focused on people actually running IP networks and services the better for me. In short, I agree. Regards, Kostas Zorbadelos
What do others think of drafting an IPv6 best practices document in this WG that is specifically for network operators?
Looking forward to a first draft of this. Is it worth joining up with the routing WG who is, I believe, busy with something on filtering recommendations and deaggregation ? MarcoH
On 13 Feb 2010, at 13:14, Marco Hogewoning wrote:
What do others think of drafting an IPv6 best practices document in this WG that is specifically for network operators?
Looking forward to a first draft of this. Is it worth joining up with the routing WG who is, I believe, busy with something on filtering recommendations and deaggregation ?
True, ever since AP-wg agreed that routing considerations, such as (de)aggregation, would be better reflected in a routing document than in an address policy one. Work has been headed by Rob Evans and Sander steffann with help. see http://www.ripe.net/ripe/wg/routing/r59-minutes.html, the minutes for RIPE 59. Look at the last item in the minutes Joao
João Damas a écrit :
On 13 Feb 2010, at 13:14, Marco Hogewoning wrote:
What do others think of drafting an IPv6 best practices document in this WG that is specifically for network operators?
some: - address plan: RFC3531 - special IPv6 prefixes (the ones who usually need to be filtered): RFC5156 Marc.
Looking forward to a first draft of this. Is it worth joining up with the routing WG who is, I believe, busy with something on filtering recommendations and deaggregation ?
True, ever since AP-wg agreed that routing considerations, such as (de)aggregation, would be better reflected in a routing document than in an address policy one. Work has been headed by Rob Evans and Sander steffann with help. see http://www.ripe.net/ripe/wg/routing/r59-minutes.html, the minutes for RIPE 59. Look at the last item in the minutes
Joao
-- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca
True, ever since AP-wg agreed that routing considerations, such as (de)aggregation, would be better reflected in a routing document than in an address policy one. Work has been headed by Rob Evans and Sander steffann with help. see http://www.ripe.net/ripe/wg/routing/r59-minutes.html, the minutes for RIPE 59. Look at the last item in the minutes
Sorry for the slow reply. An update to the IPv6 route filtering recommendations document has been on my todo list since Lisbon (and I've been chased about it a few times by some people), but I've had little chance to devote much time to it. I do aim to get it done well before Prague. However, I've been quite fond of keeping the document short and focused, so whilst I'd be happy for an IPv6 BCP to reference it, I'd need to be persuaded to add much more to it. Cheers, Rob
What do others think of drafting an IPv6 best practices document in this WG that is specifically for network operators?
Looking forward to a first draft of this. Is it worth joining up with the routing WG who is, I believe, busy with something on filtering recommendations and deaggregation ?
Why not start with some of the material on ARIN's IPv6 wiki? For instance the following page <http://www.getipv6.info/index.php/IPv6_Addressing_Plans> could serve as the start of a best practices document on IPv6 addressing plans. --Michael Dillon
On Mon, 15 Feb 2010, michael.dillon@bt.com wrote:
What do others think of drafting an IPv6 best practices document in this WG that is specifically for network operators?
Looking forward to a first draft of this. Is it worth joining up with the routing WG who is, I believe, busy with something on filtering recommendations and deaggregation ?
Why not start with some of the material on ARIN's IPv6 wiki? For instance the following page <http://www.getipv6.info/index.php/IPv6_Addressing_Plans> could serve as the start of a best practices document on IPv6 addressing plans.
Also you can look at 2 tutorials: http://www.6deploy.org/tutorials/031-IPv6_addr_case_RENATER_Hungarnet_v0_1.p... http://www.6deploy.org/tutorials/131_Campus_IPv6_deployment_consideration_v0... Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
--Michael Dillon
On 02/12/2010 10:10, Vegard Svanberg wrote:
Hello. We've stumbled across a problem with a router manufacturer, which won't implement support for /127 prefix lengths. Now, we do have peering/transit partners using /127 on their p2p links. The result is that we either cannot peer with them, or will have to get new routers.
RFC 3627 states that /127 is considered harmful, however I do feel this RFC confuse people since it doesn't propose a definite solution. It suggests a number of solutions and indicates using /64 is the right thing. I must say I strongly disagree on that conclusion. Wasting so much address space on point to point links just makes no sense to me.
So I'm not sure what to do here. I have to convince someone; either our partners or the router manufacturer. I have the impression that /127 is used widely out there.
Well, personaly as being the first commecial ipv6 provider in our country I had the same reservations. But after a talk with our IPv6 experts (go6.si) I/we just accepted the fact that we're wasting perfectly good address space and we just put /64 on P2P links... Still, if it becomes an obvious overkill I'm quite sure that by that time the HW manufacturers will have things sorted out. And that the "powers to be" will define the standards. Ragnar Belial Us
On Fri, 2010-02-12 at 11:23 +0000, Us wrote:
Well, personaly as being the first commecial ipv6 provider in our country I had the same reservations. But after a talk with our IPv6 experts (go6.si) I/we just accepted the fact that we're wasting perfectly good address space and we just put /64 on P2P links...
Even though others have said that the argument of wasting space isn't useful and that the number of 64s is near infinite, I wanted to show just how :) If you've heard it before, stop reading this mail now. We're using an 1/8th of the IPv6 space this first attempt to do it, or 2001::/3. There are maybe 5 more usable eights in case we screw this up. If some ~9 billion people on this planet *each* used say 16x /64 links, the total usage for this would only amount to a /27, or a 1/2^24th of the 2001::/3 space. A whopping 6 micro-percents, or 0.000006%. 64:s are built to be unique per broadcast domain. In the technologies I am aware of today (which arguably are few), none creates a "broadcast domain scaling problem" by for example connecting each user to every other user on always unique broadcast domains -- THIS would not scale! So the "address space waste" argument for todays network models is void, but there might very well, as Pekka exemplifies, be other technical/engineering constraints that come in to play. Regards, -- Martin Millnert <millnert@csbnet.se>
Well, personaly as being the first commecial ipv6 provider in our country I had the same reservations. But after a talk with our IPv6 experts (go6.si) I/we just accepted the fact that we're wasting perfectly good address space and we just put /64 on P2P links...
What would you prefer to waste? Money or address space? If you use a /64 for every point-to-point circuit then you are wasting address space, instead of wasting money paying for someone to put twice as many bits of silicon into the circuitry that handles routing and forwarding. Anybody who thinks that doing the "right thing", as advised by the IETF, is wasteful, needs to get their priorities straight. We have enough problems getting transitioned to IPv6 and we don't need providers who think that they are smarter than the rest of us and will just reinvent the wheel and force /127 prefixes on their peering partners. Remember this statement? RFC 3627 states that /127 is considered harmful, however I do feel this RFC confuse people since it doesn't propose a definite solution. It suggests a number of solutions and indicates using /64 is the right thing. Using /64 is the right thing. That means that on peering links with another provider, best practice is to follow the RFCs and use /64. If you want to experiment with other prefixes in your network, then go ahead, but on interfaces with others, follow best practices. By the way, that also means giving no less than a /56 to a private residence and no less than a /48 to any site. It's not your job to tell other people how to run their network. --Michael Dillon
Generally here we're using /112's for P2P links.... ...Skeeve -- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve@eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there?
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Vegard Svanberg Sent: Friday, 12 February 2010 9:10 PM To: ipv6-wg@ripe.net Subject: [ipv6-wg] /127 for point to point links
Hello. We've stumbled across a problem with a router manufacturer, which won't implement support for /127 prefix lengths. Now, we do have peering/transit partners using /127 on their p2p links. The result is that we either cannot peer with them, or will have to get new routers.
RFC 3627 states that /127 is considered harmful, however I do feel this RFC confuse people since it doesn't propose a definite solution. It suggests a number of solutions and indicates using /64 is the right thing. I must say I strongly disagree on that conclusion. Wasting so much address space on point to point links just makes no sense to me.
So I'm not sure what to do here. I have to convince someone; either our partners or the router manufacturer. I have the impression that /127 is used widely out there.
-- Vegard Svanberg <vegard@svanberg.no> [*Takapa@IRC (EFnet)]
Generally here we're using /112's for P2P links....
And RFC 4291 says: 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. (Section 2.5.1, 3rd para) That's not RFC 2119 language and other parts of the RFC describe variable length prefixes. I don't think I like it, but it's what the Draft Standard says. Sam Sam Wilson Network Team, IT Infrastructure Information Services, The University of Edinburgh Edinburgh, Scotland, UK -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
participants (14)
-
João Damas -
Kostas Zorbadelos -
Marc Blanchet -
Marco Hogewoning -
Martin Millnert -
michael.dillon＠bt.com -
Mohacsi Janos -
Ole Troan -
Pekka Savola -
Rob Evans -
Sam.Wilson＠ed.ac.uk -
Skeeve Stevens -
Us -
Vegard Svanberg