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