Re: [Dime] Suresh Krishnan's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT)

Dave Dolson <> Thu, 24 May 2018 02:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18A91129C53; Wed, 23 May 2018 19:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RmrW6RjDd9L0; Wed, 23 May 2018 19:03:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5D3C51200F1; Wed, 23 May 2018 19:03:33 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <>) id 1fLfbI-0000Te-29; Wed, 23 May 2018 22:03:32 -0400
To: Suresh Krishnan <>, The IESG <>
Cc:, Jouni Korhonen <>,,
References: <>
From: Dave Dolson <>
Message-ID: <>
Date: Wed, 23 May 2018 22:03:28 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [Dime] Suresh Krishnan's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 May 2018 02:03:35 -0000


Please see inline.

On 2018-05-23 04:55 PM, Suresh Krishnan wrote:
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-dime-rfc4006bis-08: Discuss
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Section 8.38.
> RFC5952 contains significant changes in text representation from RFC3513 and I
> am concerned that there might be RFC4006 compliant implementations that will no
> longer be legal with a MUST level use of RFC5952. e.g. Addresses with upper
> case hex digits, with leading zeroes in 16 bit fields etc. Has the working
> group considered this break in compatibility already in its discussions?
> If it has, this text should still be finessed a bit because RFC5952
> recommendations (even at the MUST level) are a SHOULD for senders with the
> receivers being required to handle all possible legal formats as per RFC4291.
> So at least the sender rules and receiver rules need to be written differently.
If I recall correctly, we did give this some thought. RFC 5952 was 
presumably done for a reason, due to flaws in previous descriptions of 
address format. Hence it is prudent to use the new requirements. 
Implementations are free to be liberal in what they receive, for 
backwards compatibility with RFC 4006.
So I think it's fair to say this standard requires use of RFC 5952 syntax.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Section 8.65
> Any reason you are allowing encoding an IPv4 address as a IPv4-Mapped IPv6
> Address while you can directly use address family 1 to encode it directly as an
> IPv4 address? This allows for two different encodings for the same address.
Because IPv4-mapped IPv6 is a good idea. It allows coders to ignore IPv4 
and just develop for IPv6.
If we hadn't mentioned it explicitly, I think some people would have 
assumed it to be supported and others not.
So we had the choice of allowing it or prohibiting it. We chose to allow.