When I was doing the config for Interop two weeks ago in Las vegas (I was the lead of the design and implementation there), then we used /127 actually... a weird thing from an engineering perspective is that addressing looks weird actually if one is used for /30's in a v4 world... For example: 2001:db8:C15c:0::/127 has as two addresses on the link: 2001:db8:C15c:0::/127 (this one looks weird to start of with actually) and 2001:db8:C15c:0::1/127 While if it would have been a /126 2001:db8:C15c:0::1/126 and 2001:db8:C15c:0::2/126 Which matches much more the /30 stuff in v4: 192.168.1.1/30 and 192.168.1.2/30 I can tell you many people were very confused about this little change and as result many made mistakes configuring p2p's during the Interop event G/ -----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Marco Hogewoning Sent: 26 May 2011 10:36 To: Pierre-Yves Maunier Cc: Jasper Jans; ipv6-wg@ripe.net Subject: Re: [ipv6-wg] IPv6 on P2P links

on our side we use /126 for P2P links. I've heard some others using /64 or /127. Some allocate a /64 but configure a /126 to always have :1 and :2 in order to avoid mistakes by calculating the good hosts ip addresses.

Curious, why did you pick /126 ? What do you do with ::0 and ::3 ? Marco

Marco, You have pretty much nailed it there. There is a million ways to do it - there is more (or less) reason and rhyme to pick your favorite flavour of the day. And yes we have the whole "let's do what they do" approach. It still leaves me facing several RFCs that says different things, vendors that might or might not support things and an all together bigger mess than I was hoping for. Anything that can be put forward as a clear cut proposal on how to handle these addressing cases would be appreciated from my point of view. It might even be something to whack your vendor over the head with - not much different from the IPv6 feature list that was put together that is now being used in tenders with regards to IPv6 feature parity. Met vriendelijke groet, Jasper Jans Team Leader Network Operations Sr. Network Engineer T: 088 - 00 68 152 F: 088 - 00 68 001 M: 06 - 218 26 380 E: jasper.jans@espritxb.nl EspritXB Monitorweg 1, 1322 BJ Almere Postbus 60043, 1320 AA Almere T: 088 00 68 000 KvK: 1717 7850 F: 088 00 68 001 W: http://www.espritxb.nl http://www.linkedin.com/companies/espritxb http://twitter.com/EspritXB EspritXB levert traditionele spraakdiensten en IP-gebaseerde diensten zoals VoIP, internettoegang, VPN, pinnen, alarm en managed hosting aan MKB Nederland. -----Original Message----- From: Marco Hogewoning [mailto:marcoh@marcoh.net] Sent: Thursday, May 26, 2011 11:13 AM To: Gunter Van de Velde Cc: Pierre-Yves Maunier; Jasper Jans; ipv6-wg@ripe.net Subject: Re: [ipv6-wg] IPv6 on P2P links

2001:db8:C15c:0::/127 has as two addresses on the link: 2001:db8:C15c:0::/127 (this one looks weird to start of with actually) and 2001:db8:C15c:0::1/127

While if it would have been a /126 2001:db8:C15c:0::1/126 and 2001:db8:C15c:0::2/126

Which matches much more the /30 stuff in v4: 192.168.1.1/30 and 192.168.1.2/30

I can tell you many people were very confused about this little change and as result many made mistakes configuring p2p's during the Interop event

Yes it looks confusing, but that is the case anyway and unfortunately the IETF didn't make things easier in this case :( We have rfc 4291stating that interface identifiers for all unicast addresses unless those starting with binary 000 must be 64 bits, that one is standards track. At the same time we have rfc 3627, informational, which states that /127 is considered harmful and finally rfc 6164 which is on standards track again contradicting that by describing the use of /127 for router point-to-point links. So far in the field it seems even more confusing, I've seen various lengths over the years. Mostly you see /126, /127 and also I come across /112 a lot and recently a /124 popped up on this list as well. I have a feeling we are heading for another disaster with this. No I'm not predicting the end of the world, the internet turns out to be resilient enough to survive these kind of things, but there is a serious risk of running into compatibility issues. Where do vendors stand on this ? I know some are really sticking to /64 pointing to rfc 3627. Now with rfc 6164 "overruling", you might be able to convince them to start supporting /127 as well. But what to do with those cases that require different length subnets. These all seem mostly arbitrary decisions made by somebody, which get copied by others based on the "let's not try invent the wheel ourselves". So it still seems reasonable to always assign the /64, no matter what you configure on the box. As anything else might come back and haunt you one day. And, putting on my co-chair hat, is there anything this WG might be able to do in providing some advice to the audience. Maybe issue a BCP on how to handle such cases ? Grtx, Marco Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer

Gunter, I agree with you that just putting something down on paper so that you have something to whack other parties with should not be the intention, apart from the fact that it's hardly constructive as you point out. The problem I see myself facing at the moment though is that as a result of several conflicting documents available and the community as a whole inventing their own wheels we might somewhere down the line run into trouble with compatibility. I personally would like to be able to point at a clear guideline for deployment that has been followed, ideally supported by several RFCs, when ultimately I will end up talking to a third party about the issue. (Third party can be vendor/customer/other sp/etc) Besides that it would ofcourse be even nice if we could all agree on a standard that has been tried and tested before we deploy and avoid issues all together - which as it currently stands is most likely not going to happen - but one can dream I guess. Jasper -----Original Message----- From: Gunter Van de Velde (gvandeve) [mailto:gvandeve@cisco.com] Sent: Thursday, May 26, 2011 11:36 AM To: Jasper Jans; Marco Hogewoning Cc: Pierre-Yves Maunier; ipv6-wg@ripe.net Subject: RE: [ipv6-wg] IPv6 on P2P links Ok, I bite on this one... Jan Zorz and his team are doing a great job with the RIPE501Bis, particular to make it inline with existing recommendations out there. A vendor as Cisco is really happy with this as it unifies a global expectations pattern and will make the world the nice internet place it currently is because of aligned expectations and investments. Which means things will materialize quicker. Next to that, the recommendations now will be more tailored to a more distinct target audience, as not every little feature availability has meaning for every kind of user. (like a SOHO office has no need for ISIS or 50 msec fast convergence or so). So, I think the key is that 'wacking your vendor' randomly is not the right path... it may sound cool to do, but is not the most constructive idea, however asking the right expected IPv6 services is important and crucial for business continuity of the user/enterprise/customer. Responsibility for a good IPv6 infrastructure is the responsibility of Vendors, Service providers, content providers and enterprise organizations as a congruent mutual effort. G/ Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer

On May 26, 2011, at 2:25 PM, Yannis Nikolopoulos wrote:

so,

other than the fact that it's wasteful, is there any other reason for not using /64 (that's what we're using) on p2p links?

I wouldn't describe it as wastwful, every subnet is per standard /64 anyway. The primary reason are security concerns like the fact that you might be able to trick a machine into sending loads of ND messages (or responses), filling up the neighbor cache or CAM table. Marco

On 05/26/2011 06:37 PM, Martin Millnert wrote:

Hi,

On Thu, May 26, 2011 at 8:43 AM, Marco Hogewoning<marcoh@marcoh.net> wrote:

...

On May 26, 2011, at 2:25 PM, Yannis Nikolopoulos wrote:

...

so,

other than the fact that it's wasteful, is there any other reason for not using /64 (that's what we're using) on p2p links? I wouldn't describe it as wastwful, every subnet is per standard /64 anyway. The primary reason are security concerns like the fact that you might be able to trick a machine into sending loads of ND messages (or responses), filling up the neighbor cache or CAM table.

Yes. I recommend http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf for more details on this. It seems to be a pretty serious issue in most implementations. The author of the PDF recommends allocating /64 but using whatever fits your need. This way you'll stay ready for the future, should you have a reason to change, interoperability or other.

