Re: [babel] [Babel-users] IPv4 over IPv6

Toke Høiland-Jørgensen <toke@toke.dk> Tue, 31 March 2020 19:25 UTC

Return-Path: <toke@toke.dk>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149C63A29FE for <babel@ietfa.amsl.com>; Tue, 31 Mar 2020 12:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUBNvK0qq68d for <babel@ietfa.amsl.com>; Tue, 31 Mar 2020 12:25:00 -0700 (PDT)
Received: from mail.toke.dk (mail.toke.dk [IPv6:2a0c:4d80:42:2001::664]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB36D3A29E8 for <babel@ietf.org>; Tue, 31 Mar 2020 12:24:58 -0700 (PDT)
From: Toke Høiland-Jørgensen <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1585682693; bh=UAmSyY8l4E2aQIANWaT+HK/Z5/T/zMXJGZNZii6laCQ=; h=From:To:Subject:In-Reply-To:References:Date:From; b=FS84OMgZpzMFsduJ7NtSWqYN1vCU4AhQd9Ghp/HLcept2bNno6xh4gSzH+7Innen6 aAsNKHJCt0f5rm7uNumdjAPFSA/+zpp9IoaD7wTqaq7vlCgOltQSCE9Gqq9CULTHS6 VpPkNlYM3OunZvKC9xX7F842FeARULYpd0K6YWDYh+eE19H9FFrvWtlZKfi+lRbLry TMeOVr7W8/8KmPPXre4NzEn754MdhF0AdMlbJR/IoUAWosIR2P17TmTAWtveVlMb3L v3Xv9rEmdlPduVOdWYwdu6iLE6qpgcr/2c4ZCG69dbJWL9GDFCSFJRPLjFLFcVbfiC 6x+zXbOiDLKrg==
To: Juliusz Chroboczek <jch@irif.fr>, babel@ietf.org, babel-users@lists.alioth.debian.org
In-Reply-To: <87o8scpgkq.wl-jch@irif.fr>
References: <87o8scpgkq.wl-jch@irif.fr>
Date: Tue, 31 Mar 2020 21:24:50 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <877dz0iayl.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/vmkxrrYmyImW95FoS8yuf4utzQY>
Subject: Re: [babel] [Babel-users] IPv4 over IPv6
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2020 19:25:07 -0000

Juliusz Chroboczek <jch@irif.fr> writes:

> Dear all,
>
> Some of you might remember that Théo Bastian (in copy of this mail) is
> working on implementing a Babel extension for IPv4 routing with IPv6 next
> hops.  Since the extension is meant to interoperate with other Babel
> routers, we've decided to encode IPv4-over-IPv6 routes as a new AE.  So an
> IPv4-over-IPv6 route announcement consists of:
>
>   1. a normal Router-ID TLV ;
>   2. an IPv4-over-IPv6 Next Hop TLV carrying an IPv6 next-hop ;
>   3. an IPv4-over-IPv6 Update TLV carrying an IPv4 prefix.
>
> The Update is encoded in the new AE, which updates a separate set of
> compression state; the normal IPv4 compression state is left undisturbed.
> On the other hand, we have two natural ways of encoding the NH :
>
>   (1) use a new NH, in the new AE ;
>   (2) reuse the IPv6 NH (AEs 1 and 2).
>
> Encoding (1) has the advantage of being easier to explain.  Encoding (2)
> has a number of advantages:
>
>    (i) if a packet carries both IPv4 and IPv6 routes, the next-hop is only
>        encoded once;
>   
>   (ii) we can use both AEs 1 and 2, which means that we can use the more
>        compact encoding for link-local next-hops ;
>
>  (iii) the code is slightly simpler.
>
> Initially, Théo preferred encoding (2), while I was in favour of (1).
> Théo rewrote all of his code in style (1), and after looking at his code,
> I'm having second thoughts.
>
> Does anyone have any good arguments one way or the other?  Scratch this --
> does anyone have any arguments, not necessarily good?

I think I would lean towards (2). As you say, it's more compact, but
also, I think it makes sense conceptually: A v4-over-v6 *route* is
certainly something new, but a *next hop* itself is not v4-over-v6, it's
just a v6 address; so why would it need its own AE?

-Toke