Re: AW: I-D Action: draft-foglar-ipv6-ull-routing-00.txt

Brian E Carpenter <> Mon, 13 November 2017 00:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E18BD126CD6; Sun, 12 Nov 2017 16:15:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FXP1QznYlDAl; Sun, 12 Nov 2017 16:15:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E61091241F5; Sun, 12 Nov 2017 16:15:24 -0800 (PST)
Received: by with SMTP id j28so8295974pfk.8; Sun, 12 Nov 2017 16:15:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SBwLysaQgmNCbBQTTaTdqTJ2P9Lr6n8Ab1/gVcd/LaM=; b=a6bbrOiVu6BMuEQeQQ5qsrCKpn4zre4H0hYXJ/oAmg777n65Z+Lazz25bYbfRRWIAd uwx2EJbFNyfo5B0ZANom5wz1weZ65Uzm5Zl9daqOoUem5X7aHnhCmekQRuybEU+njtbY Fub9u9YahgLkzmQAw3HLPf5f6fwsTiCPl5KYMa6rBk6DUeMxJdmyVSLs6f7OUbCmhfcS ecPMWMQL+uFJFLkPBIxu0GAHWwTa6RhQatSlIs0kv9IM3/nR/u/JVo2f0jQp1cnYl9Di JGrMXG2FTF7gJpKTOiF79JBZFtU2KMELnmNwmoa6KNCg6ZkrevQwtATZbVyIVu43nTVz Du7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=SBwLysaQgmNCbBQTTaTdqTJ2P9Lr6n8Ab1/gVcd/LaM=; b=exjgdUH7fvYtiOA8uAOEi03pVOTYOrhmr1/BsW94+Uq37VjcW0cZCwgYv0+50o1E+7 UDm5KyDhp34JTA6bj9uqENa3M2g0FIjS7B1/HjRHCUnSuZYrt1nrqfqvVitp+0KJNXPl 3GcnnHbqi7OGDEtKOXsU8oH66vSU877nyrm9nEUO/85pYsQ7roqKGLuR9NIr4gHwwUcv A5Bdnlo47itS5CsttXII1sZnJVLpKSuOYBRcZQqQiwMOCjwNtuZC2J7qGZEDjXzlM1hl qmJq04OshoirHCw8n+2RfLn7mfgioGeJLUrD7HxzLYPAKhXw4VIhj3DprhXdH+DzoiCu 4q1A==
X-Gm-Message-State: AJaThX5a7hVf/7SqdrCZgu66+TRAfNGJbKxLIZ7Ki7y6rY8YrFkUjmTO zco57r8vjXuMBlgP1MZFLlt51Lt9
X-Google-Smtp-Source: AGs4zMaKfoFmaNzHYManrOIOngA9GxfZr0AzH3s7hLZs2stBcdYSI3k0fGsb0HyBPlOcB+XcTuK64g==
X-Received: by with SMTP id f9mr7006805pli.76.1510532124430; Sun, 12 Nov 2017 16:15:24 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id l21sm18990722pgc.76.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 16:15:23 -0800 (PST)
Subject: Re: AW: I-D Action: draft-foglar-ipv6-ull-routing-00.txt
To:, 'Mark Smith' <>, 'Ole Troan' <>, 'Mikael Abrahamsson' <>
Cc:, '6man WG' <>, Mike Parker <>, Theodoros Rokkas <>
References: <> <> <> <> <> <02d801d35bf9$b9f96530$2dec2f90$>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Mon, 13 Nov 2017 13:15:22 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <02d801d35bf9$b9f96530$2dec2f90$>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Nov 2017 00:15:27 -0000

