RE: [16NG] Redundant DAD for RFC3041 in IPv6CS
"Premec, Domagoj" <domagoj.premec@siemens.com> Thu, 10 May 2007 09:07 UTC
Return-path: <16ng-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1Hm4cR-0004G9-Pn; Thu, 10 May 2007 05:07:27 -0400
Received: from 16ng by megatron.ietf.org with local (Exim 4.43)
id 1Hm4cQ-0004G4-Bc
for 16ng-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 05:07:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm4cN-0004Fa-9H
for 16ng@ietf.org; Thu, 10 May 2007 05:07:23 -0400
Received: from mxs1.siemens.at ([194.138.12.131] helo=atvies1zqx.siemens.at)
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm4cF-0002J8-7M
for 16ng@ietf.org; Thu, 10 May 2007 05:07:21 -0400
Received: from vies1k7x.sie.siemens.at ([158.226.129.83])
by atvies1zqx.siemens.at with ESMTP id l4A97CRI027972;
Thu, 10 May 2007 11:07:12 +0200
Received: from nets139a.ww300.siemens.net ([158.226.129.97])
by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id
l4A978c4003560; Thu, 10 May 2007 11:07:11 +0200
Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by
nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830);
Thu, 10 May 2007 11:06:55 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [16NG] Redundant DAD for RFC3041 in IPv6CS
Date: Thu, 10 May 2007 11:06:53 +0200
Message-ID: <3C31CDD06342EA4A8137716247B1CD6801FC165E@zagh223a.ww300.siemens.net>
In-Reply-To: <f7c7d76e0705090744y395b6658macaa4fb6e760f2@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [16NG] Redundant DAD for RFC3041 in IPv6CS
Thread-Index: AceSSIc9Q8/n1hwrTbut0eMaQRQujgAmRO1Q
References: <f7c7d76e0705090744y395b6658macaa4fb6e760f2@mail.gmail.com>
From: "Premec, Domagoj" <domagoj.premec@siemens.com>
To: "Daniel Park" <soohongp@gmail.com>,
=?UTF-8?B?6rmA7IOB7Ja4?= <kim.sangeon@gmail.com>
X-OriginalArrivalTime: 10 May 2007 09:06:55.0692 (UTC)
FILETIME=[8EA6F8C0:01C792E2]
X-purgate: clean
X-purgate: This mail is considered clean
X-purgate-type: clean
X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net
X-purgate-ID: 149917::070510110712-58A7CBB0-4580D819/0-0/0-15
X-purgate-size: 45800/0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2d1100b36d83fed07afbc292d8848e10
Cc: 16ng@ietf.org
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>,
<mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>,
<mailto:16ng-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0937224085=="
Errors-To: 16ng-bounces@ietf.org
Hi, > on this criteria, it may be redundant to perform DAD on a global > unicast address that is configured using the EUI-64 or generated as In my reading, this statement allows DAD to be skipped *only* for global unicast address. DAD would still be needed for link local address. regards domagoj > -----Original Message----- > From: Daniel Park [mailto:soohongp@gmail.com] > Sent: 09. svibanj 2007 16:44 > To: 김상언 > Cc: 16ng@ietf.org > Subject: [16NG] Redundant DAD for RFC3041 in IPv6CS > > (Slightly modifying the subject) > > You had skipped over the important parts from this section below: > > 9.2. Duplicate address detection > > DAD SHOULD be performed as per Neighbor Discovery for IP Version 6, > [I-D.ietf-ipv6-2461bis] and, IPv6 Stateless Address > Autoconfiguration, [I-D.ietf-ipv6-rfc2462bis]. The IPv6 link over > 802.16 is specified in this document as a point-to-point > link. Based > on this criteria, it may be redundant to perform DAD on a global > unicast address that is configured using the EUI-64 or generated as > per RFC3041 [RFC3041] for the interface as part of the > IPv6 stateless > address autoconfiguration protocol > [I-D.ietf-ipv6-rfc2462bis] as long > as the following two conditions are met: > > 1. The prefixes advertised through the router > advertisement messages > by the access router terminating the 802.16 IPv6 link > are unique > to that link. > 2. The access router terminating the 802.16 IPv6 link does not > autoconfigure any IPv6 global unicast addresses from the prefix > that it advertises. > > > This document just mentions "MAY be redundant..." not leaving out DAD. > So, this note seems acceptable and reasonable to me. > Performing DAD in this situation is up to implementation in my view. > > -- Daniel Park > > > On 5/9/07, 김상언 <kim.sangeon@gmail.com> wrote: > > > > Section 9.2 in <draft-ietf-16ng-ipv6-over-ipv6cs-09> > > states that "it may be redundant to perform DAD on a global unicast > > address that is configured using the EUI-64 or generated as per > > RFC3041 [RFC3041] for the interface as part of the IPv6 stateless > > address autoconfiguration protocol" > > > > I think that DAD is not redundant but necessary for > randomly generated > > IID on per-MS prefix. > > > > What do you think about it? > > > > S.E Kim at KT > > > > 2007/5/8, Daniel Park <soohongp@gmail.com>om>: > > > First off, I'm not sure why your subject is posted on the list > > > tagging > > Digest. > > > > > > Anyhow, IPv6CS document already mentioned RFC3041 for private IID > > > extension and this document is entirely based on P2P subnet model > > > (assignment of unique prefix for each host). > > > > > > 9.1. Interface Identifier > > > > > > The MS has a 48-bit globally unique MAC address as specified in > > > 802.16 [802.16]. This MAC address MUST be used to generate the > > > modified EUI-64 format-based interface identifier as > specified in the > > > IP Version 6 Addressing Architecture [RFC4291]. The > modified EUI-64 > > > interface identifier is used in stateless address > autoconfiguration. > > > As in other links that support IPv6, EUI-64 based interface > > > identifiers are not mandatory and other mechanisms, > such as random > > > interface identifiers, Privacy Extensions for Stateless Address > > > Autoconfiguration in IPv6 [RFC3041] MAY also be used. > > > > > > > > > Anything else ? > > > > > > -- Daniel Park > > > > > > On 5/8/07, 김상언 <kim.sangeon@gmail.com> wrote: > > > > > > > > In RFC3314, section 2.1 describes the limitation of the 3GPP > > > > address assignments. > > > > > > > > Think of RFC 3041. > > > > > > > > We need a consensus that privacy extension require or > not even if > > > > p2p > > subnet > > > > model. > > > > > > > > S.E Kim at KT > > > > > > > > 2007/5/4, 16ng-request@ietf.org <16ng-request@ietf.org>rg>: > > > > > Send 16NG mailing list submissions to > > > > > 16ng@ietf.org > > > > > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > > https://www1.ietf.org/mailman/listinfo/16ng > > > > > or, via email, send a message with subject or body 'help' to > > > > > 16ng-request@ietf.org > > > > > > > > > > You can reach the person managing the list at > > > > > 16ng-owner@ietf.org > > > > > > > > > > When replying, please edit your Subject line so it is more > > > > > specific than "Re: Contents of 16NG digest..." > > > > > > > > > > > > > > > Today's Topics: > > > > > > > > > > 1. RE: DAD in IEEE802.16 (Tjandra Paula-CPT015) > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > Message: 1 > > > > > Date: Thu, 3 May 2007 18:18:38 -0400 > > > > > From: "Tjandra Paula-CPT015" < Paula.Tjandra@motorola.com> > > > > > Subject: RE: [16NG] DAD in IEEE802.16 > > > > > To: "Behcet Sarikaya" <sarikaya@ieee.org >, > "gabriel montenegro" > > > > > <gabriel_montenegro_2000@yahoo.com > > > > > > Cc: 16ng@ietf.org > > > > > Message-ID: > > > > > > > > > > > <C089A1D88F85E84B9051FF4C97B574F601C8989A@de01exm68.ds.mot.com > > > > > > > > > > Content-Type: text/plain; charset="utf-8" > > > > > > > > > > Is it a requirement to assign unique prefix per MS in WiMAX? > > > > > <draft-ietf-16ng-ipv6-over-ipv6cs> seems to imply > > that it > > > > is. > > > > > Assuming that the MS/host has a unique prefix, why would the > > > > > MS/host > > need > > > > to perform DAD? > > > > > > > > > > Regards, Paula. > > > > > > > > > > ________________________________ > > > > > > > > > > From: Behcet Sarikaya [mailto: behcetsarikaya@yahoo.com] > > > > > Sent: Thursday, May 03, 2007 4:48 PM > > > > > To: gabriel montenegro > > > > > Cc: 16ng@ietf.org > > > > > Subject: Re: [16NG] DAD in IEEE802.16 > > > > > > > > > > > > > > > Gabriel, > > > > > Let's take RFC3314. It says: > > > > > DAD is not performed, as the GGSN > > > > > will not assign the same address to multiple nodes. > > > > > > > > > > So the context is important. Of course I agree with the above > > sentence, > > > > but in other contexts, DAD is needed. > > > > > > > > > > Regards, > > > > > > > > > > Behcet > > > > > > > > > > ----- Original Message ---- > > > > > From: gabriel montenegro < > > > > gabriel_montenegro_2000@yahoo.com> > > > > > To: Behcet Sarikaya < sarikaya@ieee.org> > > > > > Cc: 16ng@ietf.org > > > > > Sent: Thursday, May 3, 2007 4:17:37 PM > > > > > Subject: Re: [16NG] DAD in IEEE802.16 > > > > > > > > > > > > > > > Behcet said: "I don't think we can say that DAD is > not needed." > > > > > > > > > > This is what the documents I refer to below *already* say is > > > > > fine > > under > > > > certain conditions. I believe those same conditions are > likely to > > > > be generally satisfied in > > > > > networks beyond those being explicitly mentioned in those > > > > > documents > > (e.g., > > > > wimax). > > > > > > > > > > If you want those documents to not say it may be ok to forgo > > > > > DAD, then > > > > it's too late for the RFCs, but perhaps you can still > argue it for > > > > > the "IP Version 6 over PPP", but better hurry as it > is in IESG > > > > > right > > now. > > > > I happen to think that what it says is correct. > > > > > > > > > > -gabriel > > > > > > > > > > > > > > > ----- Original Message ---- > > > > > From: Behcet Sarikaya < behcetsarikaya@yahoo.com> > > > > > To: gabriel montenegro > > > > <gabriel_montenegro_2000@yahoo.com> > > > > > Cc: 16ng@ietf.org > > > > > Sent: Thursday, May 3, 2007 11:45:33 AM > > > > > Subject: Re: [16NG] DAD in IEEE802.16 > > > > > > > > > > > > > > > Isn't DAD recommended even on p2p links? You are > generating an > > > > > address > > > > from either your MAC address or using some random > numbers, you can > > > > not > > avoid > > > > a collision 100%. I heard that Vista generates a new > IPv6 address > > > > every hour. I don't think we can say that DAD is not needed. > > > > > > > > > > --behcet > > > > > > > > > > > > > > > ----- Original Message ---- > > > > > From: gabriel montenegro > > > > <gabriel_montenegro_2000@yahoo.com> > > > > > To: Syam Madanapalli < smadanapalli@gmail.com>gt;; Frank Xia > > > > <xiayangsong@huawei.com> > > > > > Cc: 16ng@ietf.org > > > > > Sent: Thursday, May 3, 2007 12:00:04 PM > > > > > Subject: Re: [16NG] DAD in IEEE802.16 > > > > > > > > > > > > > > > I really don't think it makes sense to consider END, a > > > > > non-standard, > > for > > > > such a minor issue, which might actually be a non-issue. > > > > > DAD itself may not be even needed, as mentioned by > Syam already. > > > > > This > > > > point is mentioned informationally in the DAD discussions in: > > > > > > > > > > Recommendations for IPv6 in Third Generation Partnership > > > > > Project > > (3GPP) > > > > Standards > > > > > http://tools.ietf.org/html/rfc3314 > > > > > > > > > > Internet Protocol Version 6 (IPv6) for Some Second > and Third > > Generation > > > > Cellular Hosts > > > > > http://tools.ietf.org/html/rfc3316 > > > > > > > > > > and normatively in section 5 of: > > > > > > > > > > IP Version 6 over PPP > > > > > > > > > > > http://tools.ietf.org/html/draft-ietf-ipv6-over-ppp-v2-02 > > > > > > > > > > which is currently in IESG processing. Even though the above > > > > > docs > > don't > > > > spell out w-i-m-a-x, the link characteristics from the point of > > addressing > > > > are > > > > > similar enough that the same considerations can apply. > > > > > > > > > > -gabriel > > > > > > > > > > > > > > > ----- Original Message ---- > > > > > From: Syam Madanapalli <smadanapalli@gmail.com> > > > > > To: Frank Xia < xiayangsong@huawei.com> > > > > > Cc: 16ng@ietf.org > > > > > Sent: Thursday, May 3, 2007 8:38:59 AM > > > > > Subject: Re: [16NG] DAD in IEEE802.16 > > > > > > > > > > > > > > > Hi Frank, > > > > > > > > > > > > > > > On 5/3/07, Frank Xia <xiayangsong@huawei.com> wrote: > > > > > > > > > > > > > > > Hi Syam > > > > > > > > > > Even in ODAD, there is a normal DAD procedure > in parallel. > > > > > END is to improve normal DAD, not ODAD. > > > > > END can co-work with ODAD well. > > > > > > > > > > > > > > > > > > > > I see no reason to use ODAD along with END. > > > > > END might have had better position if it were proposed before > > > > > ODAD :-) > > > > > > > > > > > > > > > > > > > > > > > > > Any way, just as you said, is it useful enough > to modify > > > > > the > > > > router? > > > > > > > > > > > > > > > > > > > > Yep, if we can answer this, then we will be in better > position > > > > > to > > support > > > > this proposal. > > > > > > > > > > > > > > > > > > > > I don't know, but I think that any feasible > improvement > > > > > can be > > > > considered. > > > > > > > > > > > > > > > > > > > > I agree. > > > > > > > > > > Thanks, > > > > > Syam > > > > > > > > > > > > > > > > > > > > BR > > > > > > > > > > Frank > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: Syam Madanapalli <mailto: > > > > > smadanapalli@gmail.com> > > > > > > > > > > To: Behcet Sarikaya <mailto: sarikaya@ieee.org> > > > > > Cc: 16ng@ietf.org > > > > > Sent: Thursday, May 03, 2007 2:18 AM > > > > > Subject: Re: [16NG] DAD in IEEE802.16 > > > > > > > > > > > > > > > Hi Bachet, > > > > > > > > > > Doing things deterministically is always good. > > > > > But here I am wondering if it is worth the > > implementation > > > > changes on the routers as well as on hosts, > > > > > especially on p2p links where the chance of > > > > > collission > > is > > > > very very remote as the p2p link will be > > > > > using just two addresses out of 2 ^64. > > > > > > > > > > Assign unique prefix using prefix > delegation for > > > > > each > > host > > > > or configuring the router not to > > > > > construct the IPv6 address using the > advertised > > > > > prefix > > in > > > > case the router advertises the prefix > > > > > along with the ODAD may solve the problem > > > > > completely, I > > > > think. > > > > > > > > > > > > > > > Thanks, > > > > > Syam > > > > > > > > > > > > > > > On 5/3/07, Behcet Sarikaya > > > > > <behcetsarikaya@yahoo.com > > > > > wrote: > > > > > > > > > > Syam, isn't it better to make it > > > > > deterministic > > in > > > > p2p links where you have an authoritative address cache? > > > > > > > > > > > > > > > --behcet > > > > > > > > > > > > > > > ----- Original Message ---- > > > > > From: Syam Madanapalli < > > > > > smadanapalli@gmail.com > > > > <mailto:smadanapalli@gmail.com> > > > > > > To: Frank Xia <xiayangsong@huawei.com> > > > > > Cc: 김상언 < kim.sangeon@gmail.com > > > > <mailto:kim.sangeon@gmail.com> >; 16ng@ietf.org > > > > > Sent: Wednesday, May 2, 2007 1:02:35 PM > > > > > Subject: Re: [16NG] DAD in > > IEEE802.16 > > > > > > > > > > > > > > > Hi Frank, > > > > > > > > > > I understand the proposed END > mechanism > > > > > is more > > > > deterministic, however it comes at > > > > > a cost: router modification and > > > > > availability of > > > > authoritative address cache. > > > > > > > > > > > > > > > And personally I do not like > the RA as a > > response > > > > to DAD NS to tell the host that > > > > > the address is unique, and at > NA cannot > > > > > be used > > as > > > > it will not be interoperable with > > > > > unmodified hosts which will > > treat that the address > > > > is duplicate. > > > > > > > > > > > > > > > IEEE 802.16 based hosts would have the > > > > > unique > > MAC > > > > address, so ODAD would > > > > > work well I think. > > > > > > > > > > > > > > > Thanks, > > > > > Syam > > > > > > > > > > > > > > > On 5/2/07, Frank Xia < > > > > > xiayangsong@huawei.com > > > > > wrote: > > > > > > > > > > Hi Syam > > > > > > > > > > END can work together > > with Optimistic DAD, > > > > and some of the description in our draft is > > > > > " If END and [OPTDAD] > > are enabled, the SS > > > > will benefit from both the > > > > > reliability and > > time > > > > advantages. > > > > > " > > > > > > > > > > Any way , there are > > some constraints for > > > > Optimistic DAD, > > > > > please refer to the > > words form RFC4429: > > > > > * Optimistic DAD > > SHOULD > > > > only be used when the implementation is aware > > > > > that the > > address > > > > is based on a most likely unique interface > > > > > identifier > > (such > > > > as in [RFC2464]), generated randomly [RFC3041], > > > > > or by a > > > > well-distributed hash function [RFC3972] or assigned by > > > > > Dynamic Host > > > > Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. > > > > > Optimistic DAD > > > > SHOULD NOT be used for manually entered > > > > > addresses." > > > > > > > > > > BR > > > > > Frank > > > > > > > > > > > > > > > ----- Original > > > > Message ----- > > > > > From: Syam > > > > Madanapalli <mailto: smadanapalli@gmail.com> > > > > > To: Frank Xia > > > > <mailto:xiayangsong@huawei.com> > > > > > Cc: Daniel > > Park > > > > <mailto: soohong.park@samsung.com> ; 김상언 > > > > <mailto:kim.sangeon@gmail.com> > > ; > > > > 16ng@ietf.org > > > > > Sent: > > Wednesday, > > > > May 02, 2007 12:22 PM > > > > > Subject: Re: > > > > [16NG] DAD in IEEE802.16 > > > > > > > > > > > > > > > > > > > > Hi Frank and > > > > Sangeon, > > > > > > > > > > How about > > using > > > > Optimistic DAD (RFC 4429) to minimize the delay? > > > > > > > > > > Thanks, > > > > > Syam > > > > > > > > > > > > > > > On 5/2/07, > > Frank > > > > Xia < xiayangsong@huawei.com > <mailto:xiayangsong@huawei.com> > wrote: > > > > > > > > > > > > > > > Hi Deniel and > > > > Sangeon > > > > > > > > > > A solution is > > > > proposed in the END draft and it applies to p2p link > model as well. > > > > > > > > > > > > > > http://tools.ietf.org/wg/16ng/draft-xia-16ng-end-01.txt > > < > > > > > > http://tools.ietf.org/wg/16ng/draft-xia-16ng-end-01.txt+> > > > > > > > > > > Comments are > > > > welcomed. > > > > > > > > > > BR > > > > > > > > > > Frank > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original > > > > Message ----- > > > > > From: Daniel > > Park > > > > <mailto:soohong.park@samsung.com > > > > > > > > > > > To: '源 ?곸뼵' > > > > <mailto: kim.sangeon@gmail.com> ; 16ng@ietf.org > > > > > Sent: Tuesday, > > May > > > > 01, 2007 6:39 PM > > > > > Subject: > > [16NG] > > > > DAD in IEEE802.16 > > > > > > > > > > > > > > > [Trimming the > > list > > > > and subject] > > > > > > > > > > Sangeon, > > > > > > > > > > IPv6 subnet > > model > > > > document was gone. Its status > > > > > is in RFC > > Queue. > > > > If you have any concern regarding > > > > > IPv6 DAD, it > > may > > > > take place in IPv6CS or EthernetCS > > > > > document in my > > > > sense. Can you elaborate on your > > > > > concern more > > > > specific ? > > > > > > > > > > -- Daniel Park > > > > > > > > > > > > > > > > > > > > > > > > > From: 源 ?곸뼵 > > > > [mailto:kim.sangeon@gmail.com] > > > > > > > > > > Sent: Monday, > > > > April 30, 2007 11:14 PM > > > > > To: > > 16ng@ietf.org > > > > > Cc: > > iab@iab.org; > > > > 16ng-chairs@tools.ietf.org > > > > > Subject: Re: > > 16NG > > > > Digest, Vol 5, Issue 22 > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > The one of the > > > > important thing in IEEE802.16 is missed. > > > > > RFC 2462 > > specifies > > > > autoconfiguration in wired-based IPv6 Internet. It did > not specify > > > > configuration time. > > > > > To use RFC > > 2462 > > > > specfication in IEEE802.16e network, it is required faster > > > > procedure > > than > > > > current DAD procedure. > > > > > Has anyone can > > > > tell the DAD processing time? > > > > > > > > > > If the IEEE > > 802.16 > > > > network will consume more than one seconds to handover at IP > > > > layer, Does > > it > > > > practical? > > > > > > > > > > So, I would > > like > > > > to propose to add some technical resolution for section > 3.1.3 and 3.3.3. > > > > > > > > > > regards, > > > > > > > > > > > > > > > 2007/4/28, > > > > 16ng-request@ietf.org < 16ng-request@ietf.org > > <mailto:16ng-request@ietf.org> > > > > >: > > > > > > > > > > Send 16NG > > mailing > > > > list submissions to > > > > > > > > > 16ng@ietf.org > > > > > > > > > > To subscribe > > or > > > > unsubscribe via the World Wide Web, visit > > > > > > > > > https://www1.ietf.org/mailman/listinfo/16ng > > > > > or, via email, > > > > send a message with subject or body 'help' to > > > > > > > > > 16ng-request@ietf.org > > > > > > > > > > You can reach > > the > > > > person managing the list at > > > > > > > > > 16ng-owner@ietf.org > > > > > > > > > > When replying, > > > > please edit your Subject line so it is more specific > > > > > than "Re: > > Contents > > > > of 16NG digest..." > > > > > > > > > > > > > > > Today's > > Topics: > > > > > > > > > > 1. Document > > > > Action: 'Analysis of IPv6 Link Models for 802.16 > > > > > based > > > > Networks' to Informational RFC (The IESG) > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > Message: 1 > > > > > Date: Fri, 27 > > Apr > > > > 2007 11:30:34 -0400 > > > > > From: The IESG > > < > > > > iesg-secretary@ietf.org > > > > > > Subject: > > [16NG] > > > > Document Action: 'Analysis of IPv6 Link Models for > > > > > 802.16 > > > > based Networks' to Informational RFC > > > > > To: > > IETF-Announce > > > > < ietf-announce@ietf.org <mailto: ietf-announce@ietf.org> > > > > > > Cc: Internet > > > > Architecture Board <iab@iab.org>rg>, 16ng mailing list > > > > > < > > > > 16ng@ietf.org>gt;, 16ng chair < 16ng-chairs@tools.ietf.org <mailto: > > > > 16ng-chairs@tools.ietf.org > >, RFC Editor > > > > > > > > > <rfc-editor@rfc-editor.org> > > > > > Message-ID: < > > > > E1HhSP4-00025w-LX@stiedprstage1.ietf.org> > > > > > > > > > > The IESG has > > > > approved the following document: > > > > > > > > > > - 'Analysis of > > > > IPv6 Link Models for 802.16 based Networks ' > > > > > > > > > <draft-ietf-16ng-ipv6-link-model-analysis-03.txt > as > > an > > > > Informational RFC > > > > > > > > > > This document > > is > > > > the product of the IP over IEEE 802.16 Networks Working > > > > > Group. > > > > > > > > > > The IESG > > contact > > > > persons are Jari Arkko and Mark Townsley. > > > > > > > > > > A URL of this > > > > Internet-Draft is: > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-link-model-an > > alysis-03.txt > > > > > > > > > > Technical > > Summary > > > > > > > > > > This document > > > > provides different IPv6 link models that are suitable > > > > > for 802.16 > > based > > > > networks and provides analysis of various > > > > > considerations > > for > > > > each link model and the applicability of each link > > > > > model under > > > > different deployment scenarios. > > > > > > > > > > Working Group > > > > Summary > > > > > > > > > > This document > > is > > > > result of a Design Team that was formed > > > > > to analyze the > > > > IPv6 link models for 802.16 based networks. > > > > > Based on the > > > > recommendations of the design team and this > > > > > document, the > > > > working group has chosen the unique-prefix-per- > > > > > link/mn model > > over > > > > the previously assumed shared prefix > > > > > model. The new > > > > model is in use in the IPv6 over 802.16 IPCS > > > > > document > > > > (draft-ietf-16ng-ipv6-over-ipv6cs), and has also > > > > > been adopted > > by > > > > the Wimax Forum. > > > > > > > > > > Protocol > > Quality > > > > > > > > > > Jari Arkko has > > > > revied this document for the IESG. > > > > > > > > > > Note to RFC > > Editor > > > > > > > > > > Please insert > > > > "IEEE" in front of references to 802.16 > > > > > or other IEEE > > > > specification numbers throughout the > > > > > document, > > > > including the title. > > > > > > > > > > Please expand > > "MS" > > > > to "MS (Mobile Station)" on first > > > > > occurence in > > > > Section 1. Similarly, expand "BS" to > > > > > "BS (Base > > > > Station)". And later in the document, > > > > > "CS" to "CS > > > > (Convergence Sublayer)". > > > > > > > > > > Please expand > > > > "MLD" to "MLD (Multicast Listener > > > > > Discovery)" in > > > > Section 3.1.3. > > > > > > > > > > Please add the > > > > following informative reference: > > > > > > > > > > [WiMAXArch] > > > > > > > > > "WiMAX End-to-End Network Systems Architecture > > > > > > > > > http://www.wimaxforum.org/technology/documents ", > > > > > > > > > August 2006. > > > > > > > > > > and refer to > > that > > > > from Section 1, 2nd paragraph, 1st sentence. > > > > > > > > > > In Section > > 3.1, > > > > change "on per MS basis" to "on a per MS basis". > > > > > > > > > > Also in > > Section > > > > 3.1, paragraph 1: change "does not any multicast" > > > > > to "does not > > > > provide any multicast". And change "illustrates high" > > > > > to "illustrate > > a". > > > > Finally, change "one more" to "one or more". > > > > > > > > > > Change the > > section > > > > titles (3 instances) that say "Reuse of > > > > > Existing > > > > Standards" to "Reuse of Existing Specifications". > > > > > > > > > > Replace the > > text > > > > in the Security Considerations section > > > > > with the > > > > following: > > > > > > > > > > This > > document > > > > provides the analysis of various IPv6 link models for > > > > > IEEE 802.16 > > > > based networks and this document as such does not > > > > > introduce > > any > > > > new security threats. No matter what the link model > > > > > is, the > > > > networks employ the same link-layer security mechanisms > > > > > defined in > > [5]. > > > > However, the chosen link model affects the scope > > > > > of link > > local > > > > communication, and this may have security implications > > > > > for > > protocols > > > > that are designed to work within the link scope. This > > > > > is the > > concern > > > > for shared link model compared other models wherein > > > > > private > > > > resources e.g. personal printer cannot be put onto a public > > > > > WiMAX > > network. > > > > This may restrict the usage of shared prefix model > > > > > to > > enterprise > > > > environments. > > > > > > > > > > The > > Neighbor > > > > Discovery related security issues are document in [RFC > > > > > > > > > > 2461] [RFC > > > > 2462] and these are applicable for all the models > > > > > described > > in > > > > this documents. The model specific security > > > > > > > considerations > > > > are documented in their respective protocol > > > > > > > specifications. > > > > > > > > > > Place a new > > > > top-level section between Sections 5 and 6: > > > > > > > > > > X. Effect > > on > > > > Routing > > > > > > > > > > The model > > used > > > > for in a 802.16 network may have a significant > > > > > impact on > > how > > > > routing protocols are run over such a network. > > > > > The > > deployment > > > > model presented in this document discusses the > > > > > least > > impacting > > > > model on routing as connectivity on the provider > > > > > edge is > > > > intentionally limited to point to point connectivity > > > > > from one BS > > to > > > > any one of multiple MSs. Any other deployment > > > > > model may > > cause > > > > a significant impact on routing protocols, > > > > > however, > > but > > > > they are outside the scope of this document. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------ > > > > > > > > > > > > > > _______________________________________________ > > > > > 16NG mailing > > list > > > > > 16NG@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/16ng > > > > > > > > > > > > > > > End of 16NG > > > > Digest, Vol 5, Issue 22 > > > > > > > > > *********************************** > > > > > >
_______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng
- [16NG] Redundant DAD for RFC3041 in IPv6CS Daniel Park
- RE: [16NG] Redundant DAD for RFC3041 in IPv6CS Premec, Domagoj