Re: [dhcwg] Question re. interpretation of option 33 destination addr

Ted Lemon <mellon@nominum.com> Sat, 10 July 2004 05:54 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10063; Sat, 10 Jul 2004 01:54:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BjAfY-0005ha-Np; Sat, 10 Jul 2004 01:45:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BjAdc-0005TP-Oy for dhcwg@megatron.ietf.org; Sat, 10 Jul 2004 01:43:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09641 for <dhcwg@ietf.org>; Sat, 10 Jul 2004 01:43:03 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BjAda-0000PL-LS for dhcwg@ietf.org; Sat, 10 Jul 2004 01:43:02 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BjAcr-00006a-00 for dhcwg@ietf.org; Sat, 10 Jul 2004 01:42:17 -0400
Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BjAcD-0007aV-00 for dhcwg@ietf.org; Sat, 10 Jul 2004 01:41:37 -0400
Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 20C081B200D; Sat, 10 Jul 2004 00:34:32 -0500 (CDT)
In-Reply-To: <EDD1E956-D20F-11D8-B32F-000A9568B702@cisco.com>
References: <EDD1E956-D20F-11D8-B32F-000A9568B702@cisco.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <CDD73259-D233-11D8-86FA-000A95D9C74C@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon <mellon@nominum.com>
Subject: Re: [dhcwg] Question re. interpretation of option 33 destination addr
Date: Fri, 09 Jul 2004 22:41:34 -0700
To: Richard Johnson <raj@cisco.com>
X-Mailer: Apple Mail (2.618)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit

I think the real answer to this question is that the reason we trashed 
option 33 is precisely that there is no sensible way to answer the 
question you have asked.   Sure, you could try to impute some subnet 
mask on an obviously invalid network destination, but you really 
couldn't do it safely.   For example, is 10.0.2.0 a /24 or a /23?   Do 
we impute subnet masks on octet boundaries, or on bit boundaries?

So I think the right answer is to just use the classless static routes 
option if you want to have network destination addresses that are not 
consistent with classed routing.   I think this is why option 33 is so 
infrequently used - it just doesn't work.


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg