[Sipping] Re: Comments on draft-ietf-sipping-ipv6-torture-tests-01.txt

"Vijay K. Gurbani" <vkg@alcatel-lucent.com> Wed, 04 April 2007 16:14 UTC

Return-path: <sipping-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ87X-0003VZ-I0; Wed, 04 Apr 2007 12:14:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ87V-0003VL-C8 for sipping@ietf.org; Wed, 04 Apr 2007 12:14:01 -0400
Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ87U-0004z7-26 for sipping@ietf.org; Wed, 04 Apr 2007 12:14:01 -0400
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l34GDnqY011964; Wed, 4 Apr 2007 11:13:50 -0500 (CDT)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l34GDjA14547; Wed, 4 Apr 2007 11:13:45 -0500 (CDT)
Message-ID: <4613CEB9.2030209@alcatel-lucent.com>
Date: Wed, 04 Apr 2007 11:13:45 -0500
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Organization: Bell Labs Security Technology Research Group
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "B, Nataraju" <bnataraju@sonusnet.com>
References: <70798CF421F00F4DA018059E5B7EEB8C0109AC2E@sonusinmail01.sonusnet.com>
In-Reply-To: <70798CF421F00F4DA018059E5B7EEB8C0109AC2E@sonusinmail01.sonusnet.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ihemail1.lucent.com id l34GDnqY011964
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: RjS@estacado.net, cboulton@ubiquitysoftware.com, sipping@ietf.org, Mary Barnes <mary.barnes@nortel.com>
Subject: [Sipping] Re: Comments on draft-ietf-sipping-ipv6-torture-tests-01.txt
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Errors-To: sipping-bounces@ietf.org

B, Nataraju wrote:
> Hi All,
> 
> Here are few comments on the draft ipv6-torture-tests-01.txt.

Hi Nataraju: Thanks for reviewing the draft.  Please see inline.

> 1. Lets not allow IPV6 addresses with out [ & ], this is a deviation 
> from RFC 3261 also.

Pedantically speaking, rfc3261 only wants the "[" and "]"
delimiting tokens for the IPv6reference production rule.  It
does NOT require these for the IPv6address production rule.

There has not been WG consensus on mandating the "[" and "]"
delimiting tokens for the IPv6address production rule -- this
is reflected in the ipv6-torture-tests draft.  That is
why it takes the position that a receiving implementation must
be robust enough to parse the IPv6address symbols with and
without the delimiters.

> This would definitely lead to interoperability issues later.

Hopefully these will be mitigated if implementors followed the
Robustness Principle of rfc1122 (also referenced in S4.5 of
ipv6-torture-tests.)

> 2. Replace all instances of umabiguous with unambiguous

Ouch; thanks!  Will do.

> 3. via-received not including delimiters [ & ] would make 
> implementations complex or why don’t we make sure all IPv6 addresses 
> always accompany with delimiters [ & ]. This loop hole will definitely 
> lead to interoperability issues some time later....

See discussion above.

> 4.
> 
> Sec 4.5 param-2 of draft ipv6-torture-tests-01 is not valid with respect 
> to 3261
> 
>         hence let us remove this test case

Actually, it is valid as per the ABNF in rfc3261.  The received
parameter contains an IPv6 address that follows the IPv6address
production rule, which does NOT require the delimiters.

> Ref: 4.6.  SIP request with IPv6 addresses in SDP body
> 
> Even here also shall we mandate addresses are with [ & ]

Unfortunately, we cannot do that.  RFC4566 (SDP) does not require
that an IPv6 address be delimited by "[" and "]" (see IP6-address
production rule in the ABNF of rfc4566.)  Thus, rfc3261 cannot
over-ride it, and neither can this draft.

Thanks.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP