Subject: IPv6 over unidirectional links?

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 16 Jul 2009 08:33:35 +0100

Here is an off-list thread that Bernhard introduced on the use of IPv6 
autoconfiguration with unidirectional links. More thoughts would be welcome.

Gorry

 >>> Bernhard Collini-Nocker wrote:
 >>>>
 >>>> Dear Gorry,
 >>>>
 >>>> I´d like to add a point that I have raised a few times in the
 >>>> past years without too much feedback/support: there is in my
 >>>> opinion an issue with unidirectional
 >>>>  links and IPv6 (neighbourhood discovery) addressing of
 >>>> rx-only network adapters.
 >>>>
 >>>> --Bernhard
 >>
 >> Hi Gorry,
 >>
 >> Gorry Fairhurst schrieb:
 >>>
 >>> Here is what I recall: this is to do with IPv6 autoconf when
 >>> you can't do DAD, NUD, etc. Is that right?
 >>>
 >> right, it is all kind of tricky when the link is not per se
 >> bidirectional. The impacts may in many cases be neglectible,
 >> but there may corner cases.
 >>>
 >>> I don't recall what you proposed to do in this case though,
 >>> because on a unidirectional link, I'd expect the sender ND
 >>> cache to be pre-populated with IPv6 addresses (since ND/SEND
 >>> could not be used to query this). So is it right that the remote
 >>> endpoints just rely on RA's to find their own on-net prefix
 >>> and configure their IPv6 addresses without being able to
 >>> validate their uniqueness (is this an issue though?
 >>> - in receive-only applications, the endpoints never send
 >>> with this prefix anyway). Maybe I have misunderstood?
 >>
 >> Well, my concern was/is that in an environment, where
 >> destination IP addresses of rx-only devices are non-unique,
 >> but are used as identifiers this might cause problems.
 >> Also, some mechanisms of IPv6 might fail in what case such an
 >> interface might be unavailable? Actually there are both
 >> operational and conceptual aspects in that problematic.
 >>>
 >>> If we need work in this space, we'd need to decide if this
 >>> were a 6man or ipdvb issue - but there is certainly no harm
 >>> discussing this in ipdvb.
 >>
 >> I guess so.
 >>
 >> --Bernhard
 >>