Subject: [Anima] ipv4-only network

From: Liyizhou <[email-masked]>
Date: Thu, 5 Aug 2021 08:00:46 +0000

Hi,

RFC8994 explained the main reasons that ACP is based on IPv6 addressing are simplicity and scale.
I wonder if there was/is any interest in defining and deploying ACP in IPv4-only network without requiring IPv6 enablement.
For example, as ULA and link-local address schemes are not available in ipv4 networks, whether and how to establish the ACP channel? (RFC3927 defines IPv4 link-local address config, but it is not a full functional substitute of ipv6 link-local address in ipv4 world in my understanding.)

There might be discussions and thoughts in this aspect in earlier days in the community. I would be very appreciated if anyone can point them out.

Thank you,
Yizhou

---

From: Brian Carpenter <[email-masked]>
Date: Thu, 5 Aug 2021 22:08:29 +1200

We don't require any IPv6 enablement by the NOC. All we require is standard
dual stack on all autonomic devices, which creates link-local addresses.
Everything else in the ACP is automatic. Why waste any effort on an IPv4
version? (The operator can do whatever they want in the data plane, of
course.)

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Thu, 5 Aug 2021, 20:01 Liyizhou, <[email-masked]> wrote:

> I wonder if there was/is any interest in defining and deploying ACP in
> IPv4-only network without requiring IPv6 enablement.
>
> For example, as ULA and link-local address schemes are not available in
> ipv4 networks, whether and how to establish the ACP channel? (RFC3927
> defines IPv4 link-local address config, but it is not a full functional
> substitute of ipv6 link-local address in ipv4 world in my understanding.)
>
>
>
> There might be discussions and thoughts in this aspect in earlier days in
> the community. I would be very appreciated if anyone can point them out.
>
>
>
> Thank you,
>
> Yizhou
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: "Michael H. Behringer" <[email-masked]>
Date: Thu, 5 Aug 2021 13:29:06 +0200

To add to that, we had a short but
quite intensive debate about whether we need an IPv4 ACP, a few
years back, after this document was proposed:

https://datatracker.ietf.org/doc/html/draft-du-anima-ipv4-acp

We came to the conclusion that it makes no sense to propose an
IPv4 ACP; the ACP is an entirely new concept, so there was the
opinion that there is no need for backwards compatibility with
IPv4.

Michael

On 05/08/2021 12:08, Brian Carpenter wrote:

We don't require any IPv6 enablement by the NOC.
All we require is standard dual stack on all autonomic devices,
which creates link-local addresses. Everything else in the ACP
is automatic. Why waste any effort on an IPv4 version? (The
operator can do whatever they want in the data plane, of
course.)

Regards,

Brian Carpenter

On Thu, 5 Aug 2021, 20:01
Liyizhou, <[email-masked]> wrote:

Hi,

RFC8994 explained
the main reasons that ACP is based on IPv6 addressing
are simplicity and scale.

I wonder if there
was/is any interest in defining and deploying ACP in
IPv4-only network without requiring IPv6 enablement.

For example, as
ULA and link-local address schemes are not available
in ipv4 networks, whether and how to establish the ACP
channel? (RFC3927 defines IPv4 link-local address
config, but it is not a full functional substitute of
ipv6 link-local address in ipv4 world in my
understanding.)

There might be
discussions and thoughts in this aspect in earlier
days in the community. I would be very appreciated if
anyone can point them out.

Thank you,

Yizhou

Anima mailing list

[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Aug 2021 12:51:41 -0400

Liyizhou <[email-masked]> wrote:
    > ipv4 networks,

This is a false statement.
IPv6 Link-Local addresses are always available without network support.
Our use of ULA occurs in the overlay layer, and is never seen.

So RFC8994 is completely deployable in IPv4-only networks.
If your control plan OS has no IPv6, then I agree there is a problem.
If it were 1999, I might believe that.

    > There might be discussions and thoughts in this aspect in earlier days
    > in the community. I would be very appreciated if anyone can point them
    > out.

Conceivably, you might have an L2 network which is opaque to etherype 0x86DD
then there might be an issue.  Is that really the case?
In which case we could discuss running over IPv4-Link-Local.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 6 Aug 2021 00:25:49 +0200

I would not say "standard dual stack" because i think the requirements
can be even less IPv6 than what i consider to be standard dual stack
with our existing ANIMA RFCs:

A) The networks data-plane can be almost (*) solely IPv4 if that is the 
(enterprise, industrial,...) network stack desired in a network.
The operator of such a network does not have to know or configure any IPv6.

(*) The only IPv6 artefact is the IPv6 link-local encap of ACP secure
channel, but that is also fully automatic and nothing the operator
would need to ever care about. And it could be optimized away through
simple follow on draft (ethernet L2 encap "optimization" for secure channel).

B) Wrt the NOC: in pre-standard ACP implementations, for IPv4-only-network
customers, I did set up ACP-connect edge router + NAT to connect to
IPv4 only management systems / NOC. When such a NAT is included as a
feature into an ACP-edge router config it can be quite simple and elegant
(e.g.: almost fully automatic, no per-ACP-node NAT config).

Let me know when you have an ACP edge-router implementation and i'll
be happy to whip up a IPv4/IPv6 NAT draft for it if that is what is
missing to sell the ACP solution to IPv4 only customers ;-))

Cheers
    Toerless
    (via gigantic screen)

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 6 Aug 2021 15:11:42 +1200

I was writing loosely; it's something like RFC8200+RFC4861+RFC4862, which every o/s of significance has supported for >10 years.

Regards
   Brian