Re: [shara] comments about draft-bajko-pripaddrassign-00
<teemu.savolainen@nokia.com> Wed, 25 February 2009 12:57 UTC
Return-Path: <teemu.savolainen@nokia.com>
X-Original-To: shara@core3.amsl.com
Delivered-To: shara@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id 2197728C169 for <shara@core3.amsl.com>;
Wed, 25 Feb 2009 04:57:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.255
X-Spam-Level:
X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=0.343,
BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMn3kAH0J1Fq for
<shara@core3.amsl.com>; Wed, 25 Feb 2009 04:57:35 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by
core3.amsl.com (Postfix) with ESMTP id 5ECD23A688A for <shara@ietf.org>;
Wed, 25 Feb 2009 04:57:34 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com
[172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with
ESMTP id n1PCvcoC028349; Wed, 25 Feb 2009 14:57:50 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);
Wed, 25 Feb 2009 14:57:33 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com
over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);
Wed, 25 Feb 2009 14:57:32 +0200
Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by
NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS)
id 8.1.291.1; Wed, 25 Feb 2009 13:57:32 +0100
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by
nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi;
Wed, 25 Feb 2009 13:57:32 +0100
From: <teemu.savolainen@nokia.com>
To: <denghui02@gmail.com>, <shara@ietf.org>
Date: Wed, 25 Feb 2009 13:56:59 +0100
Thread-Topic: [shara] comments about draft-bajko-pripaddrassign-00
Thread-Index: AcmXReIow6JlaZIPRJ+ROmdvzrZk0AAAFaXA
Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27E89F0EEF@NOK-EUMSG-01.mgdnok.nokia.com>
References: <1d38a3350902250437v3ad37690sc5d2dca7f78dddd4@mail.gmail.com>
In-Reply-To: <1d38a3350902250437v3ad37690sc5d2dca7f78dddd4@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative;
boundary="_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E89F0EEFNOKEUMSG01mgd_"
MIME-Version: 1.0
X-OriginalArrivalTime: 25 Feb 2009 12:57:32.0906 (UTC)
FILETIME=[9FAC04A0:01C99748]
X-Nokia-AV: Clean
Subject: Re: [shara] comments about draft-bajko-pripaddrassign-00
X-BeenThere: shara@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Sharing of an IPv4 Address discussion list <shara.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/shara>,
<mailto:shara-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shara>
List-Post: <mailto:shara@ietf.org>
List-Help: <mailto:shara-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shara>,
<mailto:shara-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 12:57:36 -0000
Hi,
1) It should be described in 6.2 Server behaviour:
--
If OPTION-IPv4-PRA is not present in DHCPDISCOVER, the server SHOULD
allocate full unrestricted public or private [RFC1918] IPv4 address
to the client, if available, by generating a DHCPOFFER as described
in [RFC2131].
--
and forward.
So essentially the same DHCP server is allocating both full and port restricted IPv4 addresses, depending on host's support.
2) Excellent question. The lease time will have to be per port set instead of per IPv4 address as currently.
- For a client this does not make any difference when compared to full IPv4 address (client has to renew the address and when the lease ends, the IPv4 address expires whatever was the size of allocated port set)
- For the DHCP server this is clearly more complex, though. The DHCP server has to follow lease times per allocated port set. So if the server splits an IPv4 address into 10 sets, it has to have lease time follow-up for all those 10 sets. The clients will be varyingly renewing the port set they were allocated, and also individual port sets may be released/expired individually.
For me it looks the DHCP server needs two tables: one for managing full IPv4 addresses, and one for managing port-restricted IPv4 addresses. Maybe those could be combined as well if the full IPv4 address is just considered a port-restricted IPv4 address with single 64K port allocation. I.e. something like:
{ 10.0.0.1 - port set FULL }
{ 10.0.0.2 - port set partial-A }
{ 10.0.0.2 - port set partial-B }
I hope I find time to digg deeper into this before next IETF, but let's see. Anyhow, I believe the actual impact to lease time management on the server side depends on individual implementations.
I hope I answered your questions.
Best regards,
Teemu
________________________________
From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] On Behalf Of ext Hui Deng
Sent: 25 February, 2009 14:38
To: shara@ietf.org
Subject: [shara] comments about draft-bajko-pripaddrassign-00
Hello, Authors.
I read through the document
1) when some clients support option-pra, but others don't, will server behavior section
describe this scenario?
2) how to handle lease life time of dhcp address
thanks
-Hui