RE: [dhcwg] Predictable DHCP

From daemon@ns.ietf.org Tue Apr 2 16:46:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04763 for ; Tue, 2 Apr 2002 16:46:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15799 for dhcwg-archive@odin.ietf.org; Tue, 2 Apr 2002 16:46:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15554; Tue, 2 Apr 2002 16:40:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15524 for ; Tue, 2 Apr 2002 16:40:40 -0500 (EST) Received: from hotmail.com (f134.law3.hotmail.com [209.185.241.134]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04621 for ; Tue, 2 Apr 2002 16:40:29 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 Apr 2002 13:40:01 -0800 Received: from 128.49.153.28 by lw3fd.law3.hotmail.msn.com with HTTP; Tue, 02 Apr 2002 21:40:01 GMT X-Originating-IP: [128.49.153.28] From: "Matthew Wong" To: dhcwg@ietf.org Date: Tue, 02 Apr 2002 13:40:01 -0800 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 02 Apr 2002 21:40:01.0863 (UTC) FILETIME=[F1B77D70:01C1DA8E] Subject: [dhcwg] Predictable DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org

Is it possible to use DHCP to assign IP addresses in a predictable manner? For example, is it possible to use the MAC address of a NIC so that DHCP always assigns a specific IP to a specific MAC address? This or something similar would help.

My situation is, essentially, this: our company maintains a mobile computing network. Basically a 15 port router with 15 laptops. Each and every machine needs to be kept identicle with the exception of their IP address. This makes maintainance and upgrading easy (usually done with a Norton Ghost Multicast session). The problem is that I need to assign IP address for each machine. I.E. DHCP would work but I want a static IP situation without the configuration hassels!

Is there a workaround or a software package that I should be aware of? Also, can anyone recommend a software package that loads a new image at startup (discarding changes to the system but maintaining working status)?

Thank you,

Matthew K. Wong

MSN Photos is the easiest way to share and print your photos: Click Here
_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Tue Apr 2 16:48:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04872 for ; Tue, 2 Apr 2002 16:48:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15945 for dhcwg-archive@odin.ietf.org; Tue, 2 Apr 2002 16:48:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15861; Tue, 2 Apr 2002 16:46:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15830 for ; Tue, 2 Apr 2002 16:46:53 -0500 (EST) Received: from portal.incognito.com (PORTAL.INCOGNITO.COM [207.102.214.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04778 for ; Tue, 2 Apr 2002 16:46:49 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by portal.incognito.com with smtp (Exim 3.33 #1) id 16sW4a-00088E-00; Tue, 02 Apr 2002 13:44:12 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 13:51:30 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D1984955DF@homer.incognito.com.> From: "Kostur, Andre" To: "'Matthew Wong'" , dhcwg@ietf.org Subject: RE: [dhcwg] Predictable DHCP Date: Tue, 2 Apr 2002 13:51:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA90.8BE7E1E0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DA90.8BE7E1E0 Content-Type: text/plain; charset="iso-8859-1" Most DHCP servers that I'm aware of (Incognito's, ISC, Microsoft) can do static DHCP assignments based upon requesting MAC address. About the only DHCP servers that I know of that can't do it are embedded DHCP servers. -----Original Message----- From: Matthew Wong [mailto:keilinw@hotmail.com] Sent: Tuesday, April 2, 2002 1:40 PM To: dhcwg@ietf.org Subject: [dhcwg] Predictable DHCP Is it possible to use DHCP to assign IP addresses in a predictable manner? For example, is it possible to use the MAC address of a NIC so that DHCP always assigns a specific IP to a specific MAC address? This or something similar would help. My situation is, essentially, this: our company maintains a mobile computing network. Basically a 15 port router with 15 laptops. Each and every machine needs to be kept identicle with the exception of their IP address. This makes maintainance and upgrading easy (usually done with a Norton Ghost Multicast session). The problem is that I need to assign IP address for each machine. I.E. DHCP would work but I want a static IP situation without the configuration hassels! Is there a workaround or a software package that I should be aware of? Also, can anyone recommend a software package that loads a new image at startup (discarding changes to the system but maintaining working status)? Thank you, Matthew K. Wong ------_=_NextPart_001_01C1DA90.8BE7E1E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Predictable DHCP

Most DHCP servers that I'm aware of (Incognito's, = ISC, Microsoft) can do static DHCP assignments based upon requesting = MAC address. About the only DHCP servers that I know of that = can't do it are embedded DHCP servers.

-----Original Message-----
From: Matthew Wong [mailto:keilinw@hotmail.com]
Sent: Tuesday, April 2, 2002 1:40 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Predictable DHCP

Is it possible to use DHCP to assign IP addresses in = a predictable manner? For example, is it possible to use the MAC = address of a NIC so that DHCP always assigns a specific IP to a = specific MAC address? This or something similar would = help.

My situation is, essentially, this: our company = maintains a mobile computing network. Basically a 15 port router = with 15 laptops. Each and every machine needs to be kept = identicle with the exception of their IP address. This makes = maintainance and upgrading easy (usually done with a Norton Ghost = Multicast session). The problem is that I need to assign IP = address for each machine. I.E. DHCP would work but I want a = static IP situation without the configuration hassels!

Is there a workaround or a software package that I = should be aware of? Also, can anyone recommend a software package = that loads a new image at startup (discarding changes to the system but = maintaining working status)?

Thank you,

Matthew K. Wong

------_=_NextPart_001_01C1DA90.8BE7E1E0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Tue Apr 2 21:00:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11330 for ; Tue, 2 Apr 2002 21:00:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA03833 for dhcwg-archive@odin.ietf.org; Tue, 2 Apr 2002 21:00:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03400; Tue, 2 Apr 2002 20:56:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03383 for ; Tue, 2 Apr 2002 20:56:40 -0500 (EST) Received: from flounder.gibbons.com (sdsl-66-80-7-162.dsl.sca.megapath.net [66.80.7.162]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11242 for ; Tue, 2 Apr 2002 20:56:38 -0500 (EST) Received: from gibbons.com (sdsl-66-80-7-166.dsl.sca.megapath.net [66.80.7.166]) by flounder.gibbons.com (8.11.2/8.11.2) with ESMTP id g331uda25418 for ; Tue, 2 Apr 2002 17:56:39 -0800 Message-ID: <3CAA6136.A0723C11@gibbons.com> Date: Tue, 02 Apr 2002 17:56:07 -0800 From: bao X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dhcp Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] No DHCPOFFER message Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit My server is running RH 7.2 with dhcpd-1.3.18p18-10. It is configured as follows, ================== # dhcpd.conf subnet 66.80.7.160 netmask 255.255.255.224 { # --- default gateway option routers 66.80.7.161; option subnet-mask 255.255.255.224; option broadcast-address 66.80.7.191; option domain-name "mydomain.com"; # ISP's DNS addresses option domain-name-servers 216.200.176.4, 216.34.237.2; option time-offset -18000; # Eastern Standard Time # --- Selects point-to-point node (default is hybrid). Don't change this unless # -- you understand Netbios very well # option netbios-node-type 2; range dynamic-bootp 66.80.7.188 66.80.7.190; default-lease-time 7200; max-lease-time 9000; # we want the nameserver to appear at a fixed address host testmachine { hardware ethernet 00:10:4b:2c:af:48; fixed-address 66.80.7.166; } } ================== The server accepts all the configuration parameters, and can be started. However, when the client testmachine is configured to use DHCP and is booted up, packetsniffer indicates that although there are DHCPDISCOVER messages (several, indeed, after the client sees no response, it retransmits), there is not any DHCPOFFER message. The server stays silent. Does anyone see any misconfigurations in the dhcpd.conf file above, and have any suggestions? Thanks, _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Wed Apr 3 11:36:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08483 for ; Wed, 3 Apr 2002 11:36:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07797 for dhcwg-archive@odin.ietf.org; Wed, 3 Apr 2002 11:36:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06067; Wed, 3 Apr 2002 11:16:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06042 for ; Wed, 3 Apr 2002 11:16:45 -0500 (EST) Received: from dreamwiz.com ([61.254.5.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07833 for ; Wed, 3 Apr 2002 11:16:31 -0500 (EST) Message-Id: <200204031616.LAA07833@ietf.org> Reply-To: sexycodi@dreamwiz.com From: 애플코디 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 4 Apr 2002 01:17:15 +0900 Subject: [dhcwg] [코디정보] "7cm 키크기만 꼭!?" - 다리의 단점을 보완하는 코디 [광*고] Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org

Street Sketch & Seco Shop

국내, 해외 거리스케치 눈요기 어떠세요? *^^*

거리스케치 [ 3 월스타 ]
코디평 : 38 개 , 코디합계 : 3600점

2002-03-21
이공섭/남자/21/?
취재거리 : 동대문

가장 좋아하는 가수는?
엠-플로
리포터의 한마디
B-boy스탈!타미 힐피거 셔츠에
디키즈 청바지군요,키가 크셔서
평범한 코디에도 멋짐니다^-^

산뜻한 봄맞이 바지 어떠세요?

1.봄, 여름, 가을까지 입을 수 있는 면 워싱 바지
2.허리 사이즈 프리로 28인치에서 34인치까지 커버!
3.특별 배합한 독창적인 염색칼라.
4.구김이 없고 편안한 면바지
5.남,여 공용
6.멋진 스타일링의 탁월한 선택!

해외거리스케치

2002-03-23
코바야시/남자/20/후리타
취재거리 : 타카시마야

가장 좋아하는 가수는
Red Hot Chlli Peppers
춥지 않으세요? 다리를 드러내시고..
조금 춥긴 춥네요~~
그래도 패~~션인데요~~^^

이 분 스타일이 아주 스포티하지 않나요?

스쿨룩 [ 3 월스타 ]
코디평 : 5 개 , 코디합계 : 350점

2002-03-20
황성용/남자/17/서초전자고등학교

좋아하시는 여자 연예인
짱나라
리포터 한마디^^
안경이 대게 비싼거래요^^
취재도와주셔서 감사하구 사진 늦게올라가서 죄송합니다
(__)

나어때 [ 3 월스타 ]
코디평 : 23 개 , 코디합계 : 2100점

2002-03-06
구민성/남자/17/심인고

어떤 스타일의 옷을 선호하시나요?
추잡은 닛뽄삘 말고 깨끗한 닛뽄삘 산뜻한것~
자기 자신에 대한 PR
멋진남자! 멋진녀석! 나이스 가이!!
송현동 멋진녀석입니다!

- "정보통신망이용촉진등에관한법률시행규칙개정령"에 의거 제목에 [광고]라 표시된 광고 메일입니다.
- 메일수신거부를 하실 경우 더 이상 메일이 가지 않습니다.
- 귀하의 email ID는 게시판 등 기타 공개된 자료에서 수집된 것으로 이상의 다른 개인정보는 없습니다.
- email 서비스를 원하지 않으시면 [수신거부]를 클릭하세요.

- 애플코디 매거진 서비스를 계속 받고 싶으시면 [애플코디 매거진 회원등록]을 한번 클릭하세요.

(주)섹시코디 sexycodi@sexycodi.com Tel.0505-700-1616

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Wed Apr 3 12:06:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09306 for ; Wed, 3 Apr 2002 12:06:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11314 for dhcwg-archive@odin.ietf.org; Wed, 3 Apr 2002 12:06:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08750; Wed, 3 Apr 2002 11:51:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08678 for ; Wed, 3 Apr 2002 11:51:42 -0500 (EST) Received: from localhost ([211.229.42.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08895 for ; Wed, 3 Apr 2002 11:51:28 -0500 (EST) Message-Id: <200204031651.LAA08895@ietf.org> Reply-To: leecs01@hotmail.com From: 한국취업정보 To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 4 Apr 2002 01:53:24 +0900 Subject: [dhcwg] <광 ~ 고> 한국취업정보입니다. 취업! 책임지겠습니다~~~ Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org :::060-707-9292:::

⊙ 한국취업정보입니다.
아래 자료는 저희 회사에 등록되어 있는 구인업체 구인현황중 일부분의
홍보자료입니다. 이외에도 전국에서 구인을 희망하시는 구인업체들이
매일 새롭게 등록을 하고 있습니다. 우선, 귀하께서 저희 회사에 구직등록을
해 주시면 등록된 구인업체의 정보를 안내 받으실 수 있습니다.
----------------------------------------------------------------
⊙ 상담전화는 060-707-9292 번이며 저희 회사의 상담 직원이 직접 접수
를 받고있습니다. 본 상담은 30초당 500원 의 정보 이용료가 부과되며 별도
의 수수료는 없습니다. 명단 중 적합한 구인업체가 없을 경우 해당업체로
약 15 일 동안 무료로 홍보를 해 드림으로 한번의 구직등록으로 귀하의
능력을 맘껏 발휘할 수 있는 직장을 찾으실 수 있습니다.
----------------------------------------------------------------
⊙ 현재 일자리를 찾고 계시다면 지금 바로 연락주시고, 상담을 제외한 기타
문의 사항은 0502-707-9292 번으로 문의 주십시오
(상담시간 오전 9시 ~ 오후 7시까지)

한국 취업 정보 060 - 707 - 9292
---------------------------
[ 정보 이용료 30초당 500원 ]

아래 구인업체의 상세 정보를 얻고자 하시면
전화 060 - 707 - 9292 를 통해 구직등록을 하신 후 안내를 받으실 수 있습니다.

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Wed Apr 3 13:02:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10906 for ; Wed, 3 Apr 2002 13:02:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15508 for dhcwg-archive@odin.ietf.org; Wed, 3 Apr 2002 13:02:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14427; Wed, 3 Apr 2002 12:49:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14408 for ; Wed, 3 Apr 2002 12:49:26 -0500 (EST) Received: from empal.com ([61.76.148.117]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10552 for ; Wed, 3 Apr 2002 12:49:22 -0500 (EST) Message-Id: <200204031749.MAA10552@ietf.org> Reply-To: eunjw1@empal.com From: 은종원 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 4 Apr 2002 02:49:19 +0900 Subject: [dhcwg] ★ 특별한 반지가 필요할 때 [홍보] Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org :::소금의 집:::

님 안녕 하세요?

진심으로 죄송하게 생각 하옵니다.

지우시기 전에 한번만 클릭 해 봐 주셔요

님께 결코 실망을 드리지 않을 것입니다

온,오프라인상에서 영업활동을 하는 차즈리의 CMD로서 평생활동을 보장 받을 수 있습니다. 차즈리에서 제공하는 상품(홈페이지, 쇼핑 몰, 쿠폰……등)의 영업권을 부여 받아 매출을 발생하는 새로운 개념의 비즈니스 모델입니다. 언제든지 자유롭게 영업에 임하실 수 있으며 영업을 통해 수입을 창출합니다.지역의 한계 없이 사업에 대한 열정이 있는 누구나 마케팅 인프라 구축을 통해 글로벌 마케팅이 가능합니다.

과거, 현재, 미래를 통틀어 이렇게 쉽고 강력한 마케팅은 찾기 힘들 것입니다.
기회는 언제나 그렇듯이 다가올 때 잡아야 하는 것입니다.
기타 자세한 내용이나 문의사항은 아래의 연락처로 연락을 주시거나 메일을 주시기 바랍니다.

▶ 홈페이지 : www.chazri.com / www.coupon2you.co.kr
▶ E-mail : cmdchazri@chazri.net
▶ 전화 : 02-591-7212 팩스 : 02-591-7214
▶ 담당자 : 박 승 진 팀장

본 메일은 정보통신부 권고사항에 의거, 제목에 [광고]라 표시된 광고 메일 입니다.
수신을 원치 않으시면 [메일수신거부를 클릭하세요.]

Hi all,

I am currently implementing DHCPv6 = (draft 23) and=20 have some questions regarding the DHCPv6 Relay Message.

Question: Is it possible to have a = generic DHCPv6=20 message structure for all (even the relayed messages) messages ? I must=20 apologise if this issue has been rised previously.

The idea is to have a common DHCP = message for all=20 message exchange. Since both the link-address and client-return-address = are IPv6=20 addresses, we can carried these addresses as Options (e.g Address = Option) in the=20 DHCPv6 message. These options are placed in front of the rest of the = options=20 (e.g Client/Server Message Options) so that servers = can=20 discard any messages from the Relay if the servers decide not to reply = based on=20 the two addresses.

The advantage is a preferred generic = message=20 structure for all DHCPv6 messages. This enables the processing of DHCPv6 = message=20 to be identical for both the server and relay (at least the = encoding/decoding=20 mechanism). Or is there any issues that I have overlook.

I must apologize if my proposal = sounds=20 irrelevant. Please comment.

Thank you,

Paul



아직 엔브라이드를 모르시나요? 매일매일 즐겁게 클릭해서 더욱 행복해지는 행복한 여자쇼핑몰 엔브라이드입니다. 엔브라이드와 친해지고는 공∼주되세요.

	▶엔브라이드 고객의소리 중에서 저, 감동했어요! 정말 감사합니다. 어이없이 잃어버리고는 스스로 얼마나 한심해 보였는지... 그렇지 않아도 이 잼포트가 좋아서 몇 개를 더 사려고 하던 참이었답니다. 음음음... 다른 물건들도 살 것이 없나 좀더 살펴보고 주문할게요. 다시 한 번 정말 감사합니다. - maminova 앤을 알고 부턴 인터넷 쇼핑이 넘 즐거워요!! 좋은 상품 구할수 있고 넘 넘 빠르고... 짱입니다요!! 앤에 길들여진 이후로 참을성이 부족해 졌나봐요. 지난번 선물하려고 샐러드볼 구입했다가 넘 이뻐서 제가 쓰고 있는데 ........... -fresh

	주방홀더 (랩걸이)
	독일 라이프하이트
	￦35,000

	국수밀폐병
	보덤 (Bodum)
	￦25,000

	6슬롯 칼꽂이
	위스토프 드라이작
	￦126,000

	위타드 홍차
	영국 위타드오브첼시
	￦21,250

	무공해 냅킨세트
	독일 Thr
	￦6,000

	데이지 쟁반
	영국 클로버리프
	￦19,000

	안스버그 후라이팬
	독일 베른데스
	￦105,000

	투명석쇠
	일본 미넥스
	￦24,000

	시모무라 채칼세트
	일본 시모무라
	￦29,700

본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다
e-mail주소는 인터넷상에서 취득하였으며, 주소외 어떠한 개인 정보도 가지고 있지 않습니다
수신거부를 원하시면 수신거부해 주세요. 정보를 원치 않는 분께는 대단히 죄송 합니다.

Ralph:

This sounds OK to me though:

- You say "only one server will respond to the = client Solicit" yet then you later state in the proposal = "(and may ignore any received Advertise messages)". Did you = perhaps mean respond with a Reply (not just respond - with an = Advertise) in the requirements.

- What should a client do if it receives multiple = Reply's. Should it perhaps be required to Release those addresses? At = least then the resources other servers that also Reply have allocated = are released. This would require the client to "wait around" = for a short period of time for other Reply's.

Otherwise, this procedure seems fine to me. Even if a = client receives multiple Reply's and doesn't Release, IPv6 addresses = shouldn't be a scarce resource.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Friday, April 05, 2002 2:32 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Two message transaction in = DHCPv6

Based on a conversation with Mark Stapp, here's a = proposal for allowing a
two message exchange for configuration. prefix and = address assignment. The
goal of this proposal is to allow, under certain = circumstances, a client to
complete its initial DHCPv6 transaction with two = messages instead of the
current four messages, = Solicit-Advertise-Request-Reply. The circumstances
under which this mechanism is designed to work are: = only one server will
respond to the client Solicit; the server will = commit the prefixes and
addresses to the client immediately. The = proposed mechanism also allows a
client to indicate whether it is willing to = participate in a two message
transaction, and allows a server to force a four = message transaction
(according to local policy).

Here's the proposal...

A new TMT option (two message transaction) is = defined. The TMT option can
only be included in a Solicit message. There = is no data associated with
the TMT option.

The client includes a TMT option in its Solicit = message, indicating its
willingness to perform a two message = transaction.

If the server that receives a Solicit with a TMT = option has a policy to
perform the two message transaction, it determines = the client
configuration, commits the assignment of any = prefixes or addresses, and
sends the configuration to the client in a Reply = message.

If the server that receives a Solicit with a TMT = option does not have a
policy to perform the two message transaction, the = server ignores the TMT
option and responds with an Advertise.

If the client receives a Reply, it records the = configuration and is done
(and may ignore any received Advertise = messages). If the client receives
one or more Advertise messages but not Reply = message, the client sends a
Request to continue the four message = transaction.

I intend to include this mechanism in the -24 rev of = the DHCPv6 spec, which
I'm working on now. Comments welcome...

- Ralph

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

------_=_NextPart_001_01C1DCEC.5717BA90-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Fri Apr 5 16:59:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20305 for ; Fri, 5 Apr 2002 16:59:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA01551 for dhcwg-archive@odin.ietf.org; Fri, 5 Apr 2002 16:59:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01461; Fri, 5 Apr 2002 16:58:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01438 for ; Fri, 5 Apr 2002 16:58:36 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20207 for ; Fri, 5 Apr 2002 16:58:31 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g35Lw5i03103 for ; Fri, 5 Apr 2002 15:58:05 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g35Lw5o02094 for ; Fri, 5 Apr 2002 15:58:05 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Fri Apr 05 15:58:04 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 15:58:04 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4D1B8@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Reserved anycast address for DHCPv6 Date: Fri, 5 Apr 2002 15:58:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCEC.F59CEFA0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DCEC.F59CEFA0 Content-Type: text/plain; charset="iso-8859-1" Ralph: >One potential problem is that clients now have two addresses. Is this really such a problem? If the client's interface is on a NBMA network, it uses the anycast address. If it is on a multicast capable network, it uses the Multicast address. So, yes, clients need to know about the two addresses but they only need to send packets to one. >Does anyone on the list know anything about the proposal for reserving a >site-scoped SLA for anycast addresses? Have no idea. But, if we submit the request to IANA won't they do the address assignment and follow the rules? - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Friday, April 05, 2002 2:40 PM To: dhcwg@ietf.org Subject: [dhcwg] Reserved anycast address for DHCPv6 includes the definition of three anycast addresses for use by DNS resolvers: fec0:0:0:ffff::1 fec0:0:0:ffff::2 fec0:0:0:ffff::3 I had a request in Minneapolis that we consider defining an anycast address for DHCPv6 that would allow the use of DHCPv6 on NBMA networks. Seems to me like a reasonable suggestion. One potential problem is that clients now have two addresses: the All_DHCP_Agents multicast address and the new anycast address. Which should the client choose to use? BTW, the DNS Discovery draft includes the following: Note to readers: the above addresses are tentative, but the ffff is intended to be consistent with a simultaneous proposal to reserve the ffff SLA for use with IANA-assigned addresses such as these. Does anyone on the list know anything about the proposal for reserving a site-scoped SLA for anycast addresses? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1DCEC.F59CEFA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Reserved anycast address for DHCPv6

Ralph:

>One potential problem is that clients now have = two addresses.

Is this really such a problem? If the client's = interface is on a NBMA network, it uses the anycast address. If it is = on a multicast capable network, it uses the Multicast address. So, yes, = clients need to know about the two addresses but they only need to send = packets to one.

>Does anyone on the list know anything about the = proposal for reserving a
>site-scoped SLA for anycast addresses?

Have no idea. But, if we submit the request to IANA = won't they do the address assignment and follow the rules?

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Friday, April 05, 2002 2:40 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Reserved anycast address for = DHCPv6

<draft-ietf-ipv6-dns-discovery-04.txt> includes = the definition of three
anycast addresses for use by DNS resolvers:

    fec0:0:0:ffff::1
    fec0:0:0:ffff::2
    fec0:0:0:ffff::3

I had a request in Minneapolis that we consider = defining an anycast address
for DHCPv6 that would allow the use of DHCPv6 on = NBMA networks. Seems to
me like a reasonable suggestion.

One potential problem is that clients now have two = addresses: the
All_DHCP_Agents multicast address and the new = anycast address. Which
should the client choose to use?

BTW, the DNS Discovery draft includes the = following:

   Note to readers: the above addresses are = tentative, but the ffff
   is intended to be consistent with a = simultaneous proposal to
   reserve the ffff SLA for use with = IANA-assigned addresses such as
   these.

Does anyone on the list know anything about the = proposal for reserving a
site-scoped SLA for anycast addresses?

- Ralph

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

------_=_NextPart_001_01C1DCEC.F59CEFA0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Fri Apr 5 17:10:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01157 for ; Fri, 5 Apr 2002 17:10:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02726 for dhcwg-archive@odin.ietf.org; Fri, 5 Apr 2002 17:10:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02562; Fri, 5 Apr 2002 17:09:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02541 for ; Fri, 5 Apr 2002 17:09:31 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00806 for ; Fri, 5 Apr 2002 17:09:22 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g35M7Aq7014284 for ; Fri, 5 Apr 2002 14:07:11 -0800 (PST) Date: Fri, 5 Apr 2002 17:07:10 -0500 (EST) From: Ralph Droms To: dhcwg@ietf.org Subject: RE: [dhcwg] Two message transaction in DHCPv6 In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D1B7@EAMBUNT705> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Bernie, Comments in line... BTW, anyone have a better name than "TMT"? On Fri, 5 Apr 2002, Bernie Volz (EUD) wrote: > Ralph: > > This sounds OK to me though: > > - You say "only one server will respond to the client Solicit" yet then > you later state in the proposal "(and may ignore any received Advertise > messages)". Did you perhaps mean respond with a Reply (not just respond > with an Advertise) in the requirements. I was trying to simplify the scenario/requirements; perhaps I over-simplified. Anyway, the target scenario is one in which there is a single DHCP server that responds to the client request. > > - What should a client do if it receives multiple Reply's. Should it > perhaps be required to Release those addresses? At least then the > resources other servers that also Reply have allocated are released. > This would require the client to "wait around" for a short period of > time for other Reply's I'd be willing to add "May send a Release" in response to other Reply messages. In general, if a network architect wants to use multiple, overlapping servers, the servers shouldn't use the two message transaction. > Otherwise, this procedure seems fine to me. Even if a client receives multiple Reply's and doesn't Release, IPv6 addresses shouldn't be a scarce resource. > > - Bernie > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Friday, April 05, 2002 2:32 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Two message transaction in DHCPv6 > > > Based on a conversation with Mark Stapp, here's a proposal for allowing a > two message exchange for configuration. prefix and address assignment. The > goal of this proposal is to allow, under certain circumstances, a client to > complete its initial DHCPv6 transaction with two messages instead of the > current four messages, Solicit-Advertise-Request-Reply. The circumstances > under which this mechanism is designed to work are: only one server will > respond to the client Solicit; the server will commit the prefixes and > addresses to the client immediately. The proposed mechanism also allows a > client to indicate whether it is willing to participate in a two message > transaction, and allows a server to force a four message transaction > (according to local policy). > > Here's the proposal... > > A new TMT option (two message transaction) is defined. The TMT option can > only be included in a Solicit message. There is no data associated with > the TMT option. > > The client includes a TMT option in its Solicit message, indicating its > willingness to perform a two message transaction. > > If the server that receives a Solicit with a TMT option has a policy to > perform the two message transaction, it determines the client > configuration, commits the assignment of any prefixes or addresses, and > sends the configuration to the client in a Reply message. > > If the server that receives a Solicit with a TMT option does not have a > policy to perform the two message transaction, the server ignores the TMT > option and responds with an Advertise. > > If the client receives a Reply, it records the configuration and is done > (and may ignore any received Advertise messages). If the client receives > one or more Advertise messages but not Reply message, the client sends a > Request to continue the four message transaction. > > I intend to include this mechanism in the -24 rev of the DHCPv6 spec, which > I'm working on now. Comments welcome... > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Fri Apr 5 17:10:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01212 for ; Fri, 5 Apr 2002 17:10:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02749 for dhcwg-archive@odin.ietf.org; Fri, 5 Apr 2002 17:10:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02604; Fri, 5 Apr 2002 17:09:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02585 for ; Fri, 5 Apr 2002 17:09:38 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00852 for ; Fri, 5 Apr 2002 17:09:33 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g35M95q7015442; Fri, 5 Apr 2002 14:09:05 -0800 (PST) Date: Fri, 5 Apr 2002 17:09:05 -0500 (EST) From: Ralph Droms To: "Bernie Volz (EUD)" cc: dhcwg@ietf.org Subject: RE: [dhcwg] Reserved anycast address for DHCPv6 In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D1B8@EAMBUNT705> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Bernie - Can clients reliably differentiate between broadcast and NMBA links? - Ralph On Fri, 5 Apr 2002, Bernie Volz (EUD) wrote: > Ralph: > > >One potential problem is that clients now have two addresses. > > Is this really such a problem? If the client's interface is on a NBMA network, it uses the anycast address. If it is on a multicast capable network, it uses the Multicast address. So, yes, clients need to know about the two addresses but they only need to send packets to one. > > >Does anyone on the list know anything about the proposal for reserving a > >site-scoped SLA for anycast addresses? > > Have no idea. But, if we submit the request to IANA won't they do the address assignment and follow the rules? > > - Bernie > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Friday, April 05, 2002 2:40 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Reserved anycast address for DHCPv6 > > > includes the definition of three > anycast addresses for use by DNS resolvers: > > fec0:0:0:ffff::1 > fec0:0:0:ffff::2 > fec0:0:0:ffff::3 > > I had a request in Minneapolis that we consider defining an anycast address > for DHCPv6 that would allow the use of DHCPv6 on NBMA networks. Seems to > me like a reasonable suggestion. > > One potential problem is that clients now have two addresses: the > All_DHCP_Agents multicast address and the new anycast address. Which > should the client choose to use? > > BTW, the DNS Discovery draft includes the following: > > Note to readers: the above addresses are tentative, but the ffff > is intended to be consistent with a simultaneous proposal to > reserve the ffff SLA for use with IANA-assigned addresses such as > these. > > Does anyone on the list know anything about the proposal for reserving a > site-scoped SLA for anycast addresses? > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Fri Apr 5 17:21:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02506 for ; Fri, 5 Apr 2002 17:21:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03128 for dhcwg-archive@odin.ietf.org; Fri, 5 Apr 2002 17:22:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03048; Fri, 5 Apr 2002 17:20:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03022 for ; Fri, 5 Apr 2002 17:20:17 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02286 for ; Fri, 5 Apr 2002 17:20:12 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g35MKEl15655 for ; Fri, 5 Apr 2002 16:20:14 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g35MKEo11263 for ; Fri, 5 Apr 2002 16:20:14 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Fri Apr 05 16:20:13 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 16:20:13 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4D1BB@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Reserved anycast address for DHCPv6 Date: Fri, 5 Apr 2002 16:20:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCF0.0A54DCC0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DCF0.0A54DCC0 Content-Type: text/plain; charset="iso-8859-1" Ralph: I can't say for every kernel/stack, but for Unix (Solaris) there is the IOCTL call to read a flag that says whether the interface is broadcast/multicast capable. I think it is in the SIOCGIFFLAGS (Get interface flags) - one of the flag bits is true if broadcast capable. Also, on Solaris you generally see (via IFCONFIG) something like: e0:1: flags=2080841 mtu 1500 index 2 inet6 fec0::55:a00:20ff:fe8e:f3ad/64 le0:2: flags=2080841 mtu 1500 index 2 inet6 3ff0::55:a00:20ff:fe8e:f3ad/64 The MULTICAST flag is the one of interest. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Friday, April 05, 2002 5:09 PM To: Bernie Volz (EUD) Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Reserved anycast address for DHCPv6 Bernie - Can clients reliably differentiate between broadcast and NMBA links? - Ralph On Fri, 5 Apr 2002, Bernie Volz (EUD) wrote: > Ralph: > > >One potential problem is that clients now have two addresses. > > Is this really such a problem? If the client's interface is on a NBMA network, it uses the anycast address. If it is on a multicast capable network, it uses the Multicast address. So, yes, clients need to know about the two addresses but they only need to send packets to one. > > >Does anyone on the list know anything about the proposal for reserving a > >site-scoped SLA for anycast addresses? > > Have no idea. But, if we submit the request to IANA won't they do the address assignment and follow the rules? > > - Bernie > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Friday, April 05, 2002 2:40 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Reserved anycast address for DHCPv6 > > > includes the definition of three > anycast addresses for use by DNS resolvers: > > fec0:0:0:ffff::1 > fec0:0:0:ffff::2 > fec0:0:0:ffff::3 > > I had a request in Minneapolis that we consider defining an anycast address > for DHCPv6 that would allow the use of DHCPv6 on NBMA networks. Seems to > me like a reasonable suggestion. > > One potential problem is that clients now have two addresses: the > All_DHCP_Agents multicast address and the new anycast address. Which > should the client choose to use? > > BTW, the DNS Discovery draft includes the following: > > Note to readers: the above addresses are tentative, but the ffff > is intended to be consistent with a simultaneous proposal to > reserve the ffff SLA for use with IANA-assigned addresses such as > these. > > Does anyone on the list know anything about the proposal for reserving a > site-scoped SLA for anycast addresses? > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > ------_=_NextPart_001_01C1DCF0.0A54DCC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Reserved anycast address for DHCPv6

Ralph:

I can't say for every kernel/stack, but for Unix = (Solaris) there is the IOCTL call to read a flag that says whether the = interface is broadcast/multicast capable. I think it is in the = SIOCGIFFLAGS (Get interface flags) - one of the flag bits is true if = broadcast capable.

Also, on Solaris you generally see (via IFCONFIG) = something like:
e0:1: = flags=3D2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6>
          mtu = 1500 index 2
        inet6 = fec0::55:a00:20ff:fe8e:f3ad/64
le0:2: = flags=3D2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6>
          mtu = 1500 index 2
        inet6 = 3ff0::55:a00:20ff:fe8e:f3ad/64

The MULTICAST flag is the one of interest.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Friday, April 05, 2002 5:09 PM
To: Bernie Volz (EUD)
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] Reserved anycast address for = DHCPv6

Bernie - Can clients reliably differentiate between = broadcast and NMBA
links?

- Ralph

On Fri, 5 Apr 2002, Bernie Volz (EUD) wrote:

> Ralph:
>
> >One potential problem is that clients now = have two addresses.
>
> Is this really such a problem? If the client's = interface is on a NBMA network, it uses the anycast address. If it is = on a multicast capable network, it uses the Multicast address. So, yes, = clients need to know about the two addresses but they only need to send = packets to one.

>
> >Does anyone on the list know anything about = the proposal for reserving a
> >site-scoped SLA for anycast = addresses?
>
> Have no idea. But, if we submit the request to = IANA won't they do the address assignment and follow the rules?
>
> - Bernie
>
> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Friday, April 05, 2002 2:40 PM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Reserved anycast address for = DHCPv6
>
>
> <draft-ietf-ipv6-dns-discovery-04.txt> = includes the definition of three
> anycast addresses for use by DNS = resolvers:
>
>     fec0:0:0:ffff::1
>     fec0:0:0:ffff::2
>     fec0:0:0:ffff::3
>
> I had a request in Minneapolis that we consider = defining an anycast address
> for DHCPv6 that would allow the use of DHCPv6 = on NBMA networks. Seems to
> me like a reasonable suggestion.
>
> One potential problem is that clients now have = two addresses: the
> All_DHCP_Agents multicast address and the new = anycast address. Which
> should the client choose to use?
>
> BTW, the DNS Discovery draft includes the = following:
>
>    Note to readers: the above = addresses are tentative, but the ffff
>    is intended to be consistent = with a simultaneous proposal to
>    reserve the ffff SLA for use = with IANA-assigned addresses such as
>    these.
>
> Does anyone on the list know anything about the = proposal for reserving a
> site-scoped SLA for anycast addresses?
>
> - Ralph
>
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

------_=_NextPart_001_01C1DCF0.0A54DCC0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Fri Apr 5 17:45:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03883 for ; Fri, 5 Apr 2002 17:45:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04258 for dhcwg-archive@odin.ietf.org; Fri, 5 Apr 2002 17:45:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04148; Fri, 5 Apr 2002 17:43:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04119 for ; Fri, 5 Apr 2002 17:43:10 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03669 for ; Fri, 5 Apr 2002 17:43:05 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g35M4kl09111 for ; Fri, 5 Apr 2002 16:04:46 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g35M4ko04664 for ; Fri, 5 Apr 2002 16:04:46 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Fri Apr 05 16:04:45 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 16:04:45 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4D1BA@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Paul Tan'" , dhcwg@ietf.org Subject: RE: [dhcwg] Generic DHCPv6 Message Date: Fri, 5 Apr 2002 16:04:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCED.E46775B0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DCED.E46775B0 Content-Type: text/plain; charset="iso-8859-1" Paul: We certainly could have placed these into options. But, these two messages really do need some additional special processing so I'm not sure there would be much of an advantage. - Bernie -----Original Message----- From: Paul Tan [mailto:tanpaul@cwc.nus.edu.sg] Sent: Friday, April 05, 2002 4:31 AM To: dhcwg@ietf.org Subject: [dhcwg] Generic DHCPv6 Message Hi all, I am currently implementing DHCPv6 (draft 23) and have some questions regarding the DHCPv6 Relay Message. Question: Is it possible to have a generic DHCPv6 message structure for all (even the relayed messages) messages ? I must apologise if this issue has been rised previously. The idea is to have a common DHCP message for all message exchange. Since both the link-address and client-return-address are IPv6 addresses, we can carried these addresses as Options (e.g Address Option) in the DHCPv6 message. These options are placed in front of the rest of the options (e.g Client/Server Message Options) so that servers can discard any messages from the Relay if the servers decide not to reply based on the two addresses. The advantage is a preferred generic message structure for all DHCPv6 messages. This enables the processing of DHCPv6 message to be identical for both the server and relay (at least the encoding/decoding mechanism). Or is there any issues that I have overlook. I must apologize if my proposal sounds irrelevant. Please comment. Thank you, Paul ------_=_NextPart_001_01C1DCED.E46775B0 Content-Type: text/html; charset="iso-8859-1" DHCPv6 - server-address and unicast

Paul:

We certainly could have placed these into options. But, these two messages really do need some additional special processing so I'm not sure there would be much of an advantage.

- Bernie

-----Original Message-----
From: Paul Tan [mailto:tanpaul@cwc.nus.edu.sg]
Sent: Friday, April 05, 2002 4:31 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Generic DHCPv6 Message

Hi all,

I am currently implementing DHCPv6 (draft 23) and have some questions regarding the DHCPv6 Relay Message.

Question: Is it possible to have a generic DHCPv6 message structure for all (even the relayed messages) messages ? I must apologise if this issue has been rised previously.

The idea is to have a common DHCP message for all message exchange. Since both the link-address and client-return-address are IPv6 addresses, we can carried these addresses as Options (e.g Address Option) in the DHCPv6 message. These options are placed in front of the rest of the options (e.g Client/Server Message Options) so that servers can discard any messages from the Relay if the servers decide not to reply based on the two addresses.

The advantage is a preferred generic message structure for all DHCPv6 messages. This enables the processing of DHCPv6 message to be identical for both the server and relay (at least the encoding/decoding mechanism). Or is there any issues that I have overlook.

I must apologize if my proposal sounds irrelevant. Please comment.

Thank you,

Paul

------_=_NextPart_001_01C1DCED.E46775B0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Fri Apr 5 20:36:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16861 for ; Fri, 5 Apr 2002 20:36:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA11526 for dhcwg-archive@odin.ietf.org; Fri, 5 Apr 2002 20:36:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA11406; Fri, 5 Apr 2002 20:34:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA11383 for ; Fri, 5 Apr 2002 20:34:37 -0500 (EST) Received: from flounder.gibbons.com (sdsl-66-80-7-162.dsl.sca.megapath.net [66.80.7.162]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16811 for ; Fri, 5 Apr 2002 20:34:30 -0500 (EST) Received: from gibbons.com (sdsl-66-80-7-166.dsl.sca.megapath.net [66.80.7.166]) by flounder.gibbons.com (8.11.2/8.11.2) with ESMTP id g361YXa01998 for ; Fri, 5 Apr 2002 17:34:33 -0800 Message-ID: <3CAE5083.12DA547C@gibbons.com> Date: Fri, 05 Apr 2002 17:33:55 -0800 From: bao X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dhcp Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] dhcpd.conf Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit I have dhcp version 3.0.1 installed and am trying to configure dhcpd.conf When started, it complains that, "You must add a ddns-update-style statement to /etc/dhcpd.conf. To get the same behavior as in 3.0b2pl11 and previous version, add aline that says "ddns-update-style ad-hoc;" ..." I added that line in the global section, and it complains that "can't parse standard ddns updater!" What exactly does it want ?? The man page, as suggest by the daemon, reveals no answer Thanks _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Sat Apr 6 00:01:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24935 for ; Sat, 6 Apr 2002 00:01:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA20010 for dhcwg-archive@odin.ietf.org; Sat, 6 Apr 2002 00:01:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA19544; Fri, 5 Apr 2002 23:59:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA19466 for ; Fri, 5 Apr 2002 23:59:14 -0500 (EST) Received: from localhost ([211.49.130.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24875 for ; Fri, 5 Apr 2002 23:59:08 -0500 (EST) Message-Id: <200204060459.XAA24875@ietf.org> Reply-To: event@englishsoft.co.kr From: 잉글리쉬소프트 To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 6 Apr 2002 13:59:18 +0900 Subject: [dhcwg] [광고]CCFE 영어교제 원가구매 기회를 잡으세요(Commercial) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org

▒ 이 메일은 영어학습 프로그램관련 광고용메일 입니다. 발송전용 메일주소를 사용하였고 이메일주소 이외에 귀하에 대한 아무런 정보도 가지고 있지않습니다. 혹 불필요한 정보거나 기분이 상하신일이 있으시면 깊이 사과드립니다. 아래의 수신거부를 해주시면 다시는 보내는 일이 없을것입니다. ▒
▒ This mail is designed for a Commercial use to inform a special sales event. If you don't want this type of information, please write your mail address in the blank below. ▒

※ 메일 수신을 원하지 않을시
- 아래 입력란에 거부하실 메일주소를 입력하신후 수신거부 버튼을 눌러주세요
(If you don't want to receive this type of mail any more, write your mail address in and push the refuse button.)

※ 웹메일 경우, 위의 수신거부가 않될경우가 있습니다. 이경우 2차수신거부 를 통해 가능합니다.
(If you failed to send the refusal message to us by the process above, please push this link for the second chance.)

▶ 귀하의 승락 없이 홍보성 전자 우편을 보내게 된 점 정중히 사과 드립니다.
▶ 정보통신망이용촉진법 규정을 준수하여 광고 메일임을 표시하였으며,
수신 거부 장치를 필히 마련하고 있습니다.
▶ 귀하의 전자 우편 주소는 인터넷 상의 공개된 장소에서 습득하였으며,
귀하의전자우편 주소 외 어떠한 개인 정보도 가지고 있지 않으므로안심하시기 바랍니다.
▶ 번

거러우시겠지만 수신거부를 한번만 해주시면 귀하의 메일 주소를 DB에서 삭제 조치 하겠습니다.

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Sat Apr 6 18:26:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16858 for ; Sat, 6 Apr 2002 18:26:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08929 for dhcwg-archive@odin.ietf.org; Sat, 6 Apr 2002 18:26:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08657; Sat, 6 Apr 2002 18:16:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08638 for ; Sat, 6 Apr 2002 18:16:39 -0500 (EST) Received: from iloveuno.com ([211.108.87.93]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16724 for ; Sat, 6 Apr 2002 18:16:07 -0500 (EST) Message-Id: <200204062316.SAA16724@ietf.org> Reply-To: iloveuno@iloveuno.com From: 언어닷컴 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sun, 7 Apr 2002 08:14:11 +0900 Subject: [dhcwg] [정보] 수능 언어영역 완전정복. Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 아이러브 언어닷컴 개편 안내

아이러브언어 회원여러분~!!

모두 조오오오은 대학 가세요!
늘 아이러브언어를 아껴주셔서 감사합니다.
지난 해 수능 언어영역 방법은있다와 실전모의고사로 수험생 여러분에게 엽기적 인기를 끌었던 www.iloveuno.com이 새로 단장하고 서비스를 대폭 강화하여 회원님을 초대합니다.

1월, 2월, 5월, 7월,
연 4회에 걸쳐 회원님이 학습
해야 할 취약점을 컴퓨터로
즉시 꼭 집어 드립니다.

가입과 동시 4회분 모의고사로 자신의 취약점을 직접 체크해 보세요.

3월, 4월, 6월, 8월, 9월, 10월 연 6회에 걸친 최신 경향의
고난도 모의고사로 실전
적응력과 사고력를 Upgrade
하세요.

수능 언어영역의 모든 원리와 사고 방법을 문제 설문 유형별로 제시한 국내 최초의 책자
파일. 1997년 초판이래 매년 Update하여 세련되게 디자인한, 1,000권 이상의 책이 녹아 있는 무려 530여 페이지의 책자 파일을 무료로 다운로드하세요

한자 성어를 주제별로 배우고 퍼즐과 쓰기로 즐기며 익히는 어휘로 책자 파일을 무료로
다운 로드하세요.

1. 방법은있다로 풀이한 2002 수능문제로
회원님의 사고 방식을 점검하세요. 그 외에 모든 기출 수능 언어영역 문제를 다운로드
하세요.

2. 혼동하기 쉬운 고유어·한자어, 표준어·
맞춤법과 속담사전, 고유어 사전, 시사용어 사전 등등을 기초학습실에서 확인하세요.

	귀하의 전자 우편 주소는 인터넷 상의 공개된 장소에서 습득하여 귀하의 전자우편 주소 외 어떠한 개인정보도 가지고 있지 않으므로 안심하시기 바랍니다. 수신을 원치 않으시면 수신거부를 클릭해 주십시요.

기회는 스스로 잡는 사람에게 가는 법입니다.

때를 알아야 성공할 수 있습니다..

성공의 길을 제시하는 클럽..!!

생각의 변화가 귀하를 변화시킬 것입니다.

백만장자 클럽 (Ideal Space)

***** 백만장자 -Internetworking 카페 *****

귀하의 메일주소는 웹 서핑 중 알게 된 것이며, E-Mail 주소 외에, 다른 정보는 갖고 있지 않습니다.
정통부 권고사항에 의거 제목에 [광고] 표기한 메일입니다. 원치 않으면 [수신거부]를 눌러주세요

http://www.sohomart.org
본 E-mail은 정보통신부 권고안에 따라 공개된 게시판 등에서 획득했으며
수신자께서 수신거부 의사를 밝힌 후에는 다시 보내지 않겠습니다.

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Sun Apr 7 22:49:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05597 for ; Sun, 7 Apr 2002 22:49:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA21794 for dhcwg-archive@odin.ietf.org; Sun, 7 Apr 2002 22:49:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21607; Sun, 7 Apr 2002 22:46:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21585 for ; Sun, 7 Apr 2002 22:46:28 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cm058.254.234.24.lvcm.com [24.234.254.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05513 for ; Sun, 7 Apr 2002 22:46:23 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g382dWS01586; Sun, 7 Apr 2002 19:39:32 -0700 Message-Id: <200204080239.g382dWS01586@cichlid.adsl.duke.edu> To: vijayak@india.hp.com cc: dhcwg@ietf.org Subject: Re: FW: [dhcwg] co-existence of temp and normal addresses In-Reply-To: Message from "Vijayabhaskar A K" of "Thu, 04 Apr 2002 15:27:52 +0530." <00c101c1dbbf$30182610$2f290a0f@india.hp.com> Date: Sun, 07 Apr 2002 19:39:32 -0700 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi Vijay. I agree that you've raised a valid issue. > - Why can't we have separate IAs for normal and temporary addresses? Mixing temporary and non-temporary addresses in the same IA seems like it may create some problems. I suspect that NOT mixing them together within the same IA will simplify some things. I'll have to think a bit more about the rest of your proposal. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Sun Apr 7 23:40:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06422 for ; Sun, 7 Apr 2002 23:40:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA24196 for dhcwg-archive@odin.ietf.org; Sun, 7 Apr 2002 23:40:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24083; Sun, 7 Apr 2002 23:36:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24058 for ; Sun, 7 Apr 2002 23:36:00 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06338 for ; Sun, 7 Apr 2002 23:35:57 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g383a0l01180 for ; Sun, 7 Apr 2002 22:36:00 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g383a0Z11336 for ; Sun, 7 Apr 2002 22:36:00 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Sun Apr 07 22:35:59 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 7 Apr 2002 22:35:59 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D1CA@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , vijayak@india.hp.com Cc: dhcwg@ietf.org Subject: RE: FW: [dhcwg] co-existence of temp and normal addresses Date: Sun, 7 Apr 2002 22:35:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DEAE.7F0B7E60" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DEAE.7F0B7E60 Content-Type: text/plain; charset="iso-8859-1" Thomas/Vijay: We did discuss this for a long time in designing the current DHCPv6 draft. It really would have been useful if the IPv6 community has a means to classify the 'type' of an address. This would be useful for applications when they want to "find" a specific address. Anyway, if we had such a thing, we would have revised the IA Option to carry it. Though I hate to do it because it reopens the discussions, if we consider anything we shouldn't add more IA types. Instead, we should redesign the IA option slightly and add a type field. The type field (8 bit?) could have the following values: 0 - "Normal" addresses 1 - "Temporary" addresses 2 - "DSTM" addresses (this replaces the DSTM option) ... - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Sunday, April 07, 2002 10:40 PM To: vijayak@india.hp.com Cc: dhcwg@ietf.org Subject: Re: FW: [dhcwg] co-existence of temp and normal addresses Hi Vijay. I agree that you've raised a valid issue. > - Why can't we have separate IAs for normal and temporary addresses? Mixing temporary and non-temporary addresses in the same IA seems like it may create some problems. I suspect that NOT mixing them together within the same IA will simplify some things. I'll have to think a bit more about the rest of your proposal. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1DEAE.7F0B7E60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: [dhcwg] co-existence of temp and normal addresses =

Thomas/Vijay:

We did discuss this for a long time in designing the = current DHCPv6 draft.

It really would have been useful if the IPv6 = community has a means to classify the 'type' of an address. This would = be useful for applications when they want to "find" a = specific address.

Anyway, if we had such a thing, we would have revised = the IA Option to carry it.

Though I hate to do it because it reopens the = discussions, if we consider anything we shouldn't add more IA types. = Instead, we should redesign the IA option slightly and add a type = field. The type field (8 bit?) could have the following = values:

        0       = -       "Normal" = addresses
        1       = -       "Temporary" = addresses
        2       = -       "DSTM" addresses (this = replaces the DSTM option)
        ...

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Sunday, April 07, 2002 10:40 PM
To: vijayak@india.hp.com
Cc: dhcwg@ietf.org
Subject: Re: FW: [dhcwg] co-existence of temp and = normal addresses

Hi Vijay.

I agree that you've raised a valid issue.

> - Why can't we have separate IAs for normal and = temporary addresses?

Mixing temporary and non-temporary addresses in the = same IA seems like
it may create some problems. I suspect that NOT = mixing them together
within the same IA will simplify some things. I'll = have to think a bit
more about the rest of your proposal.

Thomas

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

------_=_NextPart_001_01C1DEAE.7F0B7E60-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Mon Apr 8 03:17:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16710 for ; Mon, 8 Apr 2002 03:17:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA14688 for dhcwg-archive@odin.ietf.org; Mon, 8 Apr 2002 03:17:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14547; Mon, 8 Apr 2002 03:15:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14507 for ; Mon, 8 Apr 2002 03:15:13 -0400 (EDT) Received: from smtp.pgsworld.com ([202.56.255.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16666; Mon, 8 Apr 2002 03:15:06 -0400 (EDT) From: manmatd@pgsolutions.com Subject: Re: [dhcwg] Two message transaction in DHCPv6 Cc: dhcwg@ietf.org, dhcwg-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: Date: Mon, 8 Apr 2002 12:39:28 +0530 X-MIMETrack: Serialize by Router on PGSSMTP01/smtp/IN(Release 5.0.7 |March 21, 2001) at 04/08/2002 12:45:12 PM MIME-Version: 1.0 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Mon Apr 8 09:28:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23002 for ; Mon, 8 Apr 2002 09:28:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04186 for dhcwg-archive@odin.ietf.org; Mon, 8 Apr 2002 09:28:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03307; Mon, 8 Apr 2002 09:16:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03283 for ; Mon, 8 Apr 2002 09:16:28 -0400 (EDT) Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22525 for ; Mon, 8 Apr 2002 09:16:26 -0400 (EDT) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by atlrel6.hp.com (Postfix) with ESMTP id 2204D55A; Mon, 8 Apr 2002 09:15:49 -0400 (EDT) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by hpuxsrv.india.hp.com with SMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id SAA01945; Mon, 8 Apr 2002 18:40:45 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Bernie Volz (EUD)'" , "'Thomas Narten'" Cc: Subject: RE: FW: [dhcwg] co-existence of temp and normal addresses Date: Mon, 8 Apr 2002 18:47:07 +0530 Message-ID: <005001c1deff$afa88c10$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01C1DF2D.C960C810" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D1CA@EAMBUNT705> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0051_01C1DF2D.C960C810 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit RE: FW: [dhcwg] co-existence of temp and normal addressesThis idea is ok. But, we need two types of IA options : Renwable IA and Non-Renewable IA, because, T1 and T2 fields doesn't make sense, if IA contain temporary addresses. ~vijay -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Monday, April 08, 2002 9:06 AM To: 'Thomas Narten'; vijayak@india.hp.com Cc: dhcwg@ietf.org Subject: RE: FW: [dhcwg] co-existence of temp and normal addresses Thomas/Vijay: We did discuss this for a long time in designing the current DHCPv6 draft. It really would have been useful if the IPv6 community has a means to classify the 'type' of an address. This would be useful for applications when they want to "find" a specific address. Anyway, if we had such a thing, we would have revised the IA Option to carry it. Though I hate to do it because it reopens the discussions, if we consider anything we shouldn't add more IA types. Instead, we should redesign the IA option slightly and add a type field. The type field (8 bit?) could have the following values: 0 - "Normal" addresses 1 - "Temporary" addresses 2 - "DSTM" addresses (this replaces the DSTM option) ... - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Sunday, April 07, 2002 10:40 PM To: vijayak@india.hp.com Cc: dhcwg@ietf.org Subject: Re: FW: [dhcwg] co-existence of temp and normal addresses Hi Vijay. I agree that you've raised a valid issue. > - Why can't we have separate IAs for normal and temporary addresses? Mixing temporary and non-temporary addresses in the same IA seems like it may create some problems. I suspect that NOT mixing them together within the same IA will simplify some things. I'll have to think a bit more about the rest of your proposal. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------=_NextPart_000_0051_01C1DF2D.C960C810 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RE: FW: [dhcwg] co-existence of temp and normal addresses

This=20 idea is ok.

But,=20 we need two types of IA options : Renwable IA and Non-Renewable=20 IA,

because, T1 and T2 fields doesn't make sense, if IA contain = temporary=20

addresses.

~vijay

-----Original Message-----
From: Bernie Volz (EUD)=20 [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Monday, April 08, = 2002=20 9:06 AM
To: 'Thomas Narten'; = vijayak@india.hp.com
Cc:=20 dhcwg@ietf.org
Subject: RE: FW: [dhcwg] co-existence of temp = and=20 normal addresses

Thomas/Vijay:

We did discuss this for a long time in designing the = current=20 DHCPv6 draft.

It really would have been useful if the IPv6 = community has a=20 means to classify the 'type' of an address. This would be useful for=20 applications when they want to "find" a specific address.

Anyway, if we had such a thing, we would have = revised the IA=20 Option to carry it.

Though I hate to do it because it reopens the = discussions, if=20 we consider anything we shouldn't add more IA types. Instead, we = should=20 redesign the IA option slightly and add a type field. The type field = (8 bit?)=20 could have the following values:

        0      =20 -       "Normal" addresses=20
        1      =20 -       "Temporary" addresses=20
        2      =20 -       "DSTM" addresses (this replaces = the DSTM=20 option)
        ...

- Bernie

-----Original Message-----
From:=20 Thomas Narten [mailto:narten@us.ibm.com] =
Sent: Sunday, April 07, 2002 10:40 PM
To:=20 vijayak@india.hp.com
Cc: = dhcwg@ietf.org=20
Subject: Re: FW: [dhcwg] co-existence of temp and = normal=20 addresses

Hi Vijay.

I agree that you've raised a valid issue. =

> - Why can't we have separate IAs for normal and = temporary=20 addresses?

Mixing temporary and non-temporary addresses in the = same IA=20 seems like
it may create some problems. I = suspect that=20 NOT mixing them together
within the same IA = will=20 simplify some things. I'll have to think a bit
more=20 about the rest of your proposal.

Thomas

_______________________________________________=20
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/dhcwg=20

------=_NextPart_000_0051_01C1DF2D.C960C810-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Mon Apr 8 09:32:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23071 for ; Mon, 8 Apr 2002 09:32:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04784 for dhcwg-archive@odin.ietf.org; Mon, 8 Apr 2002 09:32:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03935; Mon, 8 Apr 2002 09:24:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03909 for ; Mon, 8 Apr 2002 09:24:17 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22856 for ; Mon, 8 Apr 2002 09:24:14 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g38DNki00854 for ; Mon, 8 Apr 2002 08:23:46 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g38DNji12013 for ; Mon, 8 Apr 2002 08:23:46 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Mon Apr 08 08:23:44 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 08:23:44 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D1CE@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" , "Bernie Volz (EUD)" , "'Thomas Narten'" Cc: dhcwg@ietf.org Subject: RE: FW: [dhcwg] co-existence of temp and normal addresses Date: Mon, 8 Apr 2002 08:23:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF00.98F45CF0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF00.98F45CF0 Content-Type: text/plain; charset="iso-8859-1" T1/T2 can simply be set to 0 or FFFFFFFF (T1/T2 are supposed to be set by the server in all cases, so using either of these values could easily mean no renewal or don't renew until 2^32-1 seconds have elapsed). No need for another option. Saving the 8 bytes for these two fields isn't worth it, IMHO. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Monday, April 08, 2002 9:17 AM To: 'Bernie Volz (EUD)'; 'Thomas Narten' Cc: dhcwg@ietf.org Subject: RE: FW: [dhcwg] co-existence of temp and normal addresses This idea is ok. But, we need two types of IA options : Renwable IA and Non-Renewable IA, because, T1 and T2 fields doesn't make sense, if IA contain temporary addresses. ~vijay -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Monday, April 08, 2002 9:06 AM To: 'Thomas Narten'; vijayak@india.hp.com Cc: dhcwg@ietf.org Subject: RE: FW: [dhcwg] co-existence of temp and normal addresses Thomas/Vijay: We did discuss this for a long time in designing the current DHCPv6 draft. It really would have been useful if the IPv6 community has a means to classify the 'type' of an address. This would be useful for applications when they want to "find" a specific address. Anyway, if we had such a thing, we would have revised the IA Option to carry it. Though I hate to do it because it reopens the discussions, if we consider anything we shouldn't add more IA types. Instead, we should redesign the IA option slightly and add a type field. The type field (8 bit?) could have the following values: 0 - "Normal" addresses 1 - "Temporary" addresses 2 - "DSTM" addresses (this replaces the DSTM option) ... - Bernie -----Original Message----- From: Thomas Narten [ mailto:narten@us.ibm.com ] Sent: Sunday, April 07, 2002 10:40 PM To: vijayak@india.hp.com Cc: dhcwg@ietf.org Subject: Re: FW: [dhcwg] co-existence of temp and normal addresses Hi Vijay. I agree that you've raised a valid issue. > - Why can't we have separate IAs for normal and temporary addresses? Mixing temporary and non-temporary addresses in the same IA seems like it may create some problems. I suspect that NOT mixing them together within the same IA will simplify some things. I'll have to think a bit more about the rest of your proposal. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1DF00.98F45CF0 Content-Type: text/html; charset="iso-8859-1" RE: FW: [dhcwg] co-existence of temp and normal addresses

T1/T2 can simply be set to 0 or FFFFFFFF (T1/T2 are supposed to be set by the server in all cases, so using either of these values could easily mean no renewal or don't renew until 2^32-1 seconds have elapsed). No need for another option. Saving the 8 bytes for these two fields isn't worth it, IMHO.

- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Monday, April 08, 2002 9:17 AM
To: 'Bernie Volz (EUD)'; 'Thomas Narten'
Cc: dhcwg@ietf.org
Subject: RE: FW: [dhcwg] co-existence of temp and normal addresses

This idea is ok.

But, we need two types of IA options : Renwable IA and Non-Renewable IA,

because, T1 and T2 fields doesn't make sense, if IA contain temporary

addresses.

~vijay

-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Monday, April 08, 2002 9:06 AM
To: 'Thomas Narten'; vijayak@india.hp.com
Cc: dhcwg@ietf.org
Subject: RE: FW: [dhcwg] co-existence of temp and normal addresses

Thomas/Vijay:

We did discuss this for a long time in designing the current DHCPv6 draft.

It really would have been useful if the IPv6 community has a means to classify the 'type' of an address. This would be useful for applications when they want to "find" a specific address.

Anyway, if we had such a thing, we would have revised the IA Option to carry it.

Though I hate to do it because it reopens the discussions, if we consider anything we shouldn't add more IA types. Instead, we should redesign the IA option slightly and add a type field. The type field (8 bit?) could have the following values:

        0       -       "Normal" addresses
        1       -       "Temporary" addresses
        2       -       "DSTM" addresses (this replaces the DSTM option)
        ...

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Sunday, April 07, 2002 10:40 PM
To: vijayak@india.hp.com
Cc: dhcwg@ietf.org
Subject: Re: FW: [dhcwg] co-existence of temp and normal addresses

Hi Vijay.

I agree that you've raised a valid issue.

> - Why can't we have separate IAs for normal and temporary addresses?

Mixing temporary and non-temporary addresses in the same IA seems like
it may create some problems. I suspect that NOT mixing them together
within the same IA will simplify some things. I'll have to think a bit
more about the rest of your proposal.

Thomas

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

------_=_NextPart_001_01C1DF00.98F45CF0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Mon Apr 8 10:38:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25396 for ; Mon, 8 Apr 2002 10:38:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA10462 for dhcwg-archive@odin.ietf.org; Mon, 8 Apr 2002 10:38:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08840; Mon, 8 Apr 2002 10:23:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08760 for ; Mon, 8 Apr 2002 10:23:39 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24846 for ; Mon, 8 Apr 2002 10:23:36 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g38ENdl11646 for ; Mon, 8 Apr 2002 09:23:39 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g38ENcp21787 for ; Mon, 8 Apr 2002 09:23:39 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Apr 08 09:23:38 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 09:23:38 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D1D4@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" Cc: vijayak@india.hp.com, dhcwg@ietf.org Subject: RE: FW: [dhcwg] co-existence of temp and normal addresses Date: Mon, 8 Apr 2002 09:23:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF08.F8D007C0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF08.F8D007C0 Content-Type: text/plain; charset="iso-8859-1" The only problem with this typing is that it presumes the client always knows what to ask for. In the cases we have today, that appears to be appropriate. However, it is not clear that this would be the case down the road depending on how "type" is defined. For example, one might ask whether we should split the "normal" case in two and have "normal-global" and "normal-site". Or, might we have three types - "normal", "normal-global", and "normal-site". Or, should we use bits to indicate what address types are desired/allowed for the particular IA (hence an IA could ask for normal-global, normal-site, DSTM, and/or temporary). Note that I do like the idea of the types since it could easily be extended to do prefix delegation, multicast address assignments, etc. However, we have to be careful in how the types are assigned to avoid the problems above. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Monday, April 08, 2002 10:08 AM To: Bernie Volz (EUD) Cc: vijayak@india.hp.com; dhcwg@ietf.org Subject: Re: FW: [dhcwg] co-existence of temp and normal addresses > Though I hate to do it because it reopens the discussions, if we > consider anything we shouldn't add more IA types. Instead, we should > redesign the IA option slightly and add a type field. The type field > (8 bit?) could have the following values: > 0 - "Normal" addresses > 1 - "Temporary" addresses I think these two may make sense. The reason is that temporary addresses are different than other addresses in *how* the client uses them. A client may want to use several at a time, or just one. It may want to extend the lease of one particular one (if the application continues to use it), etc. That is, temporary addresses really do have the potential for being used in application-specific manners. As an example (not that I necessarily agree with it), when temporary addresses were designed in the IPNg WG, there were some people that thought it should be possible to have a new address created whenever a new application started. Allowing the client to ask for "yet another new temporary address" (as opposed to "give me the temporary addresses I'm supposed to have")) would support this. > 2 - "DSTM" addresses (this replaces the DSTM option) > ... I can see the benfit here. Having a type makes sense in cases where identifying the type of address (i.e, how it will be used) is necessary to decide how to allocate and use it. Thomas ------_=_NextPart_001_01C1DF08.F8D007C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: [dhcwg] co-existence of temp and normal addresses =

The only problem with this typing is that it presumes = the client always knows what to ask for. In the cases we have today, = that appears to be appropriate. However, it is not clear that this = would be the case down the road depending on how "type" is = defined. For example, one might ask whether we should split the = "normal" case in two and have "normal-global" and = "normal-site". Or, might we have three types - = "normal", "normal-global", and = "normal-site". Or, should we use bits to indicate what = address types are desired/allowed for the particular IA (hence an IA = could ask for normal-global, normal-site, DSTM, and/or = temporary).

Note that I do like the idea of the types since it = could easily be extended to do prefix delegation, multicast address = assignments, etc. However, we have to be careful in how the types are = assigned to avoid the problems above.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Monday, April 08, 2002 10:08 AM
To: Bernie Volz (EUD)
Cc: vijayak@india.hp.com; dhcwg@ietf.org
Subject: Re: FW: [dhcwg] co-existence of temp and = normal addresses

> Though I hate to do it because it reopens the = discussions, if we
> consider anything we shouldn't add more IA = types. Instead, we should
> redesign the IA option slightly and add a type = field. The type field
> (8 bit?) could have the following = values:

> = 0 = - "Normal" = addresses
> = 1 = - "Temporary" = addresses

I think these two may make sense. The reason is that = temporary
addresses are different than other addresses in = *how* the client uses
them. A client may want to use several at a time, or = just one. It may
want to extend the lease of one particular one (if = the application
continues to use it), etc. That is, temporary = addresses really do
have the potential for being used in = application-specific manners. As
an example (not that I necessarily agree with it), = when temporary
addresses were designed in the IPNg WG, there were = some people that
thought it should be possible to have a new address = created whenever a
new application started. Allowing the client to ask = for "yet another
new temporary address" (as opposed to = "give me the temporary addresses
I'm supposed to have")) would support = this.

> = 2 = - "DSTM" addresses (this = replaces the DSTM option)
> ...

I can see the benfit here. Having a type makes sense = in cases where
identifying the type of address (i.e, how it will be = used) is
necessary to decide how to allocate and use = it.

Thomas

------_=_NextPart_001_01C1DF08.F8D007C0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Mon Apr 8 13:16:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00228 for ; Mon, 8 Apr 2002 13:16:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22890 for dhcwg-archive@odin.ietf.org; Mon, 8 Apr 2002 13:16:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21361; Mon, 8 Apr 2002 12:50:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21329 for ; Mon, 8 Apr 2002 12:50:29 -0400 (EDT) Received: from ------ ([61.174.192.89]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29619 for ; Mon, 8 Apr 2002 12:50:23 -0400 (EDT) Message-Id: <200204081650.MAA29619@ietf.org> From: "eyou321" To: dhcwg@ietf.org Content-Type: text/html; charset="us-ascii" Date: Tue, 9 Apr 2002 00:36:37 +0800 X-Priority: 3 X-Mailer: jpfree Group Mail Express V1.0 Subject: [dhcwg] ADV:Harvest lots of Target Email address quickly Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org

Want To Get A Lot Of Target Email Addresses In A Very Short Time?

Target Email Extractor is a powerful Email Software that harvests Target Email Addresses from search engines, any specified starting URLs , including cgi , asp pages etc.

It Quickly and automatically search and spider from search engine, any specified starting URLs to find and extract e-mail addresses

Powerful targeting ability. Only extract the specific email addresses that directly related to your business.

Integrated with 18 top popular search engines: Yahoo, Google, MSN, AOL

Fast Search Ability. Nearly can find thousands of e-mail addresses in an hour, allowing up to 500 simultaneous search threads!

Helpful for anyone for internet Email marketing purposes.

Free version updates.

Click The Following Link To Download This Program:

Download Site 1

Download Site 2 　If you can not download this program , please copy the following link into your URL , and then click " Enter" on your Computer Keyboard.

Here is the download links:

http://www.wldinfo.com/download/email/ESE.zip

http://bestsoft.3322.org/onlinedown/ESE.zip

Disclaimer:
We are strongly against continuously sending unsolicited emails to those who do not wish to receive our special mailings. We have attained the services of an independent 3rd party to overlook list management and removal services. This is not unsolicited email. If you do not wish to receive further mailings, please click this link http://www.autoemailremoval.com/cgi-bin/remove.pl . Auto Email Removal Company. Ref# 01222263545
This message is a commercial advertisement. It is compliant with all federal and state laws regarding email messages including the California Business and Professions Code. We have provided the subject line "ADV" to provide you notification that this is a commercial advertisement for persons over 18yrs old.

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Mon Apr 8 14:37:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02176 for ; Mon, 8 Apr 2002 14:37:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA28712 for dhcwg-archive@odin.ietf.org; Mon, 8 Apr 2002 14:37:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24995; Mon, 8 Apr 2002 13:53:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24973 for ; Mon, 8 Apr 2002 13:53:56 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cm058.254.234.24.lvcm.com [24.234.254.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01166 for ; Mon, 8 Apr 2002 13:53:53 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g38E7vq05345; Mon, 8 Apr 2002 07:07:57 -0700 Message-Id: <200204081407.g38E7vq05345@cichlid.adsl.duke.edu> To: "Bernie Volz (EUD)" cc: vijayak@india.hp.com, dhcwg@ietf.org Subject: Re: FW: [dhcwg] co-existence of temp and normal addresses In-Reply-To: Message from "Bernie Volz (EUD)" of "Sun, 07 Apr 2002 22:35:58 CDT." <66F66129A77AD411B76200508B65AC69B4D1CA@EAMBUNT705> Date: Mon, 08 Apr 2002 07:07:57 -0700 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Though I hate to do it because it reopens the discussions, if we > consider anything we shouldn't add more IA types. Instead, we should > redesign the IA option slightly and add a type field. The type field > (8 bit?) could have the following values: > 0 - "Normal" addresses > 1 - "Temporary" addresses I think these two may make sense. The reason is that temporary addresses are different than other addresses in *how* the client uses them. A client may want to use several at a time, or just one. It may want to extend the lease of one particular one (if the application continues to use it), etc. That is, temporary addresses really do have the potential for being used in application-specific manners. As an example (not that I necessarily agree with it), when temporary addresses were designed in the IPNg WG, there were some people that thought it should be possible to have a new address created whenever a new application started. Allowing the client to ask for "yet another new temporary address" (as opposed to "give me the temporary addresses I'm supposed to have")) would support this. > 2 - "DSTM" addresses (this replaces the DSTM option) > ... I can see the benfit here. Having a type makes sense in cases where identifying the type of address (i.e, how it will be used) is necessary to decide how to allocate and use it. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Apr 9 05:08:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29949 for ; Tue, 9 Apr 2002 05:08:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA02970 for dhcwg-archive@odin.ietf.org; Tue, 9 Apr 2002 05:08:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02067; Tue, 9 Apr 2002 04:58:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01994 for ; Tue, 9 Apr 2002 04:58:48 -0400 (EDT) Received: from okjoonggae.com ([218.145.206.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29810 for ; Tue, 9 Apr 2002 04:58:27 -0400 (EDT) Message-Id: <200204090858.EAA29810@ietf.org> Reply-To: dear@okjoonggae.com From: 오케이중개닷컴 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 9 Apr 2002 17:43:00 +0900 Subject: [dhcwg] [廣告]부동산직거래 매물등록 완전무료 싸이트 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org [廣告]부동산직거래 매물등록 완전무료 싸이트

인터넷 주소(D)

인터넷 키워드

부동산직거래

부동산 홈페이지 오케이중개닷컴을 소개합니다.

☞ 부동산의 일반상식과 매물정보를 주고 받을 수 있는 알찬 홈페이지 !

▷부동산을 처분( 매매/임대/교환 ) 또는 취득( 매수/임차 )하고자 하는 모든분을 대상으로 합니다

▷부동산 매물을 등록 하고 검색가능케 하는 홈페이지로서 회원가입과 전혀 무관합니다.

▷부동산 매물을 종류별,유형별로 상세히 등록/검색할 수 있습니다

▷기존의 게시판식 공짜 매물등록과 매물 유형도 몇 개 되지 않는 홈페이지와는 차원이 다름니다.

▷"주택임대차보호법" , "세무법률" , "분양정보" "인테리어"기타 필요한 정보를 제공합니다.

▷현업 부동산 전문가가 직접운영하며 정보이용 및 사용료는 완전무료.

오케이중개닷컴을 이렇게 활용하시면 유용합니다.

중개구분	설명	성격	특징	비고
▷직거래	중개업자를 배제한 소비자간 직접거래	중개수수료를 배제한 소비자 직거래	입력한 정보 모두 공개	부동산 거래사고 각별한주의요망.
▷공동중개	타중개업자가 자기의 매물을 홍보할 목적으로 함	중개업자의 매물을 공동중개 활성화를 위함	입력한 정보 모두 공개	공동중개 원치 않을시 설명란에 기재요.
▷중개의뢰	의뢰인이 오케이중개닷컴에 일반중개 의뢰	구속력 없으며 다른 중개업자에게 중개해도 무관함	동·호수/지번/ 이름/연락처 비공개	보통의 중개의뢰방식, 공동중개가능.
▷전속중개의뢰	의뢰인이 오케이중개닷컴에 전속으로 중개의뢰	약정한 기간동안 오케이중개닷컴만이 중개권한있음	동·호수/지번/ 이름/연락처 비공개	신속하고 안전한 중개의뢰방식, 공동중개가능.

인터넷 사이트는 이랬으면 좋겠습니다.

☞ 유용한 사이트는 서로 홍보하고 많은 대중에게 널리 알려져야 합니다.

▷인터넷은 공유의 정보가 필요합니다.	▷전문성을 갖추되 신뢰할 수 있어야 하며,
▷누구나 이용할 수 있어야 합니다.	▷사용자는 공중도덕을 지킬 줄 알아야 합니다.
▷대중에게 유익한 정보를 제공해야 합니다.	▷좋은정보의 무료 싸이트가 많아야 합니다.

■ 본 메일은 정통부 권고사항에 의거 제목에 [광고]라고 표기한 메일입니다.
■ 귀하의 메일주소는 웹써핑중에 알게 된 것이며, e_mail 외에 다른정보는 갖고 있지 않습니다.
■ 이메일은 발신전용 메일입니다.
■ 수신을 원치 않으실 경우 아래버튼을 클릭해 주세요.

오케이중개닷컴│서울특별시 강남구 삼성동 150-21, 2F [135-878]
문의사항 : dear@okjoonggae.com │상담문의 ☎ : (02) 552- 8484

현대 / 기아 자동차 정비 5%할인
현대 MOBIS 자동차 경품 10%할인
현대차사랑플랜 가입비 10%할인
오토에버닷컴 중고차경매 출품비 50%할인
미래카, 만도플라자 자동차 보험가입시 혜택서비스

기아렌터카 / 금호렌터카 : 상시20%할인
드림랜터카 : 성수기20% 비수기 40%할인
호텔, 콘도 10~40%할인(호텔현대/대전 유성호텔/현대설악콘도미니엄/부산메리어트호텔/롯데호텔제주)
골프잡지/용품 및 클럽(골프다이제스트, 윌슨코리아)20%할인
스포츠관람 할인 - 전북현대모터스 축구단 / 기아타이거스 야구단 홈경기 일반석 입장권
일품 여행사 - 여행상품5%할인, 해외항공권4%할인, 해외패키지상품이용시 10만원 상당 사은품 제공
펙터스(Pactus)코리아 - 골프화 30%할인

한샘인텔리전트 키친 - 가구철거비 및 시공비 무료, 판매가 10%상당의 사은품 제공
한국의학연구소(KMI) - 종합검진료 40%할인
화장품 랜드21 - 전국 250여개의 매장에서 5%할인
스마트 플라워 - 꽃배달 주문시 10%할인
행복을 나르는 사람 - 포장이사 서비스 및 창고보관 할인
마로니에 웨딩클럽 - 웨딩페키지 및 혼수상품 할인
디즈샵 - 컴퓨터 전문 쇼핑몰, 최고 20%할인
동아씨씨닷컴 - 동아일보 사이버 문화센터 온라인 강좌 할인
파파이사 - 포장이사 및 사무실 이전 할인
베이비시터 코리아 - 베이비시터 회원가입비 10%할인

지금 드림론 카드를 신청하시는 회원에게는 에이스아메리칸 화재해상보험㈜ 의 "강도상해보험'(최고3,000만원 보상)을 ㈜비아이코리아 에서 무료로 카드 신청 회원에게(25세~55세) 무료로 가입해 드립니다.

본 메일은 정보통신부 권고사항에 의거,제목에 [광고]란이 표시된 메일입니다.
허락없이 광고메일을 보내드려 죄송하며,정중히 양해 바랍니다.
또한 귀하의 이메일 주소는 게시판이나 동호회등의 공개된 메일주소를 수집한 것 으로 기타 다른 개인 정보는 없음을 알려드리며 수신거부를 원하실 경우 아래의 e-mail주소를 적어주시고 수신거부 버튼을 클릭하여 주시기 바랍니다.

자동으로 수신거부 되지 않으면 여기를 누르세요....

Kinh gui Friend!

Th�nh lập doanh nghiệp

Với sự ra đời v� c� hiệu lực của Luật Doanh nghiệp từ ng�y 01 th�ng 01 năm 2000, sự chuyển đổi của c�c tổ chức, c� nh�n đăng k� kinh doanh sang c�c loại h�nh c�ng ty đ� đem lại hiệu quả kinh doanh v� lợi �ch cao hơn nhiều.

Đăng k� nh�n hiệu

Thương hiệu ng�y nay c�ng ng�y c�ng chiếm gi� trị cao trong c�c sản phẩm của c�c doanh nghiệp. V� vậy nhu cầu bảo vệ gi� trị của c�c nh�n hiệu n�y khỏi sự x�m phạm đ� c�ng trở n�n quan trọng.

Đăng k� m� số m� vạch

Doanh nghiệp của bạn đ� v� đang sản xuất những mặt h�ng c� chất lưọng cao, được thị trường chấp nhận, v� bạn muốn được cấp một "căn cước" cho h�ng ho� của m�nh dễ d�ng v�o c�c si�u thị ...

Sản phẩm của bạn đ� c� dấu hiệu n�y chưa?

Bản quyền t�c giả

Đăng k� sở hữu bản quyền t�c giả c�c t�c phẩm nghệ thuật, văn học, khoa học, phần mềm m�y t�nh!

Cơ hội nghề nghiệp

Bạn c� tham vọng?

Bạn diễn thuyết rất tốt?

Bạn c� tuổi trẻ?

V� bạn đ� v� đang theo học Luật hoặc Kinh tế?

Ch�ng t�i cần c�c bạn cho sự ph�t triển!

Copyright (C) 2001-2002 by PHAM JURIST COMPANY LIMITED
Add: 240 Quan Nhan, Thanh Xuan, Hanoi, Vietnam.
Tel: 84-4-55 838 55 091.3553.222 email: luat@fpt.vn

Neu ban khong muon nhan tin nua, hay gui thu cho: unsubcribe@giapham.com

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Apr 9 13:42:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13750 for ; Tue, 9 Apr 2002 13:42:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA07412 for dhcwg-archive@odin.ietf.org; Tue, 9 Apr 2002 13:42:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07012; Tue, 9 Apr 2002 13:34:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06984 for ; Tue, 9 Apr 2002 13:34:42 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cm058.254.234.24.lvcm.com [24.234.254.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13267 for ; Tue, 9 Apr 2002 13:34:40 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g39HTmI01940; Tue, 9 Apr 2002 10:29:48 -0700 Message-Id: <200204091729.g39HTmI01940@cichlid.adsl.duke.edu> To: "Bernie Volz (EUD)" cc: vijayak@india.hp.com, dhcwg@ietf.org Subject: Re: FW: [dhcwg] co-existence of temp and normal addresses In-Reply-To: Message from "Bernie Volz (EUD)" of "Mon, 08 Apr 2002 09:23:37 CDT." <66F66129A77AD411B76200508B65AC69B4D1D4@EAMBUNT705> Date: Tue, 09 Apr 2002 10:29:48 -0700 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > The only problem with this typing is that it presumes the client > always knows what to ask for. In the cases we have today, that > appears to be appropriate. Right. In the specific cases of Temporary and "normal" addresses, I think the client does know which it wants and needs to treat them differently. > However, it is not clear that this would be the case down the road > depending on how "type" is defined. Thinking a bit more on this, I don't think a separate type field is needed in the IA itself. Just let the DHCP option number itself serve that purpose. I.e., it's perfectly OK to assign different option numbers for the temporary vs. normal address case. The actual format of the options could be the same, if that is what makes sense. > For example, one might ask > whether we should split the "normal" case in two and have > "normal-global" and "normal-site". I would argue no, for the reason that the client shouldn't be distinguishing these cases. I.e, the client just gets a set of addresses (0, 1, 2 or more globals, 0 or more site-locals) and assigns them to the interface. The client shouldn't care about how many or what type. It just uses the ones assigned to it. So I think we are in agreement that generalizing this is a potentially troubling direction. However, in the specific case of temporary address vs. non-temporary, the client may well have more specific knowledge about how they are used (e.g., the client may want to switch to a new temporary address more frequently than another client, so this should be under client control). Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Apr 9 23:06:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00558 for ; Tue, 9 Apr 2002 23:06:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA09513 for dhcwg-archive@odin.ietf.org; Tue, 9 Apr 2002 23:06:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09404; Tue, 9 Apr 2002 23:02:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09374 for ; Tue, 9 Apr 2002 23:02:28 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00496 for ; Tue, 9 Apr 2002 23:02:25 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g3A31vi21300 for ; Tue, 9 Apr 2002 22:01:57 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g3A31v309372 for ; Tue, 9 Apr 2002 22:01:57 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Apr 09 22:01:57 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 22:01:56 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69CEC89E@EAMBUNT705> From: "Bernie Volz (EUD)" To: Thomas Narten Cc: vijayak@india.hp.com, dhcwg@ietf.org Subject: RE: FW: [dhcwg] co-existence of temp and normal addresses Date: Tue, 9 Apr 2002 22:01:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E03C.113E9C20" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E03C.113E9C20 Content-Type: text/plain; charset="iso-8859-1" Thomas: What I don't like about the separate option space is can the IA values then overlap between the various options or are they assigned from ONE number space. If it is one option, I think it is clearer that they are assigned from ONE number space (but perhaps that is just my way of thinking). There is always the issue of what happens if an IA already exists (on the server) and now the client sends a message with that IA but uses a DIFFERENT type for that IA number. As I write this, I see that if we had (1) a separate option and (2) a separate number space for the IAs within that option number, then we would avoid this issue since then there is no conflict. This kind of makes the IA a 48 bit value - 16-bits for the option and 32-bits for the IA value. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Tuesday, April 09, 2002 1:30 PM To: Bernie Volz (EUD) Cc: vijayak@india.hp.com; dhcwg@ietf.org Subject: Re: FW: [dhcwg] co-existence of temp and normal addresses > The only problem with this typing is that it presumes the client > always knows what to ask for. In the cases we have today, that > appears to be appropriate. Right. In the specific cases of Temporary and "normal" addresses, I think the client does know which it wants and needs to treat them differently. > However, it is not clear that this would be the case down the road > depending on how "type" is defined. Thinking a bit more on this, I don't think a separate type field is needed in the IA itself. Just let the DHCP option number itself serve that purpose. I.e., it's perfectly OK to assign different option numbers for the temporary vs. normal address case. The actual format of the options could be the same, if that is what makes sense. > For example, one might ask > whether we should split the "normal" case in two and have > "normal-global" and "normal-site". I would argue no, for the reason that the client shouldn't be distinguishing these cases. I.e, the client just gets a set of addresses (0, 1, 2 or more globals, 0 or more site-locals) and assigns them to the interface. The client shouldn't care about how many or what type. It just uses the ones assigned to it. So I think we are in agreement that generalizing this is a potentially troubling direction. However, in the specific case of temporary address vs. non-temporary, the client may well have more specific knowledge about how they are used (e.g., the client may want to switch to a new temporary address more frequently than another client, so this should be under client control). Thomas ------_=_NextPart_001_01C1E03C.113E9C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: [dhcwg] co-existence of temp and normal addresses =

Thomas:

What I don't like about the separate option space is = can the IA values then overlap between the various options or are they = assigned from ONE number space. If it is one option, I think it is = clearer that they are assigned from ONE number space (but perhaps that = is just my way of thinking).

There is always the issue of what happens if an IA = already exists (on the server) and now the client sends a message with = that IA but uses a DIFFERENT type for that IA number.

As I write this, I see that if we had (1) a separate = option and (2) a separate number space for the IAs within that option = number, then we would avoid this issue since then there is no conflict. = This kind of makes the IA a 48 bit value - 16-bits for the option and = 32-bits for the IA value.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Tuesday, April 09, 2002 1:30 PM
To: Bernie Volz (EUD)
Cc: vijayak@india.hp.com; dhcwg@ietf.org
Subject: Re: FW: [dhcwg] co-existence of temp and = normal addresses

> The only problem with this typing is that it = presumes the client
> always knows what to ask for. In the cases we = have today, that
> appears to be appropriate.

Right. In the specific cases of Temporary and = "normal" addresses, I
think the client does know which it wants and needs = to treat them
differently.

> However, it is not clear that this would be the = case down the road
> depending on how "type" is = defined.

Thinking a bit more on this, I don't think a separate = type field is
needed in the IA itself. Just let the DHCP option = number itself serve
that purpose. I.e., it's perfectly OK to assign = different option
numbers for the temporary vs. normal address case. = The actual format
of the options could be the same, if that is what = makes sense.

> For example, one might ask
> whether we should split the "normal" = case in two and have
> "normal-global" and = "normal-site".

I would argue no, for the reason that the client = shouldn't be
distinguishing these cases. I.e, the client just = gets a set of
addresses (0, 1, 2 or more globals, 0 or more = site-locals) and
assigns them to the interface. The client shouldn't = care about how
many or what type. It just uses the ones assigned to = it.

So I think we are in agreement that generalizing this = is a potentially
troubling direction.

However, in the specific case of temporary address = vs. non-temporary,
the client may well have more specific knowledge = about how they are
used (e.g., the client may want to switch to a new = temporary address
more frequently than another client, so this should = be under client
control).

Thomas

------_=_NextPart_001_01C1E03C.113E9C20-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Apr 9 23:58:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01608 for ; Tue, 9 Apr 2002 23:58:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA11609 for dhcwg-archive@odin.ietf.org; Tue, 9 Apr 2002 23:58:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA11470; Tue, 9 Apr 2002 23:54:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA11435 for ; Tue, 9 Apr 2002 23:54:22 -0400 (EDT) Received: from localhost (s210-219-157-224.thrunet.ne.kr [210.219.157.224]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01551 for ; Tue, 9 Apr 2002 23:54:16 -0400 (EDT) Message-Id: <200204100354.XAA01551@ietf.org> Reply-To: lsjin67@hanmir.com From: 이성진 To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 10 Apr 2002 12:54:44 +0900 Subject: [dhcwg] 함께할 정예멤버를 찾습니다.(홍보) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 뉴트리션포라이프는미국텍사스주휴스턴에위치하고있고미국석유회사로제조회사,유통회사등자회사50여개를운영하며550여가지제품을자체생산,유통하는네트웍세계5위의글로벌회사입니다.

O 허락없이 메일을 보내서 죄송합니다. 본 메일은 일회성 메일이며, 절대로 다시 보내지 않겠습니다.
O 본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다. e-mail주소는 인터넷상에서 취득하였으며, 주소외 어떠한 개인 정보도 가지고 있지 않습니다. 수신을 원하지 않으시면 수신거부를 해 주십시요. [수신거부]

뉴트리션 포 라이프는 미국 텍사스주 휴스턴에 위치하고 있고 미국석유회사로 제조회사, 유통회사 등 자회사 50여개를 운영하며 550여 가지 제품을 자체 생산, 유통하는 네트웍 세계 5위의 글로벌 회사입니다.

84년에 시작해서 전 세계 20여 개국에 진출했고 17년 동안 한번도 보상플랜 변경이나 보너스 변경을 해 본 일 이 없습니다. 그리고 세계 20여 개국에 진출하면서 한번도 공식발표한 오픈일정을 연기한 적이 없습니다. 그만큼 믿을 수 있는 회사입니다.

올해 2월 국내 공식오픈을 발표했습니다. 헤더 사업자가 되셔서 큰 수입을 평생 얻어 가실 수 있는 절호의 기회입니다. 미국석유회사(에버레스트) 대표가 주주라 자본력 또한 막강 합니다. 전 세계적으로 하루에도 수 많은 네트워크 마케팅 회사들이 생겨나고 있습니다. 그러나 이 회사들의 95%는 5년 내에 파산하며, 나머지 5% 중에 10년 이상 지속되는 회사는 1%에 지나지 않는다고 합니다. 자신이 몇 년 동안 노력하여 일구어 놓은 수입라인과 조직도 회사가 문을 닫는다면 모든 것이 물거품이 되는 것입니다.

뉴트리션 포 라이프는 바로 그 1%에 포함된 회사입니다. 현재 국내에는 800여개의 마케팅 회사가 있으며, 1년도 안되 사라지는 회사도 있습니다. 뉴트리션 포 라이프는 17년 동안 단 한번도 회원들에게 수당을 지급하지 못한 사례가 없는 회사이며, 등록 디스트리뷰터의 활동성과 평균 수입에서 최고를 기록하고 있습니다. 이 이상의 확실한 회사는 앞으로도 잘 있으리라 생각되지 않기에 전문가들조차 뉴트리션 포 라이프를 향후 글로발 네트웍을 지배할 회사로 보는 것입니다.

17년간의 인지도, 공신력 , 검증 (4A2)
전세계에 500만 이상의 회원을 확보하고 있으며 미국회원 재구매율 85%의 건전한 기업입니다. (온라인으로 확인가능)
회원 수 대비 1인당 매출액 연간 700만원 (마케팅 회사중 최고)

국제적 신용조사회사 Dun & Bradstreet사(무디스의 모회사)의 신용평가 "4A2"
2000년 포츈지 100대 기업 선정
MLM INSIDER MAGAZINE 선정 베스트 컴퍼니 98년 2위, 99년 9위
유명 네트웍 저널 Money Maker's Monthly지 2001년 Company of the month 2회 선정
미국 및 캐나다 DSA(다이렉트 셀링 협회) 영구회원사.

○ 한국 네트워크 매거진 1월호 특별기사 -기사보기
○ 2월 8일자 매일경제 - 기사보기

★ 미국에서도 불과 200개 회사만 회원으로 등록된 까다롭기로 유명한 협회이며, 뉴트리션 포 라이프는 이 협회의 영구회원으로 등록되어 있습니다.
위의 검증은 정말 까다로우며 회사의 모든 부면을 철저히 검증하여 등급을 매기는 것입니다. 이미12개 나라 오픈을 했으며 전 세계 1위 탈환이 앞으로의 계획이랍니다.

뉴트리션 포 라이프는 17년 동안 닦아 온 미국에서의 튼튼한 기반을 바탕으로, 이제 한국시장에서 폭발적인 성장을 이룩할 것입니다.

네트웍 사업자들이 사업을 진행 하는데 가장 쉬운 아이템은 생활 용품 입니다. 500여 가지가 넘는 제품을 자체 생산하며 중간 유통을 아예 없애버려 가격 또한 저렴합니다.(공장 - 사업자) (자체 거대한 생산라인 보유) 건강 식품 다이어트 혈액순환개선 비타민제 미네랄 헤어케어 화장품 등등..(500여가지에 달하는) 없는 게 없을 정도로 완벽 지원 합니다.
특히, 뉴트리션포라이프의 비타민/미네랄 제품은 온몸에 골고루 영양을 주는 제품이 아니라, 특정 부위/병세(간, 소화기, 고혈압, 당뇨, 변비 등)에 확실한 치유 효과를 보여준다.

탁월한 제품군
바이오 워터 - 이 제품이 출시되면서 뉴트리션포라이프의 대표적인 제품이 되었다. 제품이 소개되면서 제품의 체험담이 실린 "나는 보았다. 그러나, 나는 믿을 수 없다"라는 책이 나왔다. 효과/효능 : 고혈압, 당뇨, 변비 치료(먹으면) 피부 보습, 기미제거, 화상 치료. 특히 화상을 흉터없이 아물게 하는데 탁월하다.
스노어리스 - 코골이약. 목젖에 뿌려주면 코를 골지 않고 잘 수 있다. 한국 남성의 80%가 코를 곤다고 합니다. 이약을 사용하면 코를 골지 않을 뿐 아니라, 숙면을 취하게 하는데 도움을 준다.
오션 헬스 - 간경화, 간질환, 지방간 등에 치유를 할 수 있는 제품.

가. 사업자되기
1. 무료회원가입
( 사업활동, 1000$ 이상 매출시 사업자 혜택 부여, )
2. 200$ 키트구매 ( 속성코스1 )
( 200$의 제품과 사업키트 제공 )
3. 300$ 키트구매 (속성코스2 )
( 500$ 제품과 사업키트 제공 )

나. 사업자 유지
1) 월 수당 지급조건 : 매달 재구매 매출 100$ 유지
2) 사업자 유지 : 2개월 동안 재구매 매출 100$ 유지
- 2개월연속 무활동 사업자(2개월 연속 재구매가 없는 사업자)는 레그에서 빠져 다운에서 다시 시작하여야 합니다.
- 이는 아주 강력한 보상플랜이며, 타 네트웍에 비해 굉장한 장점입니다.(재구매가 안 일어날수가 없죠.)

바로 본 사업의 보상플랜이 4*7 매트릭스이며 스필오버로 내려가며 사업자가 되면 후원인이 1명도 없어도 유지수당인 조직 보너스만 3단계까지 1,045,200원을 매달 받을 수가 있습니다. 즉, 위의 스폰서들로 부터 자동 스필오버가 되어 다운을 내려받기 때문입니다. 1분을 후원하게 되면 브론즈가 되며 스필오버로 형성된 4단계(256분)까지 조직보너스만 4,373,200원을 매달 받을 수 있습니다. 이런 식으로 7단계까지 매트릭스가 짜여진다면, 사업자는 1억원 정도의 조직보너스를 매달 받게 됩니다.
직급은 사업자에서 후원인 수에 따라 승급하며 8분을 후원하게 되면 플래티넘이라는 직급이 되며 전체매출에 1%로를 더 받을 수 있습니다. 자기 추천인 중에 플래티넘을 한명 두게 되면 1스타가 되며 전체매출의 2%, 2명두게 되면 2스타가 되며 전체매출의 3%, 이런 식으로 4스타까지 올라가면 전체매출의 5%를 더 받게 됩니다.

뉴트리션 포 라이프의 보상플랜 중 자동차 보너스의 매력은 상당합니다. 499$ 가입 사업자는 6개월내 3단계 채우고 매출 4,000$이상일 때 일시불 보너스 1000$를 받습니다. 자동차 보너스는 기간에 관계없이 예를 들어 3단계의 64분 중 40분이 재 구매를 하여 4000$ 매출이 일어나면 매달 300$를 지급받습니다. 6000$ 매출시 500$, 9000$ 매출시 750$를 매달 지급받습니다.
또, 사업초기에는 추천수당만으로 얼마든지 재구매 유지비용을 충당하고 수입을 만드실 수 있습니다. 추천수당을 50%까지 풀어주기 때문입니다. 199$, 499$ 회원 구분 없이 199$회원 1명을 후원할 경우 25%로 5만원, 499$ 회원 1명을 후원할 경우 37%인 22만오천원을 지급합니다. 그리고 님이 플래티넘이 되면 님의 직추천인이 한 분을 후원할 때마다 25$를 간접후원수당으로 지급받구요. 그리고 이 추천수당은 끝없이 이어지는 무한대의 수당입니다.

- 4스타 이상
1)4스타 보너스-주택구입 보너스-> 월3,000$지급, 자동차 보너스 ->$750/월
2)5스타 보너스-주택구입 보너스-> 월 5,000$지급, 자동차 보너스 ->$1500/월
3)대통령보너스-주택구입 보너스-> 월 10,000$지급, 자동차보너스 ->$3500/월
(5스타-추천인중 플라티늄 7명, 대통령-추천인중 플라티늄15명)

◎ 개인 그룹 보너스
당신이 세일즈 볼륨(SV)을 생성하는 각 달, 당신은 당신의 개인 그룹 보너스 볼륨을 근거로 보너스를 받을 자격을 갖는다. 당신의 개인 그룹은 당신이 후원했던 (그리고 그들이 후원했던 사업자 등등) 사업자로서의 아직 자격을 얻지 않은 사람, 사업자 조직에 들어온 사람들로 구성된다.
당신은 당신의 개인 그룹 모든 사람에 의해 생성되는 총 보너스 볼륨(BV)에서 20%를 받는다--얼마나 깊던간에! 예를 들어 당신의 개인 그룹 보너스 볼륨에 400달러의 합계를 생성하면 당신의 사업자 개인의 그룹 보너스가 80달러일 것이다.

◎ 소매업자 보너스
◎ 매주 새사업자 보너스

보상플랜에 대해서 자세히 아시려면 홈페이지를 방문해 주세요.

☞ 『정회원에게 무료 홍보용 홈페이지 제공』
☞ 『가상회원 서비스 실시』
☞ 『온라인 및 오프라인 네트워크 마케팅 교육 실시』
☞ 『뉴사모닷컴과 뉴사모카페를 통한 회원제 커뮤니티 실시』

◆ 홈페이지 "뉴사모닷컴"

◆ 커뮤니티 "뉴사모카페"

가상회원(뉴사모팀) 가입하기

본 메일은 일회성임으로 다시는 보내지 않습니다.

귀하에 대한 다른 정보는 알지 못하며,

원치 않는 분들에게는 죄송한 말씀을 드립니다.

그러나 기독교인들에게는 고정관념을 버리고

꼭 상고해 보시길 부탁드립니다.

먼저 기독교인들이 거듭나지 못하는 원인을 바로 알아서...

자기를 부인하고 자기의 십자가를 지는 삶 속에...

주님을 바로 알고 따라 갑시다.

--= Multipart Boundary 0410021423 Content-Type: application/octet-stream; name="천국비밀1.htm" Content-Disposition: attachment; filename="천국비밀1.htm" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMC8v RU4iPg0KPGh0bWw+DQo8aGVhZD4NCjx0aXRsZT6/wLTDs68gseK1trGzwMcg uPC15yCzrSC5rsGmKL+1ILrQurAsIMO1u+fDosG2LCDBy8DHseK/+Cwgu+e0 3CwguLaxzbXuKbXpwLs8L3RpdGxlPg0KPG1ldGEgbmFtZT0iZ2VuZXJhdG9y IiBjb250ZW50PSJOYW1vIFdlYkVkaXRvciB2My4wIj4NCjwvaGVhZD4NCg0K PGJvZHkgYmdjb2xvcj0iIzA2NDk2NCIgdGV4dD0iYmxhY2siIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiIGFsaW5rPSJyZWQiPg0KDQo8ZGl2IGFsaWdu PSJjZW50ZXIiPjx0YWJsZSBib3JkZXI9IjMiIHdpZHRoPSI2MDAiIGhlaWdo dD0iODAwIiBiZ2NvbG9yPSIjRkZGOUU5Ij4NCiAgICA8dHI+DQogICAgICAg IDx0ZD48cD48YnI+IDxmb250IHNpemU9IjIiIGNvbG9yPSIjMDc3RDgwIj66 u7jewM/AuiDB1rTUwMcgurjH98DHILD4t87AziANCiAgICAgICAgICAgIL3K wNqwocDHILW1v6EgtOvH0SC9xb7TwaS6uMDUtM+02S48YnI+IMC6x/24piDH 1LKyILD4wK/Hz7DtwNogx9W0z7TZLrjewM/B1rzSIA0KICAgICAgICAgICAg v9y/obTCILHNx8+/oSC068fRIL7GtMIgwaS6uLChIL74wLi45yw8YnI+IL/4 xKEgvsq0wiC60LXpsrK0wiDBpMHfyPcgDQogICAgICAgICAgICC757D6teW4 s7TPtNkuIDwvZm9udD48Zm9udCBzaXplPSIyIiBjb2xvcj0icmVkIj66uyC4 3sDPwLogwM/IuLy6wNPAuLfOIA0KICAgICAgICAgICAgtNm9w7TCILq4s7vB 9iC+yr3AtM+02S48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwNzdE ODAiPrjwtecgDQogICAgICAgICAgICC60LXpsrIgwvwgxvK+yMDMIMfUsrLH z73DseYgseK/+MfVtM+02S48L2ZvbnQ+IDxicj4gPGJyPiA8YSBocmVmPSJo dHRwOi8vd3d3LmFub3RoZXJjb21mb3J0ZXIubmV0L8O1sbm68bnQLmh0bSI+ PGltZw0KICAgICAgICAgICAgIHNyYz0iaHR0cDovL3d3dy5hbm90aGVyY29t Zm9ydGVyLm5ldC9ib2hlc2EvYmFubmVyL7+tuLC5rrTrua4zMS5naWYiDQog ICAgICAgICAgICAgYm9yZGVyPSIwIj48L2E+PC9wPg0KICAgICAgICAgICAg PHAgYWxpZ249ImNlbnRlciI+PGhyIHdpZHRoPSI1ODAiIG5vc2hhZGUgY29s b3I9Ijk5NjY2NiI+PC9wPg0KICAgICAgICAgICAgPHAgYWxpZ249ImNlbnRl ciI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMwNzdEODAiPr/AtMOzryCx4rW2 sbPAxyANCiAgICAgICAgICAgILjwtecgs60gua7Bpii/tSC60LqwLCDDtbvn w6LBtiwgwcvAx7Hiv/gsIDxicj4gu+e03CwguLaxzbXuKbXpwLsgDQogICAg ICAgICAgICDIrr3HyPcgx9iw4cfSILz2IMDWtMIguvG50MDHILi7vri16cDM IDxicj4gvcrA2rChwMcgtbW+yL+hvK0gueDH9MH9tM+02S48L2ZvbnQ+PC9w Pg0KICAgICAgICAgICAgPHAgYWxpZ249ImNlbnRlciI+PGZvbnQgc2l6ZT0i NCIgY29sb3I9ImJsdWUiPjxiPr+5vPa4piC+xrTCIMH2vcQovcrA2rChwMcg DQogICAgICAgICAgICC1tSkgvsi/obytPC9iPjwvZm9udD48L3A+DQogICAg ICAgICAgICA8cCBhbGlnbj0iY2VudGVyIj48Zm9udCBzaXplPSIzIiBjb2xv cj0icmVkIj4xKcL8IMfPs6q01LD6IL+pyKO/zSANCiAgICAgICAgICAgIMfP s6q01MDMILTZuKUgsM3AuyC+xr3KtM+x7j88YnI+IDIpw7kgu+e29yC+xrTj wMwguLaxzSC757TcwM4gsM3AuyANCiAgICAgICAgICAgIL7Gvcq0z7HuPzxi cj4gMynB9rHdse7B9iC+y77GIL/CIMO1u+fDosG2wMcgx+OxuLy6wLsgvsa9 yrTPse4/PGJyPiANCiAgICAgICAgICAgIDQpwfax3bHuwfYgvsu+xiC/wiDB y8DHseK/+MDHIMfjsbi8usC7IL7Gvcq0z7HuPzxicj4gNSnB+LiuwMcgvLq3 ySANCiAgICAgICAgICAgILq4x/2757imILnZt84gvsuw7SC4tsC9v6Egv7XB osfYvt8gx8+zqrTUwMcgvsa16Txicj4gNim6uMf3wMcgsPi3zsDOIA0KICAg ICAgICAgICAgvcrA2rChwMcgtbW4piC+xr3KtM+x7j88YnI+IDcpwLK5/cDH IMD6wdaxxyDA2rimIL7Gvcq0z7HuPzwvZm9udD48L3A+DQogICAgICAgICAg ICA8cCBhbGlnbj0iY2VudGVyIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iIzA3 N0Q4MCI+w7WxucDHILrxudDAuyC+y8H2IA0KICAgICAgICAgICAguPjHz7jp ILDhxNogw7WxuSC56by6wMwgtckgvPYgvvi9wLTPtNkuPGJyPiC9ysDasKHA xyC1tbTCIMO1sbnAxyANCiAgICAgICAgICAgILrxudDAzLDtLCDDtbG5wMcg v624sCC5rsDMuOcsIDxicj4gx8+zqrTUwMcgtubAzLDtLCC757b7wNS0z7TZ LjwvZm9udD48L3A+DQogICAgICAgICAgICA8cCBhbGlnbj0iY2VudGVyIj48 Zm9udCBzaXplPSIzIiBjb2xvcj0iIzA3N0Q4MCI+wda01LKyvK0gwdfAuL3D sO0gDQogICAgICAgICAgICC6zsiwx8+9ycC4t84gv62+7iCz9cC4vcU8YnI+ IL+tuLAgua7AuLfOILXpvu6wqb3DtNkuPC9mb250PjwvcD4NCiAgICAgICAg ICAgIDxwIGFsaWduPSJjZW50ZXIiPjxhIGhyZWY9Imh0dHA6Ly93d3cuYW5v dGhlcmNvbWZvcnRlci5uZXQvw7WxubrxudAuaHRtIj48aW1nDQogICAgICAg ICAgICAgc3JjPSJodHRwOi8vd3d3LmFub3RoZXJjb21mb3J0ZXIubmV0L2Jv aGVzYS9iYW5uZXIvY3diMy5naWYiIGJvcmRlcj0iMCI+PC9hPjwvcD4NCiAg ICAgICAgICAgIDxwIGFsaWduPSJjZW50ZXIiPjxmb250IHNpemU9IjMiIGNv bG9yPSIjMDc3RDgwIj7DtbG5wMcguvG50L+hILD8x9EgDQogICAgICAgICAg ICDDpcDauKYguau34bfOILq4s7sgteW4s7TPtNkuPGJyPiC43sDPt84gvcXD u8fPvLy/5DwvZm9udD48L3A+DQogICAgICAgICAgICA8cCBhbGlnbj0iY2Vu dGVyIj48aHIgd2lkdGg9IjU4MCIgbm9zaGFkZSBjb2xvcj0iOTk2NjY2Ij48 L3A+DQogICAgICAgICAgICA8cCBhbGlnbj0iY2VudGVyIj48YSBocmVmPSJo dHRwOi8vd3d3LmFub3RoZXJjb21mb3J0ZXIubmV0L2Nyb3NzMi5odG1sIj48 aW1nDQogICAgICAgICAgICAgc3JjPSJodHRwOi8vd3d3LmFub3RoZXJjb21m b3J0ZXIubmV0L2JvaGVzYS9iYW5uZXIvv624sLmutOu5rjUxLmdpZiINCiAg ICAgICAgICAgICBib3JkZXI9IjAiPjwvYT4gPC9wPg0KICAgICAgICAgICAg PHA+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMwNzdEODAiPjxiPrq4IMf9ILvn ILq5IMC9ILyxILGzIMi4PC9iPjwvZm9udD48Zm9udA0KICAgICAgICAgICAg IHNpemU9IjIiIGNvbG9yPSIjMDc3RDgwIj48YnI+IDwvZm9udD48YSBocmVm PSJodHRwOi8vd3d3LmFub3RoZXJjb21mb3J0ZXIubmV0Ig0KICAgICAgICAg ICAgIG9uZm9jdXM9InRoaXMuYmx1cigpIj48Zm9udCBzaXplPSIyIiBjb2xv cj0iIzA3N0Q4MCI+aHR0cDovL3d3dy5hbm90aGVyQ29tZm9ydGVyLm5ldDwv Zm9udD48L2E+PGZvbnQNCiAgICAgICAgICAgICBzaXplPSIyIiBjb2xvcj0i IzA3N0Q4MCI+PGJyPiA8L2ZvbnQ+PGEgaHJlZj0iaHR0cDovL3d3dy5wYXJh a2xldG9zLnBlLmtyIg0KICAgICAgICAgICAgIG9uZm9jdXM9InRoaXMuYmx1 cigpIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzA3N0Q4MCI+aHR0cDovL3d3 dy5wYXJha2xldG9zLnBlLmtyPC9mb250PjwvYT48Zm9udA0KICAgICAgICAg ICAgIHNpemU9IjIiIGNvbG9yPSIjMDc3RDgwIj48YnI+IDwvZm9udD48YSBo cmVmPSJtYWlsdG86Ym9oZXNhQGFub3RoZXJjb21mb3J0ZXIubmV0Ig0KICAg ICAgICAgICAgIG9uZm9jdXM9InRoaXMuYmx1cigpIj48Zm9udCBzaXplPSIy IiBjb2xvcj0iIzA3N0Q4MCI+Ym9oZXNhQGFub3RoZXJDb21mb3J0ZXIubmV0 PC9mb250PjwvYT48L3RkPg0KICAgIDwvdHI+DQo8L3RhYmxlPjwvZGl2Pg0K PC9ib2R5Pg0KDQo8L2h0bWw+ --= Multipart Boundary 0410021423-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Apr 10 07:45:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15617 for ; Wed, 10 Apr 2002 07:45:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA15223 for dhcwg-archive@odin.ietf.org; Wed, 10 Apr 2002 07:45:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15158; Wed, 10 Apr 2002 07:42:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15138 for ; Wed, 10 Apr 2002 07:42:55 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15570 for ; Wed, 10 Apr 2002 07:42:51 -0400 (EDT) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g3ABgq3G016396 for ; Wed, 10 Apr 2002 13:42:52 +0200 (MEST) Received: from al.edt.ericsson.se (edt375.al.edt.ericsson.se [136.225.193.21]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0GUC00O6WOJG7Q@mbb1.ericsson.se> for dhcwg@ietf.org; Wed, 10 Apr 2002 13:42:52 +0200 (MET DST) Date: Wed, 10 Apr 2002 13:42:52 +0200 From: Anders Vestlund To: dhcwg@ietf.org Message-id: <3CB4253C.9CBDFB18@al.edt.ericsson.se> Organization: Ericsson Radio Systems MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Content-Transfer-Encoding: 7bit Subject: [dhcwg] Status length Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi, I'm currently implementing a parse function for dhcp ipv6 messages. While reading draft 23 I noticed that status have different lengths in different options: IA option: IA Status = 8 bits IAADDR option: addr status = 7 bits STATUS_CODE option: status-code = 16 bits Is there a reason for this, or why don't they have the same lengths ? (It would result in a shorter parse function : ) ) Best Regards Anders Vestlund Ericsson /// _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Apr 10 11:45:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22797 for ; Wed, 10 Apr 2002 11:45:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29996 for dhcwg-archive@odin.ietf.org; Wed, 10 Apr 2002 11:45:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29834; Wed, 10 Apr 2002 11:42:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29797 for ; Wed, 10 Apr 2002 11:42:01 -0400 (EDT) Received: from 2ktest.sp.co ([208.5.112.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22644 for ; Wed, 10 Apr 2002 11:41:53 -0400 (EDT) Received: from mail.expl.com (SIERRA [128.200.0.63]) by 2ktest.sp.co with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 227H5VJV; Tue, 9 Apr 2002 10:42:35 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 10 Apr 2002 10:44:03 -0500 Message-ID: <4C0009BCF7F2F640AC15B254A9D4F71C2027F4@sierra.epl.com> Thread-Index: AcHgpopiX2OO0+nhQQu1knOGyLtt3A== From: "Bryan Lavigne" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA29798 Subject: [dhcwg] (no subject) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Apr 10 16:25:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01911 for ; Wed, 10 Apr 2002 16:25:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17998 for dhcwg-archive@odin.ietf.org; Wed, 10 Apr 2002 16:25:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17924; Wed, 10 Apr 2002 16:24:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17896 for ; Wed, 10 Apr 2002 16:24:01 -0400 (EDT) Received: from localhost ([61.32.165.61]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01825 for ; Wed, 10 Apr 2002 16:23:55 -0400 (EDT) Message-Id: <200204102023.QAA01825@ietf.org> Reply-To: web21@fishchain.co.kr From: 내고향 직거래 장터 To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 11 Apr 2002 05:18:30 +0900 Subject: [dhcwg] [광고] 나의 살던 고향은........? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 다함께 만드는 내고향 장터

수산물 ㅣ 특산물 ㅣ 농산물 ㅣ 건강식품/식품 ㅣ 공산품

내 고향 상품 자랑	내 향우회 모임	내 종친회 모임
[농축산물]갑천면: 참숯갈비 [수산물]인제군: 황태구이 [건강식품/식품] 안동시: 안동식혜	[서울시]이문동: 재경 당진인 모이 [서울시]반포: 반포향우회 [서울시]강원대 환경학 재경동문회	[대구시]대구: 백우회 [서울시]: 재경 전의 이씨 종친회 [경기도]: 宋氏禦梅公派親睦會
장터 모임방	내가 가본 곳 맛자랑	내 고향 장날 소개
[충청북도]청산장: 청산토박이 [충청북도]옥천: 옥천장 사랑 [경기도]파주: 파주장단콩 축제	[농축산물] 양양군: 손양면 꿩요리 [수산물] 운서동: 민물장어 [농축산물] 옥련동: 하늘다리상	[1,6일장] 충청북도 음성군 음성장 [2,7일장] 경상북도 성주군 성주장 [3,8일장] 강원도 동해시 북평장

내 고향 직거래 장터 첫 화면		내 고향 직거래 장터 무료 입점 점포 화면

다 함께 만드는 내 고향 직거래 장터는 고객님들의 참여를 중심으로 유통 혁신을 이룩하여 땀 흘리며 수확 하는 농촌,어촌의 내 부모님에게 실질소득이 증대되도록 최선을 다 하겠습니다. 내 고향의 우수한 상품을 소개하시고, 내 고향에서 판매되는 상품을 신뢰로 구매하여 더 불어 잘 사는 사회실현을 목표로 합니다
- 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다. - e-mail주소외 어떠한 개인 정보도 가지고 있지 않으며, 드리는 정보가 도움이 되시길 희망합니다. - 사전 허락을 받지 않고 전송하여 정말 죄송합니다...........[수신거부]


입점업체 안내 무료 입점 신청 입점 점포 찾기 예약구매 신청하기 대량구매 신청하기
다 함께 만드는 내 고향 직거래 장터	담당자: 류호성팀장(E-Mail) 전화 : 02-966-6701~2 팩스 : 02-966-6703

괭이부리말 아이들	봉순이 언니

해리포터 시리즈	반지의 제왕

누가 내 치즈를 옮겼을까	만화로 보는 그리스 로마 신화

새 먼나라 이웃나라	로마인 이야기

이윤기의 그리스 로마 신화	부자 아빠 가난한 아빠

본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률
제 50조에 의거한 북스포유 [광고] 메일입니다.
더이상 메일 수신을 원하지 않으신다면 수신거부를 눌러주세요

This is something we should correct.

As it is likely the T-Bit will disappear from the = IA-Address option since we'll likely be adding a Temporary-IA option to = carry temporary addresses (RTA option would also go away), I'd suggest = we standardize on 8-bit values all around.

Thanks for reporting this.

- Bernie Volz

-----Original Message-----
From: Anders Vestlund [mailto:eraaves@al.edt.ericsso= n.se]
Sent: Wednesday, April 10, 2002 7:43 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Status length

Hi,

I'm currently implementing a parse function for dhcp = ipv6 messages.

While reading draft 23 I noticed that status have = different lengths in
different options:
IA option: IA Status =3D 8 bits
IAADDR option: addr status =3D 7 bits
STATUS_CODE option: status-code =3D 16 = bits

Is there a reason for this, or why don't they have = the same lengths ?
(It would result in a shorter parse function : ) = )

Best Regards
Anders Vestlund
Ericsson ///

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

------_=_NextPart_001_01C1E105.D3E04160-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Apr 11 04:00:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21730 for ; Thu, 11 Apr 2002 04:00:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA01246 for dhcwg-archive@odin.ietf.org; Thu, 11 Apr 2002 04:00:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00605; Thu, 11 Apr 2002 03:50:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00579 for ; Thu, 11 Apr 2002 03:50:06 -0400 (EDT) Received: from localhost ([211.217.43.91]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21565 for ; Thu, 11 Apr 2002 03:50:01 -0400 (EDT) Message-Id: <200204110750.DAA21565@ietf.org> Reply-To: 120841w@hanmail.net From: 김정아 To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 12 Apr 2002 01:39:07 +0900 Subject: [dhcwg] [광고[리양의 크레이지 잉글리쉬 5일간의 이벤트 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org [광고]크레이지 잉글리쉬





중국 강연실황 [MBC 화제집중]

신청 양식

이름

성별

남 여

직업

나이

세

전화번호

- -

핸드폰번호

- -

우편번호

주소

E-mail

하고싶은말

영어수준

하 중 상

사전 허락없이 메일을 보내게 된점 사과드립니다.
메일을 수신을 원하지 않으신다면 다음을 클릭해 주세요
메일 수신거부

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Apr 11 10:02:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27529 for ; Thu, 11 Apr 2002 10:02:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18091 for dhcwg-archive@odin.ietf.org; Thu, 11 Apr 2002 10:02:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17126; Thu, 11 Apr 2002 09:54:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17057 for ; Thu, 11 Apr 2002 09:54:10 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27313 for ; Thu, 11 Apr 2002 09:54:06 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3BDral13758 for ; Thu, 11 Apr 2002 09:53:36 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJAMRAH>; Thu, 11 Apr 2002 09:53:37 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E601F0D676@zcard0ke.ca.nortel.com> From: "Glenn Waters" To: dhcwg@ietf.org Date: Thu, 11 Apr 2002 09:53:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E160.48903588" Subject: [dhcwg] Asian messages Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E160.48903588 Content-Type: text/plain Is it just me or is everyone seeing the Asian spam that seems to be hitting this list very hard? If so, can this list be made open only to subscribers? Cheers, /gww ------_=_NextPart_001_01C1E160.48903588 Content-Type: text/html

Is it just me or is everyone seeing the Asian spam that seems to be hitting this list very hard? If so, can this list be made open only to subscribers?

Cheers, /gww

------_=_NextPart_001_01C1E160.48903588-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Apr 11 10:52:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28789 for ; Thu, 11 Apr 2002 10:52:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20678 for dhcwg-archive@odin.ietf.org; Thu, 11 Apr 2002 10:52:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20135; Thu, 11 Apr 2002 10:43:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20111 for ; Thu, 11 Apr 2002 10:43:15 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28490 for ; Thu, 11 Apr 2002 10:43:10 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-249.cisco.com [10.82.224.249]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA05226; Thu, 11 Apr 2002 10:42:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20020411103724.00b7ecd8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 11 Apr 2002 10:42:27 -0400 To: "Glenn Waters" From: Ralph Droms Subject: Re: [dhcwg] Asian messages Cc: dhcwg@ietf.org In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E601F0D676@zcard0ke.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Glenn, According to a recent IESG statement, http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt, it's OK to configure a WG mailing list to require approval for postings from non-subscribers of the list. Unless I hear an objection by 8AM EDT Fri, 4/12, I will make that change to the dhcwg@ietf.org mailing list... - Ralph At 09:53 AM 4/11/2002 -0400, Glenn Waters wrote: >Is it just me or is everyone seeing the Asian spam that seems to be >hitting this list very hard? If so, can this list be made open only to >subscribers? > > > >Cheers, /gww _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Apr 11 10:59:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29096 for ; Thu, 11 Apr 2002 10:59:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21540 for dhcwg-archive@odin.ietf.org; Thu, 11 Apr 2002 10:59:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21218; Thu, 11 Apr 2002 10:57:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21191 for ; Thu, 11 Apr 2002 10:57:47 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29010 for ; Thu, 11 Apr 2002 10:57:38 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3BEv1S05047; Thu, 11 Apr 2002 10:57:02 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJAMTG5>; Thu, 11 Apr 2002 10:57:02 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E601F6505C@zcard0ke.ca.nortel.com> From: "Glenn Waters" To: Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Asian messages Date: Thu, 11 Apr 2002 10:56:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E169.213025C6" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E169.213025C6 Content-Type: text/plain Thanks!! /gww > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Thursday, April 11, 2002 10:42 > To: Waters, Glenn [CAR:IO47:EXCH] > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Asian messages > > Glenn, > > According to a recent IESG statement, > http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt, it's OK to > configure a WG mailing list to require approval for postings from > non-subscribers of the list. Unless I hear an objection by 8AM EDT Fri, > 4/12, I will make that change to the dhcwg@ietf.org mailing list... > > - Ralph > > > At 09:53 AM 4/11/2002 -0400, Glenn Waters wrote: > > >Is it just me or is everyone seeing the Asian spam that seems to be > >hitting this list very hard? If so, can this list be made open only to > >subscribers? > > > > > > > >Cheers, /gww ------_=_NextPart_001_01C1E169.213025C6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Asian messages

Thanks!!

/gww

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Thursday, April 11, 2002 10:42
> To: Waters, Glenn [CAR:IO47:EXCH]
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] Asian messages
>
> Glenn,
>
> According to a recent IESG statement,
> http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy= .txt, it's OK to
> configure a WG mailing list to require approval = for postings from
> non-subscribers of the list. Unless I = hear an objection by 8AM EDT Fri,
> 4/12, I will make that change to the = dhcwg@ietf.org mailing list...
>
> - Ralph
>
>
> At 09:53 AM 4/11/2002 -0400, Glenn Waters = wrote:
>
> >Is it just me or is everyone seeing the = Asian spam that seems to be
> >hitting this list very hard? If so, can = this list be made open only to
> >subscribers?
> >
> >
> >
> >Cheers, /gww

------_=_NextPart_001_01C1E169.213025C6-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Apr 11 11:38:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00190 for ; Thu, 11 Apr 2002 11:38:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA24280 for dhcwg-archive@odin.ietf.org; Thu, 11 Apr 2002 11:38:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22963; Thu, 11 Apr 2002 11:18:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22938 for ; Thu, 11 Apr 2002 11:18:50 -0400 (EDT) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29693 for ; Thu, 11 Apr 2002 11:18:39 -0400 (EDT) Received: from BarrH63p601 ([64.170.118.11]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GUE00L7AT74G0@mta7.pltn13.pbi.net> for dhcwg@ietf.org; Thu, 11 Apr 2002 08:18:41 -0700 (PDT) Date: Thu, 11 Apr 2002 08:18:24 -0700 From: Richard Barr Hibbs Subject: RE: [dhcwg] Asian messages In-reply-to: <0D7FC1D8D861D511AEA70002A52CE5E601F0D676@zcard0ke.ca.nortel.com> To: dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: multipart/alternative; boundary="Boundary_(ID_wOVGD57PMYLdQ9XzQpiQ7Q)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_wOVGD57PMYLdQ9XzQpiQ7Q) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT alternatively, if the "From" address showed the original sender rather than the DHC Working Group then we could filter these messages and those of you using Microsoft Outlook might consider submitting an enhancement request that requests the ability to filter mail on the "Sender" and "Reply-to" fields in addition to the "From" field -- a few hundred or thousand requests might convince the product manager that such features could be very useful --Barr -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Glenn Waters Sent: Thursday, April 11, 2002 06:54 Is it just me or is everyone seeing the Asian spam that seems to be hitting this list very hard? If so, can this list be made open only to subscribers? --Boundary_(ID_wOVGD57PMYLdQ9XzQpiQ7Q) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT

alternatively, if the "From" address showed the original sender rather than the DHC Working Group then we could filter these messages

and those of you using Microsoft Outlook might consider submitting an enhancement request that requests the ability to filter mail on the "Sender" and "Reply-to" fields in addition to the "From" field -- a few hundred or thousand requests might convince the product manager that such features could be very useful

--Barr

-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Glenn Waters
Sent: Thursday, April 11, 2002 06:54

Is it just me or is everyone seeing the Asian spam that seems to be hitting this list very hard? If so, can this list be made open only to subscribers?

--Boundary_(ID_wOVGD57PMYLdQ9XzQpiQ7Q)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Apr 11 12:48:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05593 for ; Thu, 11 Apr 2002 12:48:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29123 for dhcwg-archive@odin.ietf.org; Thu, 11 Apr 2002 12:48:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28778; Thu, 11 Apr 2002 12:40:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28750 for ; Thu, 11 Apr 2002 12:40:39 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05377 for ; Thu, 11 Apr 2002 12:40:35 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.3/8.12.3) id g3BGeamO000847 for dhcwg@ietf.org env-from ; Thu, 11 Apr 2002 10:40:36 -0600 (MDT) Date: Thu, 11 Apr 2002 10:40:36 -0600 (MDT) From: Vernon Schryver Message-Id: <200204111640.g3BGeamO000847@calcite.rhyolite.com> To: dhcwg@ietf.org Subject: RE: [dhcwg] Asian messages References: Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > From: Richard Barr Hibbs > alternatively, if the "From" address showed the original sender rather than > the DHC Working Group then we could filter these messages > > and those of you using Microsoft Outlook might consider submitting an > enhancement request that requests the ability to filter mail on the "Sender" > and "Reply-to" fields in addition to the "From" field -- a few hundred or > thousand requests might convince the product manager that such features > could be very useful > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Glenn > Waters > Is it just me or is everyone seeing the Asian spam that seems to be > hitting this list very hard? If so, can this list be made open only to > subscribers? It's not just this IETF mailing list. Rejecting mail by the mailing list system with these Content-Type values in the headers would go a long way to fixing the problem: Content-Type: text/html; charset="ks_c_5601-1987" Content-Type: text/html; charset=KS_C_5601-1987 Content-Type: text/html; charset=euc-kr Content-Type: text/html; charset="ISO-2022-KR" Regardless of other considerations, mail encoded in those character sets does not belong in mailing lists intended for international audiences. Vernon Schryver vjs@rhyolite.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Fri Apr 12 13:18:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21612 for ; Fri, 12 Apr 2002 13:18:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29168 for dhcwg-archive@odin.ietf.org; Fri, 12 Apr 2002 13:18:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28294; Fri, 12 Apr 2002 13:00:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28265 for ; Fri, 12 Apr 2002 13:00:19 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19415 for ; Fri, 12 Apr 2002 13:00:17 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA22211 for ; Fri, 12 Apr 2002 12:59:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20020412125834.03601d40@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Apr 2002 12:59:46 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Spam control on dhcwg@ietf.org Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I've reconfigured dhcwg@ietf.org so that submissions from non-subscribers must be approved by the list admin (me). - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Sun Apr 14 23:26:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27464 for ; Sun, 14 Apr 2002 23:26:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA29259 for dhcwg-archive@odin.ietf.org; Sun, 14 Apr 2002 23:26:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA29133; Sun, 14 Apr 2002 23:23:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07677 for ; Sun, 14 Apr 2002 13:55:39 -0400 (EDT) Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20661 for ; Sun, 14 Apr 2002 13:55:37 -0400 (EDT) Received: from c1033995a ([12.225.92.14]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020414175458.YBRF15826.rwcrmhc54.attbi.com@c1033995a> for ; Sun, 14 Apr 2002 17:54:58 +0000 From: "Larry & Sally" To: Date: Sun, 14 Apr 2002 10:55:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [dhcwg] configuring DHCP on my home Linux machine with ATT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit I've had an account with attbi for a while using it for internet access and email. I want to configure a linux machine of mine and need some configuration help. I asked the attbi folks via a chat room and they said I was free to use my account with linux; however, they had no configuration information. any help is appreciated, Larry _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Apr 16 06:38:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28577 for ; Tue, 16 Apr 2002 06:38:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA04115 for dhcwg-archive@odin.ietf.org; Tue, 16 Apr 2002 06:38:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03291; Tue, 16 Apr 2002 06:29:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02912 for ; Tue, 16 Apr 2002 06:17:38 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28259 for ; Tue, 16 Apr 2002 06:17:34 -0400 (EDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Tue, 16 Apr 2002 11:45:52 +0200 Message-ID: <8C19E3FBB6467846AFF97E366D34CB601F4A5B@LANMHS20.rd.francetelecom.fr> From: BOIZARD Stephane FTRD/DAC/LAN To: "'dhcwg@ietf.org'" Date: Tue, 16 Apr 2002 11:45:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-139a51a2-510b-11d6-b1ea-00508b69ab48" Subject: [dhcwg] Implementation of RFC 3118 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-139a51a2-510b-11d6-b1ea-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E52B.8338887E" ------_=_NextPart_001_01C1E52B.8338887E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am interesed in DHCP implementation of RFC 3118, related to = Authentication for DHCP Messages. Could someone inform me about the existence of DHCP clients and servers implementing this RFC ? I don't find any information on the web. Best regards, St=E9phane Boizard FTR&D DAC/CIR T=E9l: +33 (0) 2 96 05 16 72 Fax: +33 (0) 2 96 05 11 98 "Attention mon adresse email a chang=E9"=20 =20 ------_=_NextPart_001_01C1E52B.8338887E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Implementation of RFC 3118

Hi,
I am interesed in DHCP implementation = of RFC 3118, related to Authentication for DHCP Messages.
Could someone inform me about the = existence of DHCP clients and servers implementing this RFC ?
I don't find any information on the = web.
Best regards,

St=E9phane = Boizard
FTR&D = DAC/CIR
T=E9l: +33 (0) 2 = 96 05 16 72
Fax: +33 (0) 2 96 = 05 11 98
"Attention = mon adresse email a chang=E9"
<mailto:stephane.bo= izard@rd.francetelecom.com>

------_=_NextPart_001_01C1E52B.8338887E-- ------=_NextPartTM-000-139a51a2-510b-11d6-b1ea-00508b69ab48-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Tue Apr 16 12:30:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15222 for ; Tue, 16 Apr 2002 12:30:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27710 for dhcwg-archive@odin.ietf.org; Tue, 16 Apr 2002 12:30:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27238; Tue, 16 Apr 2002 12:22:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24444 for ; Tue, 16 Apr 2002 11:49:48 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09078 for ; Tue, 16 Apr 2002 11:49:41 -0400 (EDT) Received: from green.bisbee.fugue.com (user-2iveb7p.dialup.mindspring.com [165.247.44.249]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g3GFnDr29321; Tue, 16 Apr 2002 08:49:13 -0700 (PDT) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g3GFnX200354; Tue, 16 Apr 2002 11:49:33 -0400 (EDT) Date: Tue, 16 Apr 2002 11:43:38 -0400 Subject: Re: [dhcwg] Implementation of RFC 3118 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "'dhcwg@ietf.org'" To: BOIZARD Stephane FTRD/DAC/LAN From: Ted Lemon In-Reply-To: <8C19E3FBB6467846AFF97E366D34CB601F4A5B@LANMHS20.rd.francetelecom.fr> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > I am interesed in DHCP implementation of RFC 3118, related to > Authentication for DHCP Messages. > Could someone inform me about the existence of DHCP clients and servers > implementing this RFC ? > I don't find any information on the web. The problem with RFC3118 is that it doesn't solve the key management problem, so nobody's got a practical use for it as it stands. There are some ideas in the wings for ways to make it work (e.g., with Kerberos), but none of them have made it into RFCs yet. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Wed Apr 17 16:28:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06266 for ; Wed, 17 Apr 2002 16:27:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA14941 for dhcwg-archive@odin.ietf.org; Wed, 17 Apr 2002 16:27:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14642; Wed, 17 Apr 2002 16:24:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14189 for ; Wed, 17 Apr 2002 16:17:25 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05761 for ; Wed, 17 Apr 2002 16:17:21 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-93.cisco.com [161.44.150.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA12027 for ; Wed, 17 Apr 2002 16:16:45 -0400 (EDT) Message-Id: <4.3.2.7.2.20020417161205.03829390@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Apr 2002 16:16:30 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-23.txt and authors' response Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Thomas Narten has written a detailed comments based on his review of draft-ietf-dhc-dhcpv6-23.txt. I've included the first part (of two) of Thomas' comments below, with the author's comments in line. We are revising the draft based on our responses and the revision of the draft will be published this Fri, 4/19. Thanks, Thomas, for your thorough, careful and thoughtful review. Your input will help us make the DHCPv6 spec a much better document. - Ralph > General: > > 1) what is the difference between confirm and renew. Do we need > both? Yes. The client is in different states when sending the two messages and the server can make use of that differentiation. > 2) I'd suggest reorganizing sections 18 and 19 somewhat. Currently, > the server stuff is in 18, the client stuff in 19. I think it would > actually be more readable if the related messages were grouped > together in much the same way the message flows go. E.g., talk > about the client aspects of Solicit message generation in one > subsection, followed by the server processing of that message, > followed by the server generation of the Advertise, then the client > processing of it, etc. Its still the case that the server (or > client) processing rules for dealing with the message are > localized, which helps implementors. So I think this is just moving > subsections around rather than changing text. As it is now, one has > to jump around a lot to follow the processing of normal message > flows. The authors discussed this suggestion at some length. We came to the conclusion that doing this right is a lot of effort, and nobody has the bandwidth to do it right now. The current organization doesn't prevent comprehension and we can fix it before PS if there is significant pushback during IETF last call. So, we're going to focus on the parts of the spec that need to be fixed and leave the organization of sections 18, 19 and 20 as is for now. > 3) it could use an overview that describes the basic message flows and > operations. I'm willing to give a shot at doing this, (if I ever > get to it...) Some of us expressed concern about an overview that would describe part of the specification and therefore represent a potential for parts of the spec to be out of sync with each other. We agreed on writing a very high level overview that explains some typical message flows. Here's a candidate outline for a four para overview: client uses information-request to obtain parameters such as DNS configuration. server responds with reply. when configuration is pre-assigned to client, can use "Rapid Commit" two message exchange: Solicit, Committed-Reply DHCPv6 does address assignment, which is useful in situations where net admin needs control and auditing of addresses in use Client uses Rebind/Reply message exchange to extend lease on addresses > Review of -23 > > > 1. Introduction > > > > This document describes DHCP for IPv6 (DHCP), a UDP [19] > > client/server protocol designed to reduce the cost of management > > of IPv6 nodes in environments where network managers require more > > control over the allocation of IPv6 addresses and configuration > > of network stack parameters than that offered by "IPv6 Stateless > > Redo the above based on the more recent thinking on stateful > vs. stateless DHCP? Remember, the intro may be the first and only > opportunity to set the right tone for what DHCP is useful for and > whether it solves a particular problem. > > > DHCP reduces the cost of ownership by centralizing the management > > of network resources such as IP addresses, routing information, OS > > installation information, directory service information, and other > > such information on a few DHCP servers, rather than distributing such > > information in local configuration files among all network node. > > I dunno about the cost of ownership thing. This may be true for v4, > but does it hold for IPv6 with its stateless autoconfig? Seems like a > minor point anyway. > > Also, the example about centralizing the management of "routing > information" is not so good. IMO, this is a bit of a misuse of > DHCP. Let the routers do this (and with ND they are in a much better > position to than with IPv4). > > > of the IPv6 address space. Two advantages of IPv6 are that support > > for multicast is required, and nodes can create link-local addresses > > Note: there has been recent discussion about whether mcast can be > assumed. I think it is safe to assume that link-local multicast is > available, but less so for broader scope. It turns out that DHCP > doesn't rely on the wider scope mcast so much. This could maybe made > clearer here, so that folks to say "uh oh", I can't assume multicast, > therefore, I can stop reading now... > > > communications to discover neighbors on the link. For instance, a > > client can send a Solicit message and locate a server or relay. > > s/a server/an on-link server/ We will rewrite the introduction to focus on recent discussion of applicability of DHCP to configuration (e.g., DNS configuration) and de-emphasize address assignment. > > 4. Design Goals > > This entire section seems of dubious value. It's largely incomplete, I > suspect, and has some somewhat random things in it. Move to an > appendix? Delete? I understand its there from history, but is it > needed at this point in time? > > > - A DHCP client can make multiple, different requests for > > configuration parameters when necessary from one or more DHCP > > servers at any time. > > Does this need to be stated? Where in the document is it recommended > that clients do this? I.e., I think its good to be sure this is not > disallowed, but do we want to say more? (more on this below.) > > > - DHCP will contain the appropriate time out and retransmission > > mechanisms to efficiently operate in environments with high > > latency and low bandwidth characteristics. > > Oh really? > > > - How a DHCP relay is configured or what sort of information it may > > log. > > The document should make clearer just what is required to be > implemented on relay agents in terms of configuration. Section 21 has > some MAYs, but it really should be specified what a relay agent needs > to do to be compliant with this spec. Is it required (MUST?) that > relay agents be configurable with a list of unicast addresses, for > instance, or is this just a MAY? We will delete design goals section from the document. > > link-local address An IPv6 address having link-only > > scope, indicated by having the prefix > > (FE80::0000/64), that can be used to > > should be /10, not /64. Agreed; good catch. > > agent address The address of a neighboring DHCP Agent > > on the same link as the DHCP client. > > > By my check, the use of the term "agent" by itself (meaning either > relay or server) is a handful. I would suggest deleting use of the > term "agent" (when refering to either the relay or a server) and > always use "relay agent" or "server" (or list both) rather than the > generic "agent". In earlier versions of the document, having the term > might have made more sense. But not anymore. We will rewrite to replace "agents" with "relay agents" and "servers" throughout as appropriate. > > binding A binding (or, client binding) is a > > group of server data records containing > > the information the server has about > > the addresses in an IA and any other > > configuration information assigned to > > the client. A binding is indexed by the > > tuple . > > You've got acronyms here that have not yet been defined (IA, DUID, > IAID). The terminology section is in alphabetic order (or will be, with a few fixes), so forward references are unavoidable. > > DHCP relay (or relay) A node that acts as an intermediary to > > deliver DHCP messages between clients > > and servers, and is on the same link as > > a client. > > Why not just use the term "relay agent" (ala DHCPv4) since this is > exactly what it is? Agree. > > DHCP agent (or agent) Either a DHCP server on the same link as > > a client, or a DHCP relay. > > Unneeded, drop. Agreed. > > DUID A DHCP Unique IDentifier for a DHCP > > participant; each DHCP client and server > > has exactly one DUID. > > Add: "For example, a MAC address, IEEE identifier, etc." (or some > such) We will add a reference to the section where DUIDs are defined, as they are not simply described as a MAC address, etc. > > Identity association (IA) A collection of addresses assigned to > > a client. Each IA has an associated > > IAID. An IA may have 0 or more addresses > > associated with it. > > Forward reference to IAID. Also, the description could be better. For > example, it's not just a collection assigned to a "client". A client > might have multiple ones. Maybe something like: > > A collection of addresses assigned to a client. Each IA has an > associated IAID. A client may have more than one IA assigned to > it, e.g., one for each of its interfaces. The forward reference is a result of alphabetic order. Your text is much better and we will use it. > > All_DHCP_Agents (FF02::1:2) This link-scoped multicast address > > is used by clients to communicate with the > > on-link agent(s) when they do not know the > > link-local address(es) for those agents. All > > agents (servers and relays) are members of this > > multicast group. > > remove "agent(s)": wording, e.g., > > All_DHCP_Agents (FF02::1:2) A link-scoped multicast address > used by clients to communicate with > neighboring (i.e. on-link) relay agents and > servers when they do not know the unicast > addresses of those entities. All relay agents > and DHCP servers are members of this > multicast group. Agreed. > > 7.2. UDP ports > > > > DHCP uses the following destination UDP [19] port numbers. While > > source ports MAY be arbitrary, client implementations SHOULD permit > > their specification through a local configuration parameter to > > facilitate the use of DHCP through firewalls. > > This requires configuration of clients. Totally useless (what > requirement/problem does this address?). Remove. Definitely not a > SHOULD. > > > 546 Client port. Used by servers as the destination port > > for messages sent to clients and relays. Used by relay > > agents as the destination port for messages sent to > > clients. > > Note: if all DHCP messages from the server to client are required to > be sent to destination port 546, just make it required that the source > port be 546 for messages from client to server. This simplfies things. > > > 547 Agent port. Used as the destination port by clients > > for messages sent to agents. Used as the destination > > port by relays for messages sent to servers. > > Question: what is the source UDP port for relay agent to server > traffic? does it matter? Why not just make it 546 per above? > > Note: would it make life easier if the relay agent used a different > port (on source to server, and on destination FROM server?) This > *might* simplify implementations when the relay agent is first booting > and itself used DHC to assign its addresses. Or is this a non-problem? > What happens in DHCPv4? Always just statically configured? We've agreed to rewrite this section to say simply "the client listens on port 546; servers and relay agents listen on port 547". > > 7.3. DHCP message types > > General comment. It would be clearer to say who sends which message > rather than "uses". This should be fixed in all the messages in this > section. Also, it would be good to make it clear which messages are > paired together. I.e., "X message is sent by client in response to a Y > message from server". > > E.g.: > > > CONFIRM (4) The Confirm message is used by clients to > > confirm that the addresses assigned to an IA > > and the lifetimes for those addresses, as > > well as the current configuration parameters > > assigned by the server to the client are still > > valid. > > Not clear who sends this and when. Is it a response to a message from > the server? Not clear to me. We will rewrite these descriptions for clarity. > > INFORMATION-REQUEST (11) The Information-request message is sent > > by clients to request configuration parameters > > without the assignment of any IP addresses to > > the client. > > Mention that this can be used for stateless? We will mention stateless DHCPv6 in the revised introduction. > > description. Note that the numeric values do not start at 1, nor are > > they consecutive. The status codes are organized in logical groups. > > This ought to be explained/justified. I can imagine the usefullness of > having ranges of codes, where all the values within a range are > treated the same way, e.g., "hard error", "soft error", etc. so that > one can easily define new codes later that just "work". But there is > not text here saying this (so implementations won't code things this > way). Also, will you need to define an IANA considerations for when to > assign new error codes? We will collapse the list of status codes (numbering 0, 1, 2, ... without grouping), move the list to the IANA considerations section and add a brief explanation of each status code to the table. The status codes will be defined to be 8 bit values, to fit in the various status code fields. We will also take a pass across the spec and delete any unused status codes. > XXX listing the codes here is not helpful. There is insufficient > context for a listing of them to be useful here. It would be better to > just list the table of codes nearer the end of the document, perhaps > in the IANA considerations section. > > XXX I need to check retransmit values ??? > > 8. Message Formats > > This section might benefit from being reorganized somewhat. Right now, > it takes up several pages but its mostly repetetive stuff. Plus, it > doesn't contain all that much useful info, IMO. > > E.g.: > > > 8.1. DHCP Solicit Message Format > > > > msg-type SOLICIT > > > > transaction-ID An unsigned integer generated by the client used > > to identify this Solicit message. > > > > options See section 23. > > All the subsections say the same thing, and this is pretty much > useless information by itself. > > I think a "message formats" section can be quite useful. But, it needs > to include enough of the relevant message fields and say what they all > contain, so that one has a rough idea of what is in a message. In the > case of DHCP this is problematical because much of the meat of the > message is actually in the extensions. Take a look at (say RFC 2461, > section 4). There, just the formats are presented, the processing is > defined later. We will rewrite this section to improve clarity and to eliminate redundancy. > > client-return-address The IPv6 source address in which the > > message from the client was received by > > the relay agent > > Pick a better name than "client-return-address"? Perhaps just say > "client-address"? It *is* the client address (or say > 'client-ll-address" with ll for link-local? We will use "client-address". > > client-return-address The source address from the IP datagram > > in which the message from the client was > > received by the relay agent > > > > Better to just say "copied from "relay-forward" message, since that is > what is infact supposed to happen. Agreed. > > 10. Representation and use of domain names > > > > So that domain names may be encoded uniformly and compactly, a > > domain name or a list of domain names is encoded using the technique > > described in sections 3.1 and 4.1.4 of RFC1035 [14]. Section 4.1.4 > > of RFC1035 describes how more than one domain name can be represented > > in a list of domain names. For use in this specification, in a > > list of domain names, the compression pointer (see section 4.1.4 of > > RFC1035) refers to the offset within the list. > > > > If a single domain name is being used by a vendor as a vendor > > identifier, then the vendor MUST ensure that the domain name has not > > previously been used by a different vendor. > > This section seems out of place here. Middle of nowhere with no > context. But, I think it should all be deleted. Rather than using DNS > names, use Enterprise Identifiers. > > http://www.isi.edu/in-notes/iana/assignments/enterprise-numbers We weren't sure if you meant all of section 10 or just the second paragraph is out of place. The section is here because the encoding is used in the definition of the vendor-assigned DUID in the next section. The second paragraph should be moved down into section 11.3 on vendor-assigned DUID. We will define a new DUID that uses Enterprise Identifiers. > > Clients and servers that use this DUID SHOULD attempt to configure > > the time prior to generating the DUID, if that is possible, and MUST > > use some sort of time source (e.g., a real-time clock) in generating > > the DUID, even if that time source could not be configured prior to > > generating the DUID. The use of a time source makes it unlikely that > > two identical DUIDs will be generated if the network interface is > > removed from the client and another client then uses the same network > > interface to generate a DUID. A DUID collision is very unlikely even > > if the clocks haven't been configured prior to generating the DUID. > > It might be good to in this section make clear that the Time is not > really required to be a time, but is just an attempt to ensure that if > two nodes generate a DUID from *this* link-layer address, they are > likely to generate different "time values". That is what the actual > requirement seems to be. (Author consensus: no changes required here.) We will retain the use of an explicit time value in this DUID. Other DUIDs are available for clients that cannot generate a time value. > > The source of the identifier is left up to the vendor defining it, > > but each identifier part of each VUID MUST be unique to the device > > that is using it, and MUST be assigned to the device at the time of > > manufacture and stored in some form of non-volatile storage. The > > VUID SHOULD be recorded in non-erasable storage. The domain name > > is simply any domain name that has been legally registered by the > > vendor in the domain name system [13], stored in the form described > > in section 10. > > Use the Enterprise Number instead? See above. > > This type of DUID consists of two octets containing the DUID type 3, > > a two octet network hardware type code, followed by the link-layer > > address of any one network interface that is permanently connected > > to the client or server device and cannot be removed. The hardware > > type MUST be a valid hardware type assigned by the IANA as described > > in the section on ARP in RFC 826. The hardware type is stored in > > network order. > > Clarify what "cannot be removed" means. For example do you mean to > say "a built in chip on the motherboard that is unlikely to be removed > and used elsewhere". or something like that? Your text is the right idea and we will fix the spec appropriately. > Finally, it would be good to give guidelines on which of the DUIDs you > expect folks to use under what conditions. There is none at present. The sections describing the DUIDs each has a closing paragraph that describes when that DUID should be used. Do we need more? > > A client must associate at least one distinct IA with each of > > its network interfaces and uses that IA to obtain configuration > > information from a server for that interface. Other distinct IAs may > > be associated with applications. Each IA must be associated with > > exactly one interface. > > Perhaps remove that reference to "applications"? We don't disallow > this, but I think its confusing to mention it. We will delete the sentence with the reference to "applications". > > The configuration information in an IA consists of one or more IPv6 > > addresses and other parameters. The parameters are specified as DHCP > > Which parameters are associated with an IA as opposed to the client as > a whole (or more specifically, with a particular network link)? I > don't think the document talks about this point at all. DHCPv6 can't really speak to the ways in which a client might choose to use the parameters. > > An address whose valid lifetime has expired MAY be discarded from the > > IA. > > What does this mean? Why does it need to be said? We will delete this sentence. > > A server selects addresses to be assigned to an IA according to the > > address assignment policies determined by the server administrator > > and the specific information the server determines about the client > > from the following sources: > > s/from the/from some combination of the/ ? OK. > > - If the server receives the message directly from the client and > > the source address in the IP datagram in which the message was > > received is not a link-local address, then the client is on the > > link identified by the source address in the IP datagram (note > > that this situation can occur only if the server has enabled the > > use of unicast message delivery by the client and the client has > > sent a message for which unicast delivery is allowed) > > Move this text up to immediately after: > > > * If the server receives the message from a forwarding relay > > agent, then the client is on the same link as the one to > > which the interface identified by the link-address field in > > the message from the relay is attached > > It seems to fit there better. Agreed. > > The addresses that the server selects for the client MUST be valid on > > the link to which the interface is attached, regardless of the way in > > which the server selects the addresses. > > Too strong? what about tunnels? remote access scenarios? (Author consensus: Last sentence to be deleted) The tunnel is the link, so an assigned tunnel endpoint is valid for the link to which it's assigned. Three out of four of us think it's OK to delete this sentence. > > 14. Management of temporary addresses > > > > Clients ask for temporary addresses and servers assign them. When > > a client sends an IA to a server, the client lists all of the > > temporary addresses it knows about and optionally indicates how many > > additional temporary addresses it wants in the Requested Temporary > > Addresses Option(see section 23.6). The server compares the number > > of requested additional temporary addresses against any previously > > allocated temporary addresses for the IA that were not reported > > by the client in the IA but still have some reasonable preferred > > lifetime left. If the number of temporary addresses is less than the > > requested number, the server adds additional temporary addresses to > > the IA to satisfy the requested number (subject to server policy). > > > > DISCUSSION: > > > > It is important that the server include any allocated > > temporary addresses that were not reported by the client as > > it is possible the client never received an earlier Reply > > that contained these additional temporary addresses. If > > the server did not consider these, a client that fails to > > receive a server's reply might cause the server to allocate > > many temporary addresses. > > The above seems a bit confusing and maybe unclear. My understanding is > that the client requests a number of addresses. I think that model > runs the risk of the client and server getting confused. Maybe a > better model for temp addresses is that the client requests them > indidually as sets, rather than by saying "how many" it wants. That > is, it requests them individually, one at a time, using a separate IA > to indentify them. This corresponds to a simple model where the client > decides how its using them and when, and just says it wants a new set > (or to extend the lease on a current set) or to release one it had > already used. Maybe we should talk about this. (Author consensus: Use this summary from Bernie) 1. The IA Option would be used for "regular" (non-temporary) addresses only. 2. A new IA Option for temporary addresses would be created. This option would NOT need T1 and T2 times as temporary addresses are not renewable. Vijay had proposed a format for this as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_TMP_IA | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IA Status | | +-+-+-+-+-+-+-+-+ | . Options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_TMP_IA (TBD) option-len See section 23. IAID The unique identifier for this TMP_IA. IA status Status of the IA in this option. options Options associated with this IA. Each TMP_IA option can carry one "set" of temporary addresses (in the IA_Address Options). Essentially, a "set" refers to ONE temporary address per each prefix for a link - not multiple temporary addresses on a single prefix. This supports the case where there are several global prefixes on a single link such as in the multi-homed case. When a client wants multiple temporary addresses, it must Request them using a new IAID. We might want to state that the TMP_IA option MUST NOT appear in a Renew or Rebind message? Or, should we allow these there to piggyback a request for a new temporary address with a normal renewal operation? I just don't view these events as very likely to occur simultaneously so I'm not sure if there is much value? But, on the other hand being flexible may be good. I'm inclined to require them in Confirms as a client might *JUST* ask for temporary addresses and need to know if it is still on the same link and thus can continue using the addresses (until the lifetime expires). After all, if it just crashed and rebooted, it may still want to carry on some transaction it initiated before crashing using the same temporary address. Or, the lifetime on the non-temporary addresses may have expired but not on the temporary while it was down? We may want to document Solicit / Advertise behavior. I don't think a client that wants to potentially get temporary addresses down the road needs to Solicit this. However, a client may ONLY want temporary addresses and hence many want to Solicit with just these. Anyway, we should discuss and resolve the exact rules regarding the TMP_IA (perhaps we don't need to go into significant detail but ...)? 3. IAID values would be unique within an IA option type PER client. So, IAID of 0 for an IA Option and IAID of 0 for a TMP_IA option are two different IA numbers. This avoids some issues with these numbers. 4. The RTA Option is dropped as it is no longer needed. If the client wants 5 (sets of) temporary addresses active at time, it must send 5 TMP_IA options with 5 unique IAIDs for those options. 5. Drop the "T" bit in the "addr status" field of the IA Address option. Make the addr status field an 8-bit status code. I probably forgot something ... and I'm sure you'd ideally like text to cut and paste. In addition, I'd recommend having a new DSTM_IA option that is basically the same as the IA Option. The DSTM IAID follows the same rules (it a totally separate number space from the IA Option and TMP_IA option). Of course, this is a different draft and we can update it after dealing with -23. > > The client retransmission behavior is controlled and described by the > > following variables: > > > > RT Retransmission timeout > > > > IRT Initial retransmission time > > > > MRC Maximum retransmission count > > > > MRT Maximum retransmission time > > > > MRD Maximum retransmission duration > > > > RAND Randomization factor > > I assume that none of the above are configurable? I.e, implementations > aren't required to support admins reconfiguring these? These variables are used to describe the timeout and retransmission behavior and are not configurable. > > Clients MUST discard any received messages that include > > authentication information and fail the authentication check by the > > client, except as noted in section 22.6.5.2. > > Seems like the client per its own policy, decides when to accept > unauthenticated packets. Agreed. > > 16. Message validation > > I don't think this section is so useful standalone. It would probably > be more clear to just put the individual subsections in the place in > the document where you deal with processing incoming messages. In > some cases, for example, those section add more checks than what you > have listed here. (Author consensus: Leave chapter 16 where it is; check for correctness and completeness) Some validation checks don't really fit elsewhere; authors will retain the current organization. > > Relay agents MUST discard any Solicit messages received through port > > 546. > > the wording "received through" is not clear. Better to say something > like "received with destintation port 546" (if that is the > intent). Fix this throughout. Agreed. > > Servers MAY choose to discard any received Information-request > > messages that do not include a Client Identifier option. > > then later: > > > The client SHOULD include a Client Identifier option to identify > > itself to the server. If the client does not include a Client > > Identifier option, the server will not be able to return any > > client-specific options to the client. > > Even worse, the server may drop the request. This seems like a > potential problem area. Better to give stronger guideance on whether > the server really can drop these, since client is only a SHOULD. Or > should that be a MUST? (Author consensus: Rewrite for clarity) Authors will clarify the text to specify that if the client does not include a Client Identifier, the best the server can return is options that are not customized to the client, and the server may have a policy of not replying at all to messages without a client identifier. > > > addresses for which the client has a preference. The client MAY > > include an Option Request Option in the Solicit message. The client > > MUST NOT include any other options except those specifically allowed > > as defined by specific options. > > Seems like it would be useful to allow servers to send options that > the client didn't request, so long as they are just ignored if not > understood. Or, shouldn't the client just be required to include the > ORO in the solicit? I'm thinking of ease of deployment issues > here. Are the semantics here inherited from DHCPv4 (i.e, under > assumptions that may not hold for DHCPv6?) Agreed; we will clarify the verbiage to clarify this issue. > > The first Solicit message from the client on the interface MUST > > be delayed by a random amount of time between MIN_SOL_DELAY and > > MAX_SOL_DELAY. This random delay desynchronizes clients which start > > at the same time (e.g., after a power outage). > > This delay should be tied to specific actions in the ND spec, i.e., > after receipt of an RA that say 'use dhc'. See RFC 2461. Agreed. > > A client MUST collect Advertise messages for IRT seconds, unless > > it receives an Advertise message with a preference value of 255. > > The preference value is carried in the Preference option (section > > 23.8). Any Solicit that does not include a Preference option is > > considered to have a preference value of 0. If the client receives > > an Advertise message with a preference value of 255, then the client > > MAY act immediately on that Advertise message without waiting for any > > additional Advertise messages. > > Last MAY seems like it should be a SHOULD. MAY isn't helpful. Agreed. > > 18.1.3. Receipt of Advertise messages > > Seems like the message checks in 16.3 should just go here. See earlier response. > > Once a client has selected Advertise message(s), the client will > > typically store information about each server, such as server > > preference value, addresses advertised, when the advertisement was > > received, and so on. Depending on the requirements of the user that > > invoked the DHCP client, the client MAY initiate a configuration > > exchange with the server(s) immediately, or MAY defer this exchange > > until later. > > This last MAY seems like it might lead implementors to just skip the > "wait until you get a bunch of responds then pick one", which woudl be > bad. More text to say when this MAY should be invoked? The preference value 255 gives the net admin a way to bypass the Advertise collection step so the last sentence is not needed; we will delete it. > > The server MUST include IA options in the Advertise message > > containing any addresses that would be assigned to IAs contained in > > the Solicit message from the client. The server MAY include some or > > all of the IA options from the client in the Advertise message. > > Clarify. last sentence seems to be different than previous one. Can a > server not include an IA the client requested? Seems like it can't, > but that the IA might be empty (can't assign addresses). Right? We will delete the second sentence. > > If the server will not assign any addresses to IAs in a subsequent > > Request from the client, the server SHOULD either send an Advertise > > message to the client that includes only a status code option with > > the status code set to AddrUnavail and a status message for the user > > or not respond to the Solicit message. > > SHOULD? You want it clear what is to be done. Also, there is a choice > here. Which one should be done under which circumstances? If its just > left to implementors, will something reasonable happen? We will change SHOULD to MUST and delete the alternative. > > 19. DHCP Client-Initiated Configuration Exchange > > > > A client initiates a message exchange with a server or servers to > > acquire or update configuration information of interest. The client > > may initiate the configuration exchange as part of the operating > > system configuration process or when requested to do so by the > > application layer. > > Also, when addresses are about to expire. We will add text to include Rebind and Renew time. > > Advertise messages for use in constructing Request messages. Note > > that a client may request configuration information from one or more > > servers at any time. > > Do we need to include this last sentence? I think this may be > confusing. Or would it make sense to just say (somewhere in its own > paragraph/section) that the DHCP mechanisms allow one to query multiple > servers simultaneoiusly, but that the exploitation of that is future > work and is not needed for basic clients. Basic clients will just be > conversing with one server. We will delete the second sentence. > > e. g., servers that responded with an Advertise message > > spacing We'll figure out how to make LaTeX do the right thing here. > > The client SHOULD respond to the server with a Release message for > > any addresses in the Reply message that have a valid lifetime of 0. > > The client constructs and transmits this message as described in > > section 19.1.7. > > why SHOULD vs. MUST? Also, this doesn't seem like an overloading of > semantics. If the server is saying the Lifetime is 0, then it is > 0. Right? Why doesn't the client just accept that as fact? Agreed that this requirement is superfluous; we will delete it. > > If the Reply was received in response to a Renew or Rebind message, > > the client must update the information in any IA option contained in > > the Reply message. The client adds any new addresses from the IA > > option to the IA, updates lifetimes for existing addresses in the IA > > from the IA option and discards any addresses with a lifetime of zero > > in the IA option. > > Is an lifetime of 0 supposed to indicate "request denied" for that > address, or is it supposed to mean "although the address was valid at > one point, its current lifetime is 0". Seems like the two cases might > not be the same, and you should use differnet messages/codes to > distinguish. The server indicates "request denied" by returning the current remaining lifetime. The server indicates "stop using this address immediately" by returning lifetime 0. Do we need some additional text to clarify? > > When the client receives a NoBinding status in an IA from the server > > for a Confirm message the client can assume it needs to send a > > Request to reestablish an IA with the server. > > Clarify: what are the next steps a client needs to take? We will rewrite this as follows: When the client receives a NoBinding status in an Ia from the server for a Confirm message, the client sends a Solicit message to locate a server that is willing to configure the IA for the client. > > > When the client receives a ConfNoMatch status in an IA from the > > server for a Confirm message the client can send a Renew message to > > the server to extend the lifetimes of the addresses. > > This seems confusing. Maybe if I understood better the difference > between Confirm and Renew, this would be clear. We will delete this paragraph. > > A client MAY choose to wait for a Reply message from the server in > > response to the Release message. If the client does wait for a > > Reply, the client MAY choose to retransmit the Release message. > > Shouldn't this be a SHOULD? We will rewrite this paragraph to read: The client SHOULD choose to guarantee the delivery of the Release message using the retransmission strategy in section 15. An example of a situation in which a client would not guarantee delivery would be when the client is powering down or restarting because of some error condition. The paragraph immediately following this paragraph in 19.1.7 gives the retransmission parameters. > > 19.2.1. Receipt of Request messages > > > > The server MAY choose to discard Request messages received via > > unicast from a client to which the server has not sent a unicast > > option. > > Better to always respond, but include an indication of "go through > relay agent"? We will change to: When the server receives a Request message via unicast from a client to which the server has not sent a unicast option, the server responds with a Request message containing a status code UseRelayAgent. > > When the server receives a Request the client is requesting the > > configuration of a new IA by the server. The server MUST take the > > Strictly speaking, not "a new IA". Maybe the IA exists already from > before... Agreed. > > configuration of a new IA by the server. The server MUST take the > > IA from the client and associate a binding for that client in an > > implementation-specific manner within the configuration parameter > > database for DHCP clients managed by the server. > > saying "implementation-sepecific manner" seems like poor words. You > mean, it will creates a binding according to its policy/config > information, etc. Agreed. > > The server SHOULD process each option for the client in an > > implementation-specific manner. The server MUST construct a Reply > > message containing the following values: > > First SHOULD seems like empty words. Second MUST seems silly to. Of > course one needs to respond to the message... Agreed. > > If the server finds that the prefix on one or more IP addresses in > > any IA in the message from the client is not a valid prefix for the > > link to which the client is connected, the server MUST return the IA > > to the client with the status field set to NoPrefixMatch. > > Wouldn't it be better then to call the return code "NotOnLink"? OK. > > If the server cannot assign any addresses to any of the IAs in > > the message from the client, the server SHOULD include the IAs in > > the Reply message with the status field set to AddrUnavail and no > > addresses in the IA. > > As opposed to doing what? I.e., SHOULD implies there may be alternate > response. What is it? We will change SHOULD to MUST. > > For any IAs to which the server can assign addresses, server includes > s/server/the server/ OK. > > the IA with addresses and other configuration parameters a status of > > Success, and add the IA as a new client binding. > s/add/adds/ OK. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Thu Apr 18 01:13:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17942 for ; Thu, 18 Apr 2002 01:13:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA19430 for dhcwg-archive@odin.ietf.org; Thu, 18 Apr 2002 01:13:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18482; Thu, 18 Apr 2002 01:11:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18395 for ; Thu, 18 Apr 2002 01:11:47 -0400 (EDT) Received: from corp2.cbn.net.id (corp2.cbn.net.id [202.158.3.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17881 for ; Thu, 18 Apr 2002 01:11:38 -0400 (EDT) Received: from cbn.net.id (unknown [202.158.63.159]) by corp2.cbn.net.id (Postfix) with ESMTP id 32A9685A6 for ; Thu, 18 Apr 2002 12:10:24 +0700 (WIT) Message-ID: <3CBE54BE.215550C5@cbn.net.id> Date: Thu, 18 Apr 2002 12:08:14 +0700 From: Aries Fajar X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: dhcwg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] message format Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Dear all, I'm new to dhcpv6 and still learning it. I'm confuse about the dhcp message. Can u give the full message dhcp request from the client to the server as an example ? draft-ietf-dhc-dhcpv6-23.txt is a little bit confusing about message format. I read a book about IPV6 that contains dhcpv6 ( very old, 1996 ) and i understand many have changed since then... so, from all my knowledge that i have acquired, this is my thinking about message request ------------------------------------------------ | 6 | 4 | flow label : 0 | ------------------------------------------------ | len:32 | nxt : 17 | hops : 9 | ------------------------------------------------ | | | Source : | | | |---------------------------------------------- | | | Dest : DHCP Server | | | ---------------------------------------------- | src port : 546 | dst port : 547 | ---------------------------------------------- | length : 96 | checksum | ---------------------------------------------- | request | 12345 | ---------------------------------------------- | options | ---------------------------------------------- so, what's in the options field ? after reading the RFC, there is no client network address in the udp message. how can the server send the reply message to the client, if it doesn't know about the client address ? I read the old draft ( draft-ietf-dhc-dhcpv6-15.txt ) and i find a more clearly message format. Here it is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type = 3 |C|R| reserved | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | client's link-local address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | relay-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | server-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extensions (variable number and length) .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where is it now ? is it somewhere at the options field ? Please help Thanks Aries Fajar Electrical Engineering Department Trisakti University Indonesia _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Apr 18 13:55:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17154 for ; Thu, 18 Apr 2002 13:55:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20169 for dhcwg-archive@odin.ietf.org; Thu, 18 Apr 2002 13:55:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19791; Thu, 18 Apr 2002 13:51:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19720 for ; Thu, 18 Apr 2002 13:51:10 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16933 for ; Thu, 18 Apr 2002 13:51:06 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-93.cisco.com [161.44.150.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA12609 for ; Thu, 18 Apr 2002 13:50:38 -0400 (EDT) Message-Id: <4.3.2.7.2.20020418134908.0365def0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Apr 2002 13:50:37 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-23.txt and authors' response (part 2) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Here's the second part of Thomas Narten's comments, with the author's comments in line. We are still on schedule to publish the -24 rev of the draft on 4/19. - Ralph > > If the server cannot determine if the information in the Confirm > > message is valid or invalid, the server MUST NOT send a reply to the > > client. For example, if the server does not have a binding for the > > client, but the configuration information in the Confirm message > > appears valid, the server does not reply. > >Is it the case that the server should not reply because the intent >here is that another server (the correct one) will respond, and if >this one does, the client will get confused? Would it be good to just >say something like this, so it's clear why the MUST NOT applies? It's not so much that the client will get confused as that the server cannot respond definitively ACK or definitively NAK. We can add a sentence or a clause with additional explanation. > > The server SHOULD process each option for the client in an > > implementation-specific manner. The server MUST construct a Reply > >might be good to change the "implementation-specfic" wording. The >processing of each option should be clearly defined and not be >"implementation-specific". This wording appears in a lot of places. Agreed. > > The server MAY choose to discard Renew messages received via unicast > > from a client to which the server has not sent a unicast option. > >Would be good to say why/when. This isn't an arbitrary MAY (i.e., >implementation choice). Add: "..., for example, when the server requires options from the relay agent on the client's link." > > When the server receives a Renew and IA option from a client it > > SHOULD locate the clients binding and verify the information in the > > IA from the client matches the information stored for that client. > >SHOULD seems wrong. Isn't this a MUST. Also, why upper case? This is >just normal processing, I would think... Yeah; change to "...client, it locates the client's binding..." > > If the server cannot find a client entry for this IA the server > > SHOULD return an IA containing no addresses with status set to > > NoBinding. > >SHOULD as opposed to what? If this is the normal response, it >shouldn't be SHOULD (read the 2119 definition of SHOULD). I.e, why not >MUST? (and upper case wording seems overkill to me). Change to "...server returns an IA option containing..." >also "return an IA". Shouldn't this be "an IA for each IA in the >client's message"? Agreed. > > If the server cannot Renew addresses for the client it SHOULD send > > back an IA containing no addresses to the client with the status > > field set to AddrUnavail. > >SHOULD? as opposed to what? Will change to MUST. > > If the server finds the addresses in the IA for the client then the > > server SHOULD send back the IA to the client with new lifetimes and > >ditto. Edit to: If the server finds the addresses in the IA for the client then the server sends back the IA to the client with new lifetimes and > > The server SHOULD process each option for the client in an > > implementation-specific manner. The server MUST construct a Reply > > message containing the following values: > >first sentence could be worded better (this occurs multiple times in >the document). Also, use of MUST here seems silly. Can't you just say >"The server constructs..." I.e, this is normal processing. > >XXX overuse of MUST/SHOULD? Agreed - first sentence should be rewritten (not clear exactly what it means) and SHOULD/MUST are unneeded here. > > If the server finds that the addresses in the IA for the client > > do not match the client binding the server should return an IA > > containing no addresses with status set to RebdNoMatch. > > > > If the server cannot Rebind addresses for the client it SHOULD send > > back an IA containing no addresses to the client with the status > > field set to AddrUnavail. > >What is the difference between the two paragraphs above? Seems like >either would apply to the case where the server can't provide the >requested addresses... We will drop the second paragraph. > > When the server receives an Information-request message, the client > > is requesting configuration information that does not include > > the assignment of any addresses. The server SHOULD determine all > > configuration parameters appropriate to the client, based on the > > server configuration policies known to the server. > >SHOULD? As opposed to ... Change to "The server determines all...". > > The server MAY choose to discard Release messages received via > > unicast from a client to which the server has not sent a unicast > > option. > >Would be good to say under what conditions the MAY might be needed. We have the same issue for each message that can be unicast. I propose we apply the same fix (I think I suggested some text about the server requiring relay agent options) to the text for each of those messages. > > A server is not required to (but may choose to as an implementation > > strategy) retain any record of an IA from which all of the addresses > > have been released. > >Hmm... more words? What is the intent here? And, shouldn't the >document include some words discouraging reusing the same address for >a new client *immediately*? I.e., don't we want the same address to be >returned in most cases, even if the client goes away for a few days? We will change the text to: A server may choose to retain a record of assigned addresses and IAs after the lifetimes on the addresses have expired to allow the server to reassign the previously assigned addresses to a client. > > the addresses from the IAs. The server SHOULD mark the addresses > > declined by the client so that those addresses are not assigned to > > other clients, and MAY choose to make a notification that addresses > > were declined. > >Wording above could be stronger. If the declined address is a >duplicate, it shouldn't be used any more. The wording could make this >stronger above. We don't think the wording needs to be stronger. > > exchange when links in the DHCP domain are to be renumbered. Other > > examples include changes in the location of directory servers, > > addition of new services such as printing, and availability of new > > software (system or application). > >Do you have an example of the latter? If not, drop the example? We will drop the phrase in parentheses. > > The server sets the "msg-type" field to RECONFIGURE. The server > > generates a transaction-ID and inserts it in the "transaction-ID" > > field. The server places its identifier in a Server Identifier > > option. > >Hmm. The client doesn't echo this back to the server. Does it matter >what id the server uses? I think not. Except the retransmissions use >the same ID, new ones don't. But its not really used. We will change this to make the transaction-id MBZ in this message. > > The server MUST include an authentication option with the appropriate > > settings and add that option as the last option in the "options" > > field of the Reconfigure message. > >So, authentication is mandatory to implement. We really need a mode >where the server is authenticated. I don't understand the comment - the authentication mechanism authenticates both the client and the server. We will remove the restriction that the option be the last option in the message. Placement of the authentication option will be specified in the section on authentication. > > It is possible that the client may send a Renew message after the > > server has sent a Reconfigure but before the Reconfigure is received > > by the client. In this case, the Renew message from the client > > may not include all of the IAs and requests for parameters to be > > reconfigured by the server. To accommodate this scenario, the server > > MAY choose to send a Reply with the IAs and other parameters to be > > reconfigured, even if those IAs and parameters were not in the Renew > > message from the client. > >This seems pretty ambiguous and unclear. I think we want very well >defined behavior here, not a "MAY". Can't this be simplified into a >clear rule? We will change the text to read: The server MAY choose to send IAs and other parameters to be reconfigured, even if those IAs and parameters were not in the Renew message from the client. > > 20.2. Receipt of Information-request messages > > > > If the server has assigned addresses to one or more IAs that belong > > to the responding client, the server MUST silently discard the > > Information-request message. > >Why? Seems unrobust. Will the client now get no responses and >retransmit? Better to include an error, or return the requested info >(perhaps with a code indicating, BTW, I have addresses but didn't >include them...) We will delete this sentence. > > It is possible that the client may send an Information-request > > message after the server has sent a Reconfigure but before > > the Reconfigure is received by the client. In this case, the > > Information-request message from the client may not request all of > > the parameters to be reconfigured by the server. To accommodate > > this scenario, the server MAY choose to send a Reply with the other > > parameters to be reconfigured, even if those parameters were not > > specified in the Information-request message from the client. > >Same comment as before. This seems ripe for ambiguity and >ineroperability problems. > >Why not just require the last sentence be the standard behavior? We will edit this text to: The server MAY choose to send IAs and other parameters to be reconfigured, even if those IAs and parameters were not in the Renew message from the client. > > A client MUST always monitor UDP port 546 for Reconfigure messages > > on interfaces for which it has acquired DHCP parameters. Since the > >Wording could be better. Do you mean "MUST accept packets sent to port >546. These packets may be sent at any time." ? We will edit the text to: A client MUST accept Reconfigure messages sent to UDP port 546 on interfaces for which it has acquired configuration information through DHCP. These messages may be sent at any time. Since the results of a reconfiguration event may affect application layer programs, the client SHOULD log these events, and MAY notify these programs of the change through an implementation-specific interface. > > Upon receipt of a valid Reconfigure message, the client initiates a > > transaction with the server. While the transaction is in progress, > > the client silently discards any Reconfigure messages it receives. > >What kind of transaction is initiated? Add text specifying Renew or Information-Request. > > If the client has IAs with addresses that have been assigned by the > > server from which the Reconfigure message was received, the client > > MUST respond with a Renew message. Otherwise, the client responds > > with an Information-request message. > >Would it be clearer for the reconfigure to have a flag (or two) that >says "just addresses" and/or "just other parameters"? This way there >is no guessing about how the client needs to respond. We will define an option that specifies whether a client should respond to a Reconfigure message with a Renew or an Information-request message. > > If the configuration parameters changed were requested by the > > application layer, the client notifies the application layer of the > > changes using an implementation-specific interface. > >Hmm. Is this a requirement with some big unstated implications? >Might be better to remove this wording. At best, it is a MAY. We will delete this paragraph. > > 21. Relay Behavior > > > > For this discussion, the Relay MAY be configured to use a list of > > server destination addresses, which MAY include unicast addresses, > > the All_DHCP_Servers multicast address, or other multicast addresses > > selected by the network administrator. If the Relay has not been > > explicitly configured, it MUST use the All_DHCP_Servers multicast > > address as the default. > >There should be some clear MUST rules on what is required of relay in >terms of configuration. I.e., isn't the first MAY a de facto MUST in >IPv4? The multicast address is a default, and the implementation ought to allow configuration with other addresses. Does this text need to be clarified? > > When a Relay receives a valid client message, it constructs a > > Relay-forward message. The relay places an address with a prefix > > assigned to the link on which the client should be assigned an > > address in the link-address field. This address will be used by the > >reword: places a global or site-local address ... from the interface >on which the client packet was received... We will add text to specify that the address should be a global or site-local address. The remaining text in the sentence is OK. > > If the relay cannot use the address in the link-address field to > > identify the interface through which the response to the client will > > be forwarded, the relay MUST include an Interface-id option (see > > section 23.17) in the Relay-forward message. The server will include > > the Interface-id option in its Relay-reply message. > >MUST seems too strong. This option is used if it makes sense to. It >isn't required in some cases... The relay agent doesn't need to use the Interface-id option when it can otherwise identify the link to which the client is attached, which is what the first phrase is about. >Also, what gets placed in the link-address field if the Interface-id >option is included? The link-address field is still set with a prefix from the link. In some technologies, the prefix from the link is not sufficient to identify the physical interface to which the client is attached. > > 23.17. Interface-Id Option > >Seems underspecified. If this option is used, does the server use >it (rather than the client-return-address) to figure out which link >the client is on, and hence, what address pool to select an address >from? there are no words about what the server does with this option, >other than echo it back. We will add text stating clearly that this option is primarily for use by the relay agent in facilitating or expediting the return of the server's response to a client request. It is not used by the server to determine where the client is - the link-address field is used for that. >Also, should the text more clearly state that the relay removes this >option before forwarding the packet to the client? We will add text explicitly specifying that the relay agent discards any option in the message from the server when it unencapsulates and forwards the client message. > > message. The Relay MUST send the Relay-forward message to the list > > of server destination addresses with which it has been configured. > >MUST? but it's not clear that any server addresses have even been >configured (what is the requirement that this be done?) We will add text: "The Relay Agent MUST send the Relay-forward message to the list of server destination addresses with which it has been configured or to the All_DHCP_Servers multicast address if it was not explicitly configured with server destination addresses." > > 22.1. DHCP threat model > > > > The threat to DHCP is inherently an insider threat (assuming a > > properly configured network where DHCPv6 ports are blocked on the > > perimeter gateways of the enterprise). Regardless of the gateway > > configuration, however, the potential attacks by insiders and > > outsiders are the same. > >Note: this is somewhat at odds with the idea of a mobile node that can >still talk to its DHCP server about releasing addresses and such... We would say that a mobile node talking to its home DHCP server (or to its previous DHCP server) is still an "insider threat", as it must be, in some sense, a trusted member of the network to which the DHCP server belongs... > > The threat common to both the client and the server is the resource > > "denial of service" (DoS) attack. These attacks typically involve > > the exhaustion of valid addresses, or the exhaustion of CPU or > > network bandwidth, and are present anytime there is a shared > > resource. In current practice, redundancy mitigates DoS attacks the > > best. > >Not sure I understand the last sentence or necessarily even agree with >it. We will drop the last sentence. > > 22.2. Security of messages sent between servers and relay agents > > > > Relay agents and servers that choose to exchange messages securely > > use the IPsec mechanisms for IPv6 [10]. The way in which IPsec > > is employed by relay agents and servers is not specified in this > > document. > >If this is a MUST, please just say so. Also, do you want to scope >this? Is this just IPsec (with manual keying) or full IKE? It is not a requirement that relay agents and servers use any authentication. If relay agents and servers use IPsec, they may choose manual keying or IKE. > > 22.3. Summary of DHCP authentication > >Note: in this section and onwords, you talk about specific fields in >the option, but those fields have not even been described yet... this >is confusing. We will add a reference to the section in which the authentication option is defined. > > If the RDM field contains 0x00, the replay detection field MUST be > > set to the value of a monotonically increasing counter. Using a > > counter value such as the current time of day (e.g., an NTP-format > > timestamp [12]) can reduce the danger of replay attacks. This method > > MUST be supported by all protocols. > >MUST even in the stateless case? I would guess yes... We don't understand this comment... > > 22.5. Configuration token protocol > >I wonder if this should just be dropped as less than useful. Would be >better to have a public key based one? We will drop this protocol. The authors would gratefully accept the contribution of a public key authentication protocol > > Replay Detection - as defined by the RDM field > > K - a secret value shared between the source and > > destination of the message; each secret has a > > unique identifier (secret ID) > > secret ID - the unique identifier for the secret value > > used to generate the MAC for this message > > HMAC-MD5 - the MAC generating function. > >Show these fields? how big are they, for instance? Where in the packet >do these go? This problem will be fixed with a reference to the authentication option definition. > > to the replay detection method specified by the RDM field. Next, > > the receiver computes the MAC as described in [11]. The receiver > > MUST set the 'MAC' field of the authentication option to all 0s for > > computation of the MAC. If the MAC computed by the receiver does not > > match the MAC contained in the authentication option, the receiver > > MUST discard the DHCP message. > >This doesn't seem right. Earlier, the document says: > > > The sender computes the MAC using the HMAC generation algorithm [11] > > and the MD5 hash function [20]. The entire DHCP message (except > > the MAC field of the authentication option itself), including the > > DHCP message header and the options field, is used as input to the > > HMAC-MD5 computation function. The 'secret ID' field MUST be set to > > the identifier of the secret used to generate the MAC. > >I.e, the MAC field is not included. The receiver shouldn't check it >either. Agreed. > > Each DHCP server MUST know, or be able to obtain in a secure manner, > > the keys for all authorized clients. If all clients use the same > > key, clients can perform both entity and message authentication for > > all messages received from servers. However, the sharing of keys > > is strongly discouraged as it allows for unauthorized clients to > > masquerade as authorized clients by obtaining a copy of the shared > > key. To authenticate the identity of individual clients, each client > > MUST be configured with a unique key. > >Note, using a single shared key also allows trivial spoofing of the >server. (this should be mentioned). Agreed. >change last MUST to must? Agreed. > > A client MUST be configurable to discard unauthenticated messages, > > and SHOULD be configured by default to discard unauthenticated > > messages. A client MAY choose to differentiate between Advertise > > messages with no authentication information and Advertise messages > > that do not pass the validation test; for example, a client might > > accept the former and discard the latter. If a client does accept an > > unauthenticated message, the client SHOULD inform any local users and > > SHOULD log the event. > >Per the above, clients won't work out of the box. I.e, they must drop >unauthenticated stuff, but they also don't have any keying >material. Seems like a bad thing to specify... :-( We will change the text to read: SHOULD be configured by default to discard unauthenticated messages *if the client has been configured with an authentication key or other authentication information*. > > If the client authenticated the Advertise message through which the > > client selected the server, the client MUST generate authentication > > information for subsequent Request, Confirm, Renew, Rebind or Release > > messages sent to the server as described in section 22.6. When the > > client sends a subsequent message, it MUST use the same secret used > > by the server to generate the authentication information. > >Need better terminology than "same secret". you want it to use the >same "security association" I think, where SA could mean shared >secret, but also public/private, etc. This text is from the delayed authentication protocol using a shared key, so the text need not be generalized to "security association". We will change the text to read "same key". > > 22.6.5.4. Sending Information-request messages > > > > If the client has negotiated a secret with the server through a > > previous message exchange, the client MUST use the same secret used > > by the server to generate the authentication information. If the > > client has not negotiated a secret with the server, the client MUST > > use a secret that has been selected for the client through some > > external mechanism. > >Terminology? a "secret" has been "negotiated"? if the key is >negotiated, isn't this then a "session key"? Also, I don't think you >are really negotiating keys... > >Need to fix the "secret" terminology throughout I think. Agreed. >22.6.5.6. Receiving Reconfigure messages > > The client MUST validate the Reconfigure message from the server. > >What does this mean, and isn't this a requirement earlier per normal >processing rules? We will delete this sentence. > > The server uses the secret identified in the message and validates > > the message as specified in section 22.6.3. If the message fails to > > pass validation or the server does not know the secret identified by > > the 'secret ID' field, the server MUST discard the message and MAY > > choose to log the validation failure. > >What is the "secret ID" field? We will add a reference to authentication option section of the draft. > > 22.6.6.3. Sending Reconfigure messages > > > > The server MUST include authentication information in a Reconfigure > >Better to say "Authentication Option" ... Agreed. > > If the server has not previously negotiated a secret with the client, > > the server MUST use a secret that has been selected for the client > > through some external mechanism. > >"negotiated ... secret" terminology is odd. We will reword this text for clarity. > > described in section 23.1. All values in options is represented in > >s/is/are/ Agreed. > > option-code OPTION_CLIENTID (TBD) > >Go ahead and fill in the TBDs you create in this document. Then, in >the IANA considerations, just list them in a table and say "these are >the initial values for this name space". IANA provides values for >existing name spaces, but its OK to define them yourself if you are >creating the namespace for the first time. Do this throughout for the >TBDs. Agreed; we will put all numbers here in IANA section. > > The identity association option is used to carry an identity > > association, the parameters associated with the IA and the addresses > > assigned to the IA. > >s/assigned to/associated with/ ? Agreed. > > IAID The unique identifier for this IA. > >Would be good here to describe the properities the "uniqueness" needs >to satisfy. Agreed; in particular, the IAID must be unique across all of the client's links. > > T1 The time at which the client contacts the > > server from which the addresses in the IA > > were obtained to extend the lifetimes of the > > addresses assigned to the IA. > >Would be good here to describe the time units. > > > T2 The time at which the client contacts any > > available server to extend the lifetimes of > > the addresses assigned to the IA. > > > >ditto Agreed. > > IA status Status of the IA in this option. > >needs more explanation. Agreed. > > The server MUST set the T1 and T2 times to values that will allow > > the client to extend as appropriate the lifetimes of any addresses > > in the IA. If the server does not intend for a client to extend the > > lifetimes of a particular address in an IA, the server MAY set the > > renewal time values to occur after the lifetimes on that address > > expire. > >recommended guidelines would be good here. They should be such that >the T1 and T2 rules the client use will result in the address being >renewed before it expires, even if there are some errors (server >unavailable for a short amount of time, etc. We have IPv4 experience >here, just use the same guidelines I would think. Agreed. > > T1 is the time at which the client SHOULD begin the lifetime > > extension process by sending a Renew message to the server that > > originally assigned the addresses to the IA. T2 is the time at which > >why not MUST? We will change SHOULD to MUST. > > the client SHOULD start sending a Rebind message to any server. A > >ditto OK. > > client MAY begin the lifetime extension process prior to T1 if it > > needs additional addresses for some reason. > >don't follow. Renewing existing addresses is different than getting >"additional addresses" T1/T2 are for extending existing >lifetimes. Right? We will delete this text. > > 23.5. IA Address option > >IMO, this should be a suboption, not a regular option. This draft does not differentiate between options and sub-options. We will add text to the intro section on options to clarify the use of options. > > option-len See section 23. > >Better to just say what the len is in *this* case. This comment >applies to all the option descriptions. Agreed. > > addr status Status of this address in this IA. > >say what this is? What values can be returned? We will add text to specify what status codes are returned and why each status code is returned. > > prefix length Prefix length for this address. > >What is this and why is it needed? I suspect it would be better to not >need this. The client *shouldn't* know this information. > >I don't see any text right off that explains why this is needed or >how it is used. We will delete the prefix length field. > > lifetime fields for the preferred and valid lifetimes. The values in > > the preferred and valid lifetimes are the number of seconds remaining > > in each lifetime. > >Units of time should be defined earlier, where the field is initially >described. Agreed. > > 23.6. Requested Temporary Addresses (RTA) Option > >Per earlier comments, I think each temporary address should be >identified individually, rather than as a group (i.e., with >num-requested). We will make significant changes to the handling of temporary addresses. > > within an Identity association option. A client MUST only include > > this option when it wants to have additional temporary address > > allocated; a client SHOULD NOT send this option if 'num-requested' is > > 0. > >why not MUST NOT? This text will be deleted in the next draft because of changes to the handling of temporary addresses. >23.8. Preference option > >Seems to me like this should be in the header, i.e, fixed for easy >location. I'll note that the Client Identifier option is required to >be the first option (presumably so it can be located easily). But this >option is not? So a client needs to parse the entire message before it >can even decide whether to process it (i.e., select this message over >another one)? Seems like this should be the first option, or in the >fixed header. The preference option is only used in the Advertise message so we have not put it in the message header. Advertise messages are used relatively infrequently and only processed by clients so we don't need to worry (much) about scaling and processing efficiency. > > 23.9. Elapsed Time > >What is this option used for? Not immediately clear. Either get rid of >it, or explain what it is used for. We will add text explaining the use of the elapsed time option to allow a secondary DHCP server to respond to a request when a primary hasn't answered in a reasonable time. > > A client MAY include an Elapsed Time option in messages to indicate > >Is MAY appropriate? seems like it should be a MUST/SHOULD. I.e, here >is a client MAY include it, the server MAY act on it. Sounds like a >recipe for lack of usefulness do to lack of implementatoins. i.e, at >very least, servers MUST implement it. If they don't why would a >client ever bother including it? We will strengthen the text requiring this option... > > 23.12. Authentication option > > > > The Authentication option carries authentication information to > > authenticate the identity and contents of DHCP messages. The use of > > the Authentication option is described in section 22. If present, > > the Authentication option MUST appear as the first option in the DHCP > > message. > >Note. Does this document say whether the same option can be included >multiple times, and what the semantics of that would be? It needs to. Agreed. >Last sentence seems wrong. Shouldn't it be the *last* option? We want it first (or early) to allow a client (or server) to quickly determine whether it should process this message (whether it is authenticated). This doesn't mean it CAN'T be at the end, we should just point out that putting it early means a client or server can find it quickly to authenticate the message before having to parse all of the options. >Doesn't this option need a way to name security associations? I.e., a >way for the server/client to easily identify *which* keys are being >used? This seems to assume that the protocol/algorith is sufficient >for this. Seems to me this doesn't allow for the same >protocol/algorithm but different keys. Security associations are identified within the authentication information for a specific protocol. For example, the delayed authentication protocol includes a "Secret ID" which identifies the secret used to generate the MAC in a message. > > 23.13. Server unicast option > > > > The server MAY send this option to a client to indicate to the client > >s/MAY send/sends/ Agreed. > > messages in the server-address field. When a client receives this > > option, where permissible, the client MAY send messages directly to > > the server using the IPv6 address specified in the server-address > > field of the option. > >ditto on MAY. Also, add "as appropriate" to end of sentence? Agreed. > > 23.14. Status Code Option > > > > This option returns a status indication related to the DHCP message > > in which it appears. > >Only one of these may appear in a message? Yes; we will add text to specify that requirement. > > The data area of the user class option MUST contain one or more > > instances of user class data. Each instance of the user class data > > is formatted as follows: > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ > > | user class len | user class data | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ > >note: these are effectively sub options. Yet in other places, you >don't define sub-options. Rather you just use existing >options. Consistency? When one vs. the other? They may be effectively sub-options, but they are not DHCP options and are not formally defined anywhere. > > be used to process that User class option. Servers not equipped to > > interpret the user class information sent by a client MUST ignore it > > (although it may be reported). > >Isn't it the case that the server MUST ignore options it doesn't >understand in general? Better to say this once and be sure the text is >clear that it applies to all options. In fact, the last sentence is a cut-and-paste from the DHCPv4 user class option, which was added to the protocol in a separate RFC. We don't need the caveat in DHCPv6 because the option is defined in the base spec and all servers will be able to process it. > > vendor-id A domain name belonging to the vendor used to > > identify the vendor that defined this vendor > > class option. > >use the enterprise identifier? We will rewrite the Vendor-specific option and add a Vendor Class option. > > The Encapsulated vendor-specific options field MUST be encoded as > > a sequence of code/length/value fields of identical format to the > > DHCP options field. Each of the encapsulated options is formatted as > > follows. > >Mumble. Here you define yet a different sub-option format. Can't we >just do this once in a consistent manner? We will edit the sentence to read: "The Encapsulated vendor-specific options field is encoded using the same option-code/option-len/option-data format as the DHCP options, described in Section 23.1." We will add text that the option codes are assigned by the vendor and not managed by IANA. > > opt-code The code for the encapsulated option > >What is the numbering space for this option? I.e., is this a new name >space (and does it need an IANA section) or is this actually just a >normal option? I can't quite tell. Add text to indicate the number space is up to the vendor. > > 26.2. DHCPv6 message types > > > > IANA is requested to record the message types defined in section 7.3. > > IANA is requested to manage definition of additional message types in > > the future. > >Summarize what the initial values are and indicate what the rules are >for assigning new values. Ditto for remaining spaces in this section. Agreed. > > 27. Acknowledgments > >I suspect this needs updating. Aren't there some recent contributers (last >year or so) worth mentioning? I think I've added recent contributors - e.g., Thirumalesh Bhat, Vijayabhaskar, Mark Stapp (?) - are there others? > > Authors' Addresses > >Note that there is a new RFC editor policy in effect about long lists >of authors. Should there be a single editor listed on the cover page? >You should look at the RFC Editor policy on this. We should look at the policy (I don't think it has been formally published yet). On the other hand, we think that the list of authors is appropriate because of the particular history of this doc. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Apr 18 14:55:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19197 for ; Thu, 18 Apr 2002 14:55:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24888 for dhcwg-archive@odin.ietf.org; Thu, 18 Apr 2002 14:55:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24780; Thu, 18 Apr 2002 14:53:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24752 for ; Thu, 18 Apr 2002 14:53:55 -0400 (EDT) Received: from 3miasto.net (3miasto.net [217.96.12.59]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19121 for ; Thu, 18 Apr 2002 14:53:45 -0400 (EDT) Received: from scope (pc64.gdynia.sdi.tpnet.pl [213.77.131.64]) by 3miasto.net (8.11.6/8.11.6) with ESMTP id g3IIrbk22252 for ; Thu, 18 Apr 2002 20:53:41 +0200 Date: Thu, 18 Apr 2002 20:54:02 +0200 From: Artur Guja X-Mailer: The Bat! (v1.49) UNREG / CD5BF9353B3B7091 Reply-To: Artur Guja X-Priority: 3 (Normal) Message-ID: <962863607.20020418205402@3miasto.net> To: DHCWG List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Looking... Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hello DHCWG, I'm looking for people who tried to implement DHCPv6 on Linux. I'm doing it myself and would like to exchange some tips and knowledge, and this list seems to ignore such messages. Please, contact me off-list. Artur Guja PS: I understand that this list is for DHCP and not for implementation issues. Don't flame me for this. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Apr 18 18:39:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24805 for ; Thu, 18 Apr 2002 18:39:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA09793 for dhcwg-archive@odin.ietf.org; Thu, 18 Apr 2002 18:39:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09617; Thu, 18 Apr 2002 18:37:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20567 for ; Thu, 18 Apr 2002 14:00:05 -0400 (EDT) Received: from nscorp.com (gip-8-2.nscorp.com [167.121.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17285 for ; Thu, 18 Apr 2002 14:00:01 -0400 (EDT) Received: from svcs44.atldc.nscorp.com (svcs44-dmz [10.4.30.42]) by nscorp.com (8.9.2/8.9.3) with ESMTP id NAA22460 for ; Thu, 18 Apr 2002 13:59:03 -0400 (EDT) Received: from gaatlitexch03s.atldc.nscorp.com ([10.2.246.75]) by svcs44.atldc.nscorp.com (Netscape Messaging Server 4.15) with ESMTP id GURZBV00.10G for ; Thu, 18 Apr 2002 13:59:55 -0400 Received: by gaatlitexch03s.atldc.nscorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Apr 2002 13:59:15 -0400 Message-ID: From: "Handy, Norman W." To: "'dhcwg@ietf.org'" Date: Thu, 18 Apr 2002 13:59:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E702.BCDE2330" Subject: [dhcwg] Static IP's vs. DHCP for NT/Win2K servers Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E702.BCDE2330 Content-Type: text/plain My Distributed Systems Group is proposing using MAC address resolution and having DHCP assign IP's instead of using static ip's in our WinTel environment. What are the benefits and what are the drawbacks of using this type of scenario. We use over 180 WinTel servers (all Compaq and Dell) and all have static IP's. Any assistance will be greatly appreciated. Norman Handy Network Services Architecture Norfolk Southern Corporation ------_=_NextPart_001_01C1E702.BCDE2330 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

My Distributed Systems Group is proposing using MAC = address resolution and having DHCP assign IP's instead of using static ip's in our WinTel environment. What are the = benefits and what are the drawbacks of using this type of scenario. We use over 180 WinTel servers (all Compaq and Dell) and all have static IP's. Any assistance will be greatly appreciated.

Norman = Handy

Network Services Architecture =

Norfolk Southern = Corporation

------_=_NextPart_001_01C1E702.BCDE2330-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Apr 18 18:57:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25033 for ; Thu, 18 Apr 2002 18:57:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA10397 for dhcwg-archive@odin.ietf.org; Thu, 18 Apr 2002 18:57:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10341; Thu, 18 Apr 2002 18:56:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10183 for ; Thu, 18 Apr 2002 18:52:22 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24940 for ; Thu, 18 Apr 2002 18:52:18 -0400 (EDT) Received: from green.bisbee.fugue.com (user-2ive7ai.dialup.mindspring.com [165.247.29.82]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g3IMpwr07207; Thu, 18 Apr 2002 15:51:58 -0700 (PDT) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g3IMqQ203986; Thu, 18 Apr 2002 18:52:26 -0400 (EDT) Date: Thu, 18 Apr 2002 18:52:26 -0400 Subject: Re: [dhcwg] Static IP's vs. DHCP for NT/Win2K servers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "'dhcwg@ietf.org'" To: "Handy, Norman W." From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit In general, I wouldn't recommend doing this. You are adding a common point of failure to your system - if DHCP goes down for longer than half the lease interval, the servers will start to fail. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Thu Apr 18 20:09:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26170 for ; Thu, 18 Apr 2002 20:09:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA14034 for dhcwg-archive@odin.ietf.org; Thu, 18 Apr 2002 20:10:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13969; Thu, 18 Apr 2002 20:08:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13942 for ; Thu, 18 Apr 2002 20:08:35 -0400 (EDT) Received: from flounder.gibbons.com (sdsl-66-80-7-162.dsl.sca.megapath.net [66.80.7.162]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26112 for ; Thu, 18 Apr 2002 20:08:30 -0400 (EDT) Received: from gibbons.com (sdsl-66-80-7-180.dsl.sca.megapath.net [66.80.7.180]) by flounder.gibbons.com (8.11.2/8.11.2) with ESMTP id g3J08Ve26013 for ; Thu, 18 Apr 2002 17:08:31 -0700 Message-ID: <3CBF5FBA.143DFE40@gibbons.com> Date: Thu, 18 Apr 2002 17:07:22 -0700 From: bao X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dhcp Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] ddns-update-style and dhcp renewal Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit I followed the recommendation to use dhcp 3.01rc8. However, the config file for this version is not the same as that of 2.0xx. It requires the use of "ddns-update-style ...". What are the options for this line?? Currently, I have "ddns-update-style interim". This allows dhcp to start, however, it always complains in the log file about "Unable to add forward map from client.domain.com to server_ip: timed_out". The second problem i'm encountering is when a lease is going to be expired soon, the client owning the release requests for a renewal. This does not work and so the client loses its IP eventually. The log shows many DHCPREQUEST from client and DHCPACK from server. Although dhcp documenation says it's a must to have rules allowing broadcast packets (67 and 68) through the firewall, I don't have this enable and other machines (mostly 98) have no problem. The client having problem is an NT, while other NTs also work fine. Thanks for any pointers _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Thu Apr 18 20:13:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26284 for ; Thu, 18 Apr 2002 20:13:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA14260 for dhcwg-archive@odin.ietf.org; Thu, 18 Apr 2002 20:14:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14095; Thu, 18 Apr 2002 20:10:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10473 for ; Thu, 18 Apr 2002 18:59:44 -0400 (EDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25068; Thu, 18 Apr 2002 18:59:39 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g3IMxXm13524; Thu, 18 Apr 2002 15:59:34 -0700 (PDT) Message-Id: <200204182259.g3IMxXm13524@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, dhcwg@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 18 Apr 2002 15:59:33 -0700 From: RFC Editor Subject: [dhcwg] RFC 3256 on The DOCSIS Device Class DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3256 Title: The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option Author(s): D. Jones, R. Woundy Status: Standards Track Date: April 2002 Mailbox: doug@yas.com, rwoundy@broadband.att.com Pages: 5 Characters: 8551 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-agentoptions-device-class-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3256.txt This document proposes a new sub-option to the DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Option. This new sub-option is for use with DOCSIS (Data-Over-Cable Service Interface Specifications) cable modems and describes a "device class" to which the cable modem belongs. The cable modem signals its device class information to the Relay Agent using DOCSIS signaling, and the Relay Agent forwards the device class information to the DHCP Server which can then make a policy decision based on it. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020418155752.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3256 --OtherAccess Content-Type: Message/External-body; name="rfc3256.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020418155752.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Thu Apr 18 20:28:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26410 for ; Thu, 18 Apr 2002 20:28:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA14769 for dhcwg-archive@odin.ietf.org; Thu, 18 Apr 2002 20:28:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14660; Thu, 18 Apr 2002 20:26:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14511 for ; Thu, 18 Apr 2002 20:20:38 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26308 for ; Thu, 18 Apr 2002 20:20:33 -0400 (EDT) Received: from green.bisbee.fugue.com (user-2ive7ai.dialup.mindspring.com [165.247.29.82]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g3J0KFr07356; Thu, 18 Apr 2002 17:20:16 -0700 (PDT) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g3J0Ki204006; Thu, 18 Apr 2002 20:20:44 -0400 (EDT) Date: Thu, 18 Apr 2002 20:20:43 -0400 Subject: Re: [dhcwg] ddns-update-style and dhcp renewal Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: Dhcp To: bao From: Ted Lemon In-Reply-To: <3CBF5FBA.143DFE40@gibbons.com> Message-Id: <49B77537-532B-11D6-A092-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit The dhcpd.conf man page describes the possible values for ddns-update-style. You probably want 'none'. If you are trying to renew across a firewall, and it's not working, it's probably because the firewall is blocking some of the packets. If you deliberately chose not to follow the directions, there is some chance that this choice is what is causing the problem, although I will admit that the way you've described it, that doesn't seem to be the problem. But please try following the instructions exactly and see if that fixes the problem. If you have further questions, please ask them on the dhcp-server@isc.org mailing list - this is the IETF DHC working group mailing list, which exists to discuss the DHCP protocol, not specific implementations of the protocol such as the ISC DHCP server. :'/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Fri Apr 19 04:46:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13671 for ; Fri, 19 Apr 2002 04:46:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA23784 for dhcwg-archive@odin.ietf.org; Fri, 19 Apr 2002 04:46:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23649; Fri, 19 Apr 2002 04:44:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23632 for ; Fri, 19 Apr 2002 04:44:41 -0400 (EDT) Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13629 for ; Fri, 19 Apr 2002 04:44:32 -0400 (EDT) Received: from there ([193.12.201.10]) by fep01-svc.swip.net with SMTP id <20020419084404.GXUB72.fep01-svc.swip.net@there> for ; Fri, 19 Apr 2002 10:44:04 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: dhcwg@ietf.org Subject: Re: [dhcwg] RFC 3256 on The DOCSIS Device Class DHCP Date: Fri, 19 Apr 2002 10:50:13 +0200 X-Mailer: KMail [version 1.3.2] References: <200204182259.g3IMxXm13524@gamma.isi.edu> In-Reply-To: <200204182259.g3IMxXm13524@gamma.isi.edu> MIME-Version: 1.0 Message-Id: <20020419084404.GXUB72.fep01-svc.swip.net@there> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA23633 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit We have at least one customer making policy decisions on the server based on the Class Identifier (option 60) value. Apparently, it's always "docsis1.0" for a DOCSIS cable-modem. (Not sure about docsis 1.1). But even though this method appears to work fine in practice, I welcome this new draft because of the security aspect, as well as the possibility for future expansion using the reserved bits. I think it's important to let a trusted device give us as much information as possible about the clients we're servicing. So important, in fact, that I have wondered about the possibility of *requiring* *any* kind of relay agent (DOCSIS or not) to insert option 82, with information about the originating machine (hwtype-mac, for example). The premise being that even in corporations, most routers are trusted equipment, usually locked away in a basement somewhere. Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 70 566 7803 fax: +46 8 758 3687 mailto:budm@weird-solutions.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Fri Apr 19 07:31:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16337 for ; Fri, 19 Apr 2002 07:31:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA03334 for dhcwg-archive@odin.ietf.org; Fri, 19 Apr 2002 07:31:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02473; Fri, 19 Apr 2002 07:22:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02456 for ; Fri, 19 Apr 2002 07:22:02 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15833 for ; Fri, 19 Apr 2002 07:22:00 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3JBLqs7028156 for ; Fri, 19 Apr 2002 13:21:52 +0200 (MEST) Received: FROM esealnt135.al.sw.ericsson.se BY esealnt461 ; Fri Apr 19 13:19:32 2002 +0200 Received: by esealnt135.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2298H7W9>; Fri, 19 Apr 2002 13:06:33 +0200 Message-ID: <1254192C94D3D411B8060008C7E6AEEBF9DD5C@esealnt408> From: =?iso-8859-1?Q?Tony_Lindstr=F6m_=28ERA=29?= To: "'dhcwg@ietf.org'" Date: Fri, 19 Apr 2002 13:20:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] RE: Comments on draft-ietf-dhc-dhcpv6-23.txt and authors' respons e Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I disagree to drop the second paragraph in the handling of the Rebind message. > > > If the server finds that the addresses in the IA for the client > > > do not match the client binding the server should return an IA > > > containing no addresses with status set to RebdNoMatch. > > > > > > If the server cannot Rebind addresses for the client it SHOULD send > > > back an IA containing no addresses to the client with the status > > > field set to AddrUnavail. > > > >What is the difference between the two paragraphs above? Seems like > >either would apply to the case where the server can't provide the > >requested addresses... >We will drop the second paragraph. I though the idea was to check a Rebind(/Renew) in three levels. 1. Check the client entry (Client_ID and IA ). If the it does not exist send NoBinding. 2. Check the client address with the stored address for the client. If it does not match send RebdNoMatch. 3. Check the client address with the configuration (if re-configuration has occurred during the time). If it does not match send AddrUnavail. (All three fault cases are only valid if ALL addresses received from the client for the IA are wrong.) If you still want to drop the paragraph, please be consistent and drop it in Renew message too. / Tony _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Fri Apr 19 11:26:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23672 for ; Fri, 19 Apr 2002 11:26:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18836 for dhcwg-archive@odin.ietf.org; Fri, 19 Apr 2002 11:26:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18326; Fri, 19 Apr 2002 11:22:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18303 for ; Fri, 19 Apr 2002 11:22:04 -0400 (EDT) Received: from portal.incognito.com (PORTAL.INCOGNITO.COM [207.102.214.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23401 for ; Fri, 19 Apr 2002 11:22:00 -0400 (EDT) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by portal.incognito.com with smtp (Exim 3.33 #1) id 16ya9D-00032N-00; Fri, 19 Apr 2002 08:18:03 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <2ZV8RM2P>; Fri, 19 Apr 2002 08:28:24 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D1984956B9@homer.incognito.com.> From: "Kostur, Andre" To: "'Bud Millwood'" , dhcwg@ietf.org Subject: RE: [dhcwg] RFC 3256 on The DOCSIS Device Class DHCP Date: Fri, 19 Apr 2002 08:28:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E7B6.D76E9FE0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E7B6.D76E9FE0 Content-Type: text/plain; charset="iso-8859-1" You could simply configure your DHCP server to ignore requests which don't have option 82.... > -----Original Message----- > From: Bud Millwood [mailto:budm@weird-solutions.com] > Sent: Friday, April 19, 2002 1:50 AM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] RFC 3256 on The DOCSIS Device Class DHCP > > > We have at least one customer making policy decisions on the > server based on > the Class Identifier (option 60) value. Apparently, it's > always "docsis1.0" > for a DOCSIS cable-modem. (Not sure about docsis 1.1). > > But even though this method appears to work fine in practice, > I welcome this > new draft because of the security aspect, as well as the > possibility for > future expansion using the reserved bits. > > I think it's important to let a trusted device give us as > much information as > possible about the clients we're servicing. So important, in > fact, that I > have wondered about the possibility of *requiring* *any* kind > of relay agent > (DOCSIS or not) to insert option 82, with information about > the originating > machine (hwtype-mac, for example). The premise being that even in > corporations, most routers are trusted equipment, usually > locked away in a > basement somewhere. > > Bud Millwood > Weird Solutions, Inc. > http://www.weird-solutions.com > tel: +46 70 566 7803 > fax: +46 8 758 3687 > mailto:budm@weird-solutions.com > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > ------_=_NextPart_001_01C1E7B6.D76E9FE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] RFC 3256 on The DOCSIS Device Class DHCP

You could simply configure your DHCP server to ignore = requests which don't have option 82....

> -----Original Message-----
> From: Bud Millwood [mailto:budm@weird-solutions.com= ]
> Sent: Friday, April 19, 2002 1:50 AM
> To: dhcwg@ietf.org
> Subject: Re: [dhcwg] RFC 3256 on The DOCSIS = Device Class DHCP
>
>
> We have at least one customer making policy = decisions on the
> server based on
> the Class Identifier (option 60) value. = Apparently, it's
> always "docsis1.0"
> for a DOCSIS cable-modem. (Not sure about = docsis 1.1).
>
> But even though this method appears to work = fine in practice,
> I welcome this
> new draft because of the security aspect, as = well as the
> possibility for
> future expansion using the reserved = bits.
>
> I think it's important to let a trusted device = give us as
> much information as
> possible about the clients we're servicing. So = important, in
> fact, that I
> have wondered about the possibility of = *requiring* *any* kind
> of relay agent
> (DOCSIS or not) to insert option 82, with = information about
> the originating
> machine (hwtype-mac, for example). The premise = being that even in
> corporations, most routers are trusted = equipment, usually
> locked away in a
> basement somewhere.
>
> Bud Millwood
> Weird Solutions, Inc.
> http://www.weird-solutions.com
> tel: +46 70 566 7803
> fax: +46 8 758 3687
> mailto:budm@weird-solutions.com=
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

------_=_NextPart_001_01C1E7B6.D76E9FE0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Fri Apr 19 15:25:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22317 for ; Fri, 19 Apr 2002 15:25:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA04917 for dhcwg-archive@odin.ietf.org; Fri, 19 Apr 2002 15:25:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04805; Fri, 19 Apr 2002 15:23:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04779 for ; Fri, 19 Apr 2002 15:22:58 -0400 (EDT) Received: from snowmass.tci.com (coral.tci.com [198.178.8.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21864 for ; Fri, 19 Apr 2002 15:22:55 -0400 (EDT) Received: from wsimc08.broadband.att.com (wsimc08.tci.com [147.191.89.205]) by snowmass.tci.com (8.12.2/8.12.2) with SMTP id g3JIZejX013233; Fri, 19 Apr 2002 13:22:56 -0600 (MDT) Received: from 147.191.89.203 by wsimc08.broadband.att.com with SMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Fri, 19 Apr 2002 13:22:55 -0600 X-Server-Uuid: cda7734f-06b2-11d3-bc59-00805fbb2b22 Received: by entexchimc01.tci.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 19 Apr 2002 13:22:54 -0600 Message-ID: <518E23226CAFD211858C0008C7F9548E185A38B0@neexch01.broadband.att.com> From: "Woundy, Richard" To: "'Bud Millwood'" , dhcwg@ietf.org Subject: RE: [dhcwg] RFC 3256 on The DOCSIS Device Class DHCP Date: Fri, 19 Apr 2002 13:22:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 10DEB105162530-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Bud, According to the DOCSIS specifications, a DOCSIS 1.0 CM may include the value "docsis1.0" in DHCP option 60, and a DOCSIS 1.1 CM must include the value "docsis1.1" (followed by additional data in the string). See: appendix C.1.1, and appendix D.1.1. Note that some relay agents (e.g. broadband aggregation routers acting as ATM VC aggregators for DSLAMs) may not have as much information about the subscriber premise equipment as DOCSIS CMTSs... -- Rich -----Original Message----- From: Bud Millwood [mailto:budm@weird-solutions.com] Sent: Friday, April 19, 2002 4:50 AM To: dhcwg@ietf.org Subject: Re: [dhcwg] RFC 3256 on The DOCSIS Device Class DHCP We have at least one customer making policy decisions on the server based on the Class Identifier (option 60) value. Apparently, it's always "docsis1.0" for a DOCSIS cable-modem. (Not sure about docsis 1.1). But even though this method appears to work fine in practice, I welcome this new draft because of the security aspect, as well as the possibility for future expansion using the reserved bits. I think it's important to let a trusted device give us as much information as possible about the clients we're servicing. So important, in fact, that I have wondered about the possibility of *requiring* *any* kind of relay agent (DOCSIS or not) to insert option 82, with information about the originating machine (hwtype-mac, for example). The premise being that even in corporations, most routers are trusted equipment, usually locked away in a basement somewhere. Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 70 566 7803 fax: +46 8 758 3687 mailto:budm@weird-solutions.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Sat Apr 20 08:01:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01209 for ; Sat, 20 Apr 2002 08:01:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA25868 for dhcwg-archive@odin.ietf.org; Sat, 20 Apr 2002 08:01:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25389; Sat, 20 Apr 2002 07:59:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25362 for ; Sat, 20 Apr 2002 07:59:14 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01104 for ; Sat, 20 Apr 2002 07:59:12 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-159.cisco.com [10.82.224.159]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA02375; Sat, 20 Apr 2002 07:58:32 -0400 (EDT) Message-Id: <4.3.2.7.2.20020419181536.00ba55e0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 20 Apr 2002 07:58:28 -0400 To: Aries Fajar From: Ralph Droms Subject: Re: [dhcwg] message format Cc: dhcwg In-Reply-To: <3CBE54BE.215550C5@cbn.net.id> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Aries, The DHCPv6 message header has been simplified to avoid carrying redundant information. The address to which the server should reply to a DHCPv6 message is always available as the source address in the IPv6 header. When the client and server are on the same link, the source address is an address belonging to the client, so the server can reply directly to the client. When the client and server are on different links, the message to the server is forwarded by a relay agent. In this case, the source address in the message received by the server is an address belonging to the relay agent. The server sends its reply back to the relay agent, which then forwards the reply back to the client. For example, in draft-ietf-dhc-dhcpv6-23.txt, at the end of section 18.2.2. this text specifies how a server sends a Solicit message: 18.2.2. Creation and transmission of Advertise messages [...] If the Solicit message was received directly by the server, the server unicasts the Advertise message directly to the client using the address in the source address field from the IP datagram in which the Solicit message was received. The Advertise message MUST be unicast through the interface on which the Solicit message was received. If the Solicit message was received in a Relay-forward message, the server constructs a Relay-reply message with the Advertise message in the payload of a "server-message" option. The server unicasts the Relay-reply message directly to the relay agent using the address in the source address field from the IP datagram in which the Relay-forward message was received. - Ralph Droms At 12:08 PM 4/18/2002 +0700, Aries Fajar wrote: >Dear all, >I'm new to dhcpv6 and still learning it. I'm confuse about the dhcp >message. >Can u give the full message dhcp request from the client to the server >as an example ? >draft-ietf-dhc-dhcpv6-23.txt is a little bit confusing about message >format. >I read a book about IPV6 that contains dhcpv6 ( very old, 1996 ) and i >understand >many have changed since then... >so, from all my knowledge that i have acquired, this is my thinking >about message request > >------------------------------------------------ >| 6 | 4 | flow label : 0 | >------------------------------------------------ >| len:32 | nxt : 17 | hops : 9 | >------------------------------------------------a >| | >| Source : | >| | >|---------------------------------------------- >| | >| Dest : DHCP Server | >| | >---------------------------------------------- >| src port : 546 | dst port : 547 | >---------------------------------------------- >| length : 96 | checksum | >---------------------------------------------- >| request | 12345 | >---------------------------------------------- >| options | >---------------------------------------------- > >so, what's in the options field ? after reading the RFC, there is no >client network address >in the udp message. how can the server send the reply message to the >client, if it doesn't >know about the client address ? > >I read the old draft ( draft-ietf-dhc-dhcpv6-15.txt ) and i find a >more clearly message format. Here it is: > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| msg-type = 3 |C|R| reserved | transaction-ID | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >| client's link-local address | >| (16 octets) | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| relay-address | >| (16 octets) | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| server-address | >| (16 octets) | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| extensions (variable number and length) .... | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >where is it now ? is it somewhere at the options field ? > > >Please help >Thanks > >Aries Fajar >Electrical Engineering Department >Trisakti University >Indonesia > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Sat Apr 20 13:50:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05205 for ; Sat, 20 Apr 2002 13:50:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA08391 for dhcwg-archive@odin.ietf.org; Sat, 20 Apr 2002 13:50:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08251; Sat, 20 Apr 2002 13:46:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08222 for ; Sat, 20 Apr 2002 13:46:00 -0400 (EDT) Received: from sjwc380101.int.lantronix.com (clarify-web.lantronix.com [164.109.144.217] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05121 for ; Sat, 20 Apr 2002 13:45:57 -0400 (EDT) Received: from sj580004wcom.int.lantronix.com ([10.107.100.143]) by sjwc380101.int.lantronix.com with Microsoft SMTPSVC(5.0.2195.2966); Sat, 20 Apr 2002 10:45:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 20 Apr 2002 10:45:58 -0700 Message-ID: <603BA0CFF3788E46A0DB0918D9AA95100122CD17@sj580004wcom.int.lantronix.com> Thread-Topic: Extreme Interest in : IPv4 Address Conflict Detection Thread-Index: AcHok7k4pIedFeD1SuqVEGYZA3Pw4g== From: "Lynn Linse" To: X-OriginalArrivalTime: 20 Apr 2002 17:45:58.0640 (UTC) FILETIME=[3ABD3700:01C1E893] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA08223 Subject: [dhcwg] Extreme Interest in : IPv4 Address Conflict Detection Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit This draft seems to have been jettisoned - any idea if it's dead or moved or merged or renamed? Stuart Cheshire had said this was under discussion in both DHC and MobileIP WG. I'm working with GM (as in cars) and Rockwell Automation. A severe problems we are hitting in the field with Ethernet+TCP/IP products is wide variation and unpredictable behavior in duplicate IP cases between multiple vendor's devices. Some devices go off-line, some defend, some have a race condition where it depends who sees who first as to what will happen. A device unexpectedly going off-line can cost lots of $$$ to recover, or in rare cases even kill workers or damage hundreds of thousands of $$$ worth of attached equipment. This is part of the reason that Ethernet has taken decades longer to reach the factory floor. Keep in mind one rarely see PC (either Windows or Linux or Mac) in these plant floor systems, but instead have a wide variety of small devices with diverse in-house (roll-your-own) TCP stacks. Many of these products also use fixed (manually set) IP. DHCP is considered a risk since it creates yet-another critical failure point, so many products even "cheat" and allow using BOOTP to assign an Ip which is then coded into NVRAM and BOOTP is never called again unless a DHCP "FORCERENEW" is issued to in effect unset the old NVRAM IP and cause reissue of BOOTP. Sounds odd, but it gets the job done. Add these together means we need a documented way (an RFC?) to both predict WHAT happens in duplicate IP cases and to help guide all these roll-your-own TCP stack writers to do it the consistent way. best regards Lynn August Linse, Senior IA Application Engineer 15353 Barranca Parkway, Lantronix Inc, Irvine CA 92618 lynn.linse@lantronix.com www.lantronix.com Tel: (949)279-3969 Fax: (949)453-7152 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Sat Apr 20 21:00:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09099 for ; Sat, 20 Apr 2002 21:00:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA22992 for dhcwg-archive@odin.ietf.org; Sat, 20 Apr 2002 21:00:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22713; Sat, 20 Apr 2002 20:58:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22688 for ; Sat, 20 Apr 2002 20:58:50 -0400 (EDT) Received: from public.szptt.net.cn (mail2-smtp.szptt.net.cn [202.96.136.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09060 for ; Sat, 20 Apr 2002 20:58:46 -0400 (EDT) Received: from public.szptt.net.cn([202.96.136.221]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jma3cc21f62; Sun, 21 Apr 2002 00:58:20 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm03cbf9678; Fri, 19 Apr 2002 00:57:43 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id TAA22989 for ietf-123-outbound.01@ietf.org; Thu, 18 Apr 2002 19:15:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id SAA22887 for ; Thu, 18 Apr 2002 18:59:44 -0400 (EDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25068; Thu, 18 Apr 2002 18:59:39 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g3IMxXm13524; Thu, 18 Apr 2002 15:59:34 -0700 (PDT) Message-Id: <200204182259.g3IMxXm13524@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, dhcwg@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 18 Apr 2002 15:59:33 -0700 From: RFC Editor Subject: [dhcwg] RFC 3256 on The DOCSIS Device Class DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3256 Title: The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option Author(s): D. Jones, R. Woundy Status: Standards Track Date: April 2002 Mailbox: doug@yas.com, rwoundy@broadband.att.com Pages: 5 Characters: 8551 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-agentoptions-device-class-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3256.txt This document proposes a new sub-option to the DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Option. This new sub-option is for use with DOCSIS (Data-Over-Cable Service Interface Specifications) cable modems and describes a "device class" to which the cable modem belongs. The cable modem signals its device class information to the Relay Agent using DOCSIS signaling, and the Relay Agent forwards the device class information to the DHCP Server which can then make a policy decision based on it. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020418155752.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3256 --OtherAccess Content-Type: Message/External-body; name="rfc3256.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020418155752.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Mon Apr 22 06:47:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20974 for ; Mon, 22 Apr 2002 06:47:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA05416 for dhcwg-archive@odin.ietf.org; Mon, 22 Apr 2002 06:47:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05328; Mon, 22 Apr 2002 06:45:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05302 for ; Mon, 22 Apr 2002 06:45:36 -0400 (EDT) Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20932 for ; Mon, 22 Apr 2002 06:45:33 -0400 (EDT) Received: from there ([193.12.201.10]) by fep01-svc.swip.net with SMTP id <20020422104504.NEKJ26263.fep01-svc.swip.net@there> for ; Mon, 22 Apr 2002 12:45:04 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: dhcwg@ietf.org Subject: Re: [dhcwg] RFC 3256 on The DOCSIS Device Class DHCP Date: Mon, 22 Apr 2002 12:51:14 +0200 X-Mailer: KMail [version 1.3.2] References: <4FB49E60CFBA724E88867317DAA3D1984956B9@homer.incognito.com.> In-Reply-To: <4FB49E60CFBA724E88867317DAA3D1984956B9@homer.incognito.com.> MIME-Version: 1.0 Message-Id: <20020422104504.NEKJ26263.fep01-svc.swip.net@there> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA05303 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Andre Kostur wrote: > You could simply configure your DHCP server to ignore requests which don't > have option 82.... Yep, on provider networks, but on most corporate networks the average relay agent doesn't support option 82. I was just pointing out that providers are using a decent mechanism for limiting DoS attacks, and maybe this technique could be implemented in more networks if the average relay agent provided support for this 82 (specifically RID, in the format of the 'htype'-'chaddr' field would be sufficient). But as Richard Woundy pointed out, not all relay agents have info about the CPE, so you couldn't really make it a requirement. Thanks for the links, Richard. Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 70 566 7803 fax: +46 8 758 3687 mailto:budm@weird-solutions.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Apr 23 07:20:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12384 for ; Tue, 23 Apr 2002 07:20:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA20311 for dhcwg-archive@odin.ietf.org; Tue, 23 Apr 2002 07:20:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19502; Tue, 23 Apr 2002 07:17:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18712 for ; Tue, 23 Apr 2002 07:13:16 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11690; Tue, 23 Apr 2002 07:13:08 -0400 (EDT) Message-Id: <200204231113.HAA11690@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 23 Apr 2002 07:13:07 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-concat-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Encoding Long DHCP Options Author(s) : T. Lemon, S. Cheshire Filename : draft-ietf-dhc-concat-03.txt Pages : Date : 22-Apr-02 This document specifies the processing rules for DHCP options that appear multiple times in the same message. Multiple instances of the same option are generated when an option exceeds 255 octets in size (the maximum size of a single option) or when an option needs to be split apart in order to take advantage of DHCP option overloading (Dynamic Host Configuration Protocol [1], Section 4.1. When multiple instances of the same option appear in the options, file and/or sname fields in a DHCP packet, the contents of these options are concatenated together to form a single option prior to processing. This draft specifies how DHCP options in a DHCP packet can be aggregated so that DHCP protocol agents can send options that are more than 255 bytes in length. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-concat-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-concat-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-concat-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020422135105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-concat-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-concat-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020422135105.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Apr 24 08:09:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00880 for ; Wed, 24 Apr 2002 08:09:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA24574 for dhcwg-archive@odin.ietf.org; Wed, 24 Apr 2002 08:09:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24295; Wed, 24 Apr 2002 08:04:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24267 for ; Wed, 24 Apr 2002 08:04:12 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00636; Wed, 24 Apr 2002 08:04:08 -0400 (EDT) Message-Id: <200204241204.IAA00636@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 24 Apr 2002 08:04:07 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-24.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Author(s) : J. Bound, M. Carney, C. Perkins, T. Lemon, B. Volz, R. Droms Filename : draft-ietf-dhc-dhcpv6-24.txt Pages : 82 Date : 23-Apr-02 The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to 'IPv6 Stateless Address Autoconfiguration' (RFC2462), and can be used separately or concurrently with the latter to obtain configuration parameters A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-24.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-24.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-24.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020423121257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-24.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-24.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020423121257.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Apr 25 08:41:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03569 for ; Thu, 25 Apr 2002 08:41:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA03469 for dhcwg-archive@odin.ietf.org; Thu, 25 Apr 2002 08:41:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03332; Thu, 25 Apr 2002 08:38:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14525 for ; Thu, 25 Apr 2002 03:46:55 -0400 (EDT) Received: from hotmail.com (f196.law9.hotmail.com [64.4.9.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28619 for ; Thu, 25 Apr 2002 03:46:53 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 25 Apr 2002 00:46:25 -0700 Received: from 203.115.109.2 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 25 Apr 2002 07:46:25 GMT X-Originating-IP: [203.115.109.2] From: "Sachin Nair" To: dhcwg@ietf.org Date: Thu, 25 Apr 2002 07:46:25 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Apr 2002 07:46:25.0437 (UTC) FILETIME=[4D1ACCD0:01C1EC2D] Subject: [dhcwg] client programs. Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi friends, pls help me to sort out my confusion. I wish to run my own program in my system and I wish to try if that program can get a different IP address( other than my computer) from the DHCP server. I am reading on DHCP ( rfc 2131 etc) But i find it difficult to decide if I can get 2 IP addresses for two programs running at the same computer. ( ie; different IPs to same MAC address). Is it possible ?? if so .. can u give me some helpful resources/contacts/ links on it? Regards and Thanks Sachin _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Apr 25 10:42:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07759 for ; Thu, 25 Apr 2002 10:42:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA11756 for dhcwg-archive@odin.ietf.org; Thu, 25 Apr 2002 10:43:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10606; Thu, 25 Apr 2002 10:29:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10568 for ; Thu, 25 Apr 2002 10:29:33 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07240 for ; Thu, 25 Apr 2002 10:29:28 -0400 (EDT) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g3PER1r27090; Thu, 25 Apr 2002 07:27:01 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g3PERXi03873; Thu, 25 Apr 2002 09:27:33 -0500 (CDT) Date: Thu, 25 Apr 2002 09:27:33 -0500 Subject: Re: [dhcwg] client programs. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: dhcwg@ietf.org To: "Sachin Nair" From: Ted Lemon In-Reply-To: Message-Id: <94DA22B2-5858-11D6-AB29-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit You can get two different addresses by using two different client identifiers, but I know of no out-of-the-box solution to this problem - you' d have to do some programming work, or find someone to do it for you (that' s not a veiled hint - I don't have time). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Thu Apr 25 17:08:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06103 for ; Thu, 25 Apr 2002 17:08:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA11341 for dhcwg-archive@odin.ietf.org; Thu, 25 Apr 2002 17:08:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11053; Thu, 25 Apr 2002 17:05:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09286 for ; Thu, 25 Apr 2002 10:04:17 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06493 for ; Thu, 25 Apr 2002 10:04:13 -0400 (EDT) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g3PE4E0E023837 for