On 13/11/2017 10:03, wrote:
> Dears Mark, Brian, Ole, Mikael and Bob,
> Thank you for your valuable comments to our draft. 
> First of all, I am sorry that the sentence “One of the goals of IPv6 was to have a sufficiently long address to allow grouping in fields to simplify routing decisions.” did cause so much irritation.
> The background was: in the mid-nineties I have read a document called “The case for IPv6”, where one of its goals was that the structure of the IPv6 address should simplify routing. I remember this requirement well, because at that time I was working for a chip manufacturer and we considered making a dedicated IPv6 routing chip. Unfortunately, I could not find this document for the original citation.

That was a white paper from the ex-vendor Bay Networks that was
transformed into the controversial draft-ietf-iab-case-for-ipv6, which
was never published as an RFC and which even the IETF data tracker
has forgotten. I have a copy of draft-ietf-iab-case-for-ipv6-06
(December 1999).

It does indeed contain the following claim:
" An independent
  IPv6 architecture presents the opportunity to build a fresh,
  hierarchical network address plan that will facilitate connection to
  one or more ISPs.  This simplifies renumbering, route aggregation
  (summarization), and other goals of a routing hierarchy."

I suspect that is one of the main reasons the document was scrapped,
since that isn't how IP routing works in the real world.


> Answer: I will remove the first two of the chapter sentences and add this simple one:
> "The following proposal uses the 64-bit IPv6 address prefix." 
> Next, I thank Ole Troan for citing Y. Rekhter: “Addressing can follow topology or topology can follow addressing; choose one”.
> Answer: in this case addressing and topology already match perfectly. In short: where more people are living there are more telephone numbers assigned. In case there are not enough addresses there are spare ones: currently only the digits 0…9 are used; by extending to A…F the address space can be almost doubled. 
> Finally, there was a comment the proposal means replacing a great deal of existing software and hardware. 
> Answer: hardware effort is low, as not all hierarchies must be populated by forwarding nodes. Also, existing infrastructure such as transmission links can be reused. Both are outlined in an example at the end of the draft. 
> A corrected draft is uploaded.
> With best regards,
> Andreas Foglar
> InnoRoute CEO
> Phone +49-89-4524199-01
> Mail <> 
> <> 
> Marsstr. 14a, D80335 Munich, Germany
> -----Ursprüngliche Nachricht-----
> Von: Mark Smith [] 
> Gesendet: Samstag, 16. September 2017 03:07
> An: Brian E Carpenter <>;
> Cc: Ole Troan <>;;; 6man WG <>;
> Betreff: Re: I-D Action: draft-foglar-ipv6-ull-routing-00.txt
> On 16 September 2017 at 09:31, Brian E Carpenter < <> > wrote:
>> On 15/09/2017 20:10, Ole Troan wrote:
>>>> Re
>>>> "One of the goals of IPv6 was to have a sufficiently long address to 
>>>> allow grouping in fields to simplify routing decisions."
>>>> What makes you believe that? I don't recall such a goal in the IPng 
>>>> process, and I can't see any trace of it in RFC1752 or RFC1726.
>>> “Addressing can follow topology or topology can follow addressing; 
>>> choose one” - Y Rekhter
>>> Goal or no goal, we know of no other way to make the routing system scale.
>> Sure. I agree with that and with the RIPE policy that Mikael cited. 
>> Believe me, everybody in the IPng discussion was acutely aware of the 
>> tension between PA and PI addressing and the benefits of aggregation 
>> when possible. But that is very different from the quoted "goal", 
>> which simply wasn't there. Allowing topological aggregation was a 
>> goal, of course, but that's always been a matter of prefix assignment policy, not of the protocol design.
>> Please note that I did not say that their idea will not work. It's the 
>> "alternative fact" that I'm concerned about.
>>From what I've read in Christian Huitema's IPv6 book, at one stage
> there was a thought of swapping the source and destination address fields so that the DA field was first, to facilitate this sort of cut-through forwarding. From memory, the explanation was that it was decided against was because fields other than the just the DA address have to be processed during layer 3 forwarding.
> Regards,
> Mark.
>>     Brian
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> <> 
>> Administrative Requests:
>> --------------------------------------------------------------------