Best regards, Martin

i should've been more elaborate in my original post. One one hand, allocating a /64 per p2p link *could* be considered wasteful and Cisco's "official" word was to use /64 on p2p links as all code is optimized for that boundary. On the other hand, there's the NDP cache exhaustion issue mentioned in rfc6164 (this issue can be minimized by a sane security policy btw) plus Gunter's (very informative) comments. Allocating and using /64 on p2p links sounds tidy. The "allocating" part, we'll stick with, the "using" part remains to be seen regards, Yannis

Some work a while ago was to deliver some considerations on address planning at IETF: http://tools.ietf.org/html/rfc5375 As you mention the /64 has for P2P a severe issue due to no ND process the Link resulting in ping-pong problem, and by doing that I have tested I can generate spikes of few Gig on a p2p with a single laptop connection, which is quite unfortunate. Imho this is the biggest driver for the /127 on a p2p connection from technological perspective. I would be willing to contribute together with Surfnet and other interested people to extend the RFC5375 and Surfnets paper to a more formal RIPE piece of work? One of the drivers of creating rfc5375 I had was that there is indeed inconsistency, and as result it should be fixed, but I am not sure RIPE can fix it. RIPE501Bis should imho be focused upon features for 'asking the right IPv6 support'... asking for /127 is silly I think... (btw Cisco IOS device's have no issue with it at all btw... so I am speaking here with my technology hat on). G/ -----Original Message----- From: Marco Hogewoning [mailto:marcoh@marcoh.net] Sent: 26 May 2011 16:34 To: Gunter Van de Velde (gvandeve) Cc: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] IPv6 on P2P links On May 26, 2011, at 11:36 AM, Gunter Van de Velde (gvandeve) wrote:

Ok, I bite on this one...

Jan Zorz and his team are doing a great job with the RIPE501Bis, particular to make it inline with existing recommendations out there. A vendor as Cisco is really happy with this as it unifies a global expectations pattern and will make the world the nice internet place it currently is because of aligned expectations and investments. Which means things will materialize quicker. Next to that, the recommendations now will be more tailored to a more distinct target audience, as not every little feature availability has meaning for every kind of user. (like a SOHO office has no need for ISIS or 50 msec fast convergence or so).

So, I think the key is that 'wacking your vendor' randomly is not the right path... it may sound cool to do, but is not the most constructive idea, however asking the right expected IPv6 services is important and crucial for business continuity of the user/enterprise/customer. Responsibility for a good IPv6 infrastructure is the responsibility of Vendors, Service providers, content providers and enterprise organizations as a congruent mutual effort.

Ok, so there is a document on the RIPE NCC website which describes how to build an addressing plan. It originated in Surfnet, the Dutch NREN, who agreed on having it translated and published by RIPE NCC. It can be found at http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6 _addr_plan4.pdf and on page 18 it addresses the problem: 4.10 Addressing Point-to-point Links If you use point-to-point links, using a /64 address may present problems in combination with certain router configurations. Unused addresses in the /64 system are bounced back by the routers on either side of the link. Data packages sent to this address will thus be sent back and forth between the routers like ping pong balls. This places an unwanted burden on the network. It might therefore, be practical in some cases to configure a /127 prefix instead of a /64 for these links. Please note: this configuration often works, but it is not in accordance with IPv6 standards. We therefore recommend reserving a /64 prefix for such links in the addressing plan, even if you use only a /127. As soon as the router configuration has been corrected by the supplier, you may proceed to configure a /64 prefix without having to modify the addressing plan. So the documentation exists, although not as a RIPE document. I'm a bit stuck here wether we should try and solve this and if so, in which way ? We could look into producing an informational RIPE document on this topic and issue it as BCP from this working group, hoping it provides some guidance and be picked up. On the other hand, the IETF did exactly that with RFC 6164 and even moved it beyond that point by putting it on standards track. So what would we gain by stating the same and putting a green RIPE logo on it ? Or as you mentioned ripe-501 should we include more than just the issue of point-to-point links and take on addressing habits in general ? In which case I have the feeling most of the work is already done by Surfnet in the quoted document and it might be easier to point there. Marco

