[ipv6-wg] IPv6 on P2P links

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 at marcoh.net] 
Sent: 26 May 2011 16:34
To: Gunter Van de Velde (gvandeve)
Cc: ipv6-wg at 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