[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/

-----Original Message-----
From: Jasper Jans [mailto:Jasper.Jans at espritxb.nl] 
Sent: 26 May 2011 11:23
To: Marco Hogewoning; Gunter Van de Velde (gvandeve)
Cc: Pierre-Yves Maunier; ipv6-wg at ripe.net
Subject: RE: [ipv6-wg] IPv6 on P2P links

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 at 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 at marcoh.net]
Sent: Thursday, May 26, 2011 11:13 AM
To: Gunter Van de Velde
Cc: Pierre-Yves Maunier; Jasper Jans; ipv6-wg at 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