On 5/26/11 8:19 PM, Ivan Pepelnjak wrote:

Nice to hear Cisco has no problems with /127 (now I don't have to test it and blog about it ;)

As for RIPE501bis - I would add RFC 6164 to the list of "optional" RFCs in the "Router requirements" section. Makes sense?

Ivan

...

RIPE501Bis should imho be focused upon features for 'asking the right IPv6 support'... asking for /127 is silly I think... (btw Cisco IOS device's have no issue with it at all btw... so I am speaking here with my technology hat on).

G/ Hehe, I see you two guys will have a lot to talk about at dinner after v6 summit here in Ljubljana on Thursday :)

ok, there is that draft document requested in RIPE-501, we need to change it to RFC6164 now, when it's published. Thnx for a note :) /jan

Gunter Van de Velde (gvandeve) wrote on 26/05/2011 17:59:

Some work a while ago was to deliver some considerations on address planning at IETF: http://tools.ietf.org/html/rfc5375

As you mention the /64 has for P2P a severe issue due to no ND process the Link resulting in ping-pong problem, and by doing that I have tested I can generate spikes of few Gig on a p2p with a single laptop connection, which is quite unfortunate. Imho this is the biggest driver for the /127 on a p2p connection from technological perspective.

Shouldn't that (the ping-pong problem) be avoided by default, according to (standards track) RFC 4443? If the reason for the failure to deliver cannot be mapped to any of other codes, the Code field is set to 3. Example of such cases are an inability to resolve the IPv6 destination address into a corresponding link address, or a link-specific problem of some sort. One specific case in which a Destination Unreachable message is sent with a code 3 is in response to a packet received by a router from a point-to-point link, destined to an address within a subnet assigned to that same link (other than one of the receiving router's own addresses). In such a case, the packet MUST NOT be forwarded back onto the arrival link. -- Tassos

On Thu, May 26, 2011 at 10:36:27AM +0200, Marco Hogewoning wrote:

...

on our side we use /126 for P2P links. I've heard some others using /64 or /127. Some allocate a /64 but configure a /126 to always have :1 and :2 in order to avoid mistakes by calculating the good hosts ip addresses.

Curious, why did you pick /126 ? What do you do with ::0 and ::3 ?

Marco

I understand that you asked (and in fact we use /31 for IPv4 P2P links). The fact is that when I decided the addressing plan, I was looking for implementation stories from others and based on what I've read, we decided to go on /126. No real reasons. We're always open to look deeper and make changes if necessary. We had to make a decision at this time and we went to /126 over /127 mainly because of RFC3627. Our main goal was to deploy IPv6 and tried to quickly find a good way to subnet our block. Regards, -- Pierre-Yves Maunier AS8218 IP/Project Engineer tel +33 1 49 97 07 45 mob +33 6 30 92 18 36 fax +33 1 49 97 07 30 pymaunier@neotelecoms.com Neotelecoms 21 rue La Boétie, 75008 Paris, France

Hi Gunter, On Thu, May 26, 2011 at 12:56 PM, Gunter Van de Velde (gvandeve) <gvandeve@cisco.com> wrote:

GV> important is that host/user stations are on /64 bit length prefixes, the point-2-point's don't really matter actually in that case as they are just transport path and not a routing destination.

And there's no major technical reason I'm aware of why the NDP must be used on p2p links at all. A router in theory need only figure out what (p2p-) port to send a packet out on, and.. then do it. If there's only one receiver connected, it's going to get the bits. Not sure if vendors have NDP-less p2p-link features yet. Regards, Martin