Subject: [manet] DLEP-17: Assumptions

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 11:16:29 -0500

I think it is NOT reasonable to assume that all DLEP
implementations will happen to support IPv6.  

Many deployed routers/modems either (a) do not support IPv6 (yet) 
or (b) have IPv6 disabled (e.g. in a network where IPv6 has not 
yet been deployed by the network operator).

Further, there are some existing deployed in-use IP/RF links 
that are both low data-rate and low-MTU.  In those links,
links likely to benefit from DLEP, it is not obvious how one 
can efficiently support IPv6, since IPv6 is specified to have 
a minimum MTU of 1280 bytes (and hence would require the
additional overhead of an adaptation layer).

For some multi-year transition period we also will need
to support UDP/IPv4 link-local multicast for DLEP Discovery.
(See my previous note about getting an IPv4 link-local 
multicast address for this purpose.)

I propose to edit this to either (a) remove the recommendation 
that only IPv6 link-local addresses be used or (b) scope
that recommendation to situations where IPv6 already is in use.

Yours,

Ran

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 24 Nov 2015 11:26:41 -0500

Ran,

Please note that this specification covers *only* the local connection
between a router and it's attached radio - the spec does not intend to
imply that the radio must support IPv6 OTA.

That said, I don't believe there's any hard-and-fast mandate to use IPv6,
just a recommendation that it be used. As Rick mentioned in an earlier
email, the IPv4 broadcast address can be used for discovery, and there is
no restriction that I'm aware of on the P2P session.

Regards,
Stan

On Tue, Nov 24, 2015 at 11:16 AM, RJ Atkinson <[email-masked]> wrote:

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Rick Taylor <[email-masked]>
Date: Tue, 24 Nov 2015 16:28:38 +0000

Ran,

I was working under the assumption (and yes, I know it is an assumption) 
that in 2015 the IETF would mandate IPv6, and not let us get away with 
an either/or approach.

I totally understand the difficulties of IPv6 and legacy equipment, but 
DLEP must mandate 1 method of discovery, and I can't see the IESG 
letting us mandate IPv4.

If, however, someone has an approach that allows IPv4 only, and will get 
through the IETF processes, then I would love to hear it.

Cheers,

Rick

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 13:08:52 -0500

> On 24  Nov 2015, at 11:26 , Stan Ratliff <[email-masked]> wrote:
> 
> Ran, 
> 
> Please note that this specification covers *only* the local connection between a router
> and it's attached radio - the spec does not intend to imply that the radio must support IPv6 OTA. 

I certainly know of radios, deployed in the thousands, that might get
updated to support DLEP but have NO CHANCE of ever getting IPv6 support,
(not even IPv6 Link-local on a wired/optical Ethernet interface).

Hence my concern.

> just a recommendation that it be used. As Rick mentioned in an earlier email,
> the IPv4 broadcast address can be used for discovery, and there is no restriction
> that I'm aware of on the P2P session. 

I sent a separate response to Rick’s reply, but I really think it ought
to avoid using IPv4 link-broadcast.  We have literally decades of negative
operational experience with IPv4 link-broadcast, and IPv4 link-local multicast
works very well (much more favorable operational experience than broadcast).

Thanks,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 13:21:51 -0500

> On 24  Nov 2015, at 11:28 , Rick Taylor <[email-masked]> wrote:
> 
> Ran,
> 

I don’t think that is a valid assumption.

The IETF generally mandates that IPv6 support must be specified,
but generally also still supports IPv4 in IETF specifications.

As a concrete example, OSPFv3 can carry both IPv6 and IPv4 prefixes,
yet IETF OSPF WG is adding “segment routing extensions” to OSPFv2 
(and OSPFv2 ONLY supports IPv4 prefixes and ONLY runs over IPv4).
Separately, there is also OSPF WG draft on how to frame OSPFv3 over IPv4,
primarily as an IPv6-transition aid.

> I totally understand the difficulties of IPv6 and legacy equipment,
> but DLEP must mandate 1 method of discovery, and I can't see the IESG 
> letting us mandate IPv4.

What DLEP **can** do (and SHOULD do) is specify both how DLEP works 
in an IPv6 environment — and also how DLEP works in an IPv4 environment.  

> through the IETF processes, then I would love to hear it.

I am NOT saying that DLEP should be IPv4-only.  I am saying that
there definitely exists legacy IPv4-only equipment that might 
support DLEP in the future, but is extremely unlikely ever to support 
IPv6.

Assertions:
—————
DLEP routers want to be able to communicate with any DLEP modem.
If a radio only supports IPv4, it can’t hear an IPv6 anything.
If a radio only supports IPv6, it can’t hear an IPv4 anything.
If a radio supports both IPv4 & IPv6, it will hear both IPv4 & IPv6.

For example, this means that one tailors the recommendation to
the operational deployment:
	- in a dual-stack operational deployment, the RECOMMENDATION 
          is to send DLEP Discovery messages twice, once with IPv4 
          link-local multicast AND again with IPv6 link-local multicast
	- in an IPv6-only operational deployment, the RECOMMENDATION
          is to send DLEP Discovery messages only using IPv6 link-local 
          multicast.
	- in an IPv4-only operational deployment, the RECOMMENDATION
          is to send DLEP Discovery messages using IPv4 link-local multicast.

Yours,

Ran

---

From: Rick Taylor <[email-masked]>
Date: Wed, 25 Nov 2015 13:27:02 +0000

>            is to send DLEP Discovery messages using IPv4 link-local multicast.

You make a very good point about supporting equipment in IPv4 only 
deployments as a valid target for IETF documents.  In light of that I am 
in favour of updating the discovery text to something along the lines of 
your suggestion.

Rick