[16NG] Redundant DAD for RFC3041 in IPv6CS
"Daniel Park" <soohongp@gmail.com> Wed, 09 May 2007 14:44 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 1HlnOl-0001px-2U; Wed, 09 May 2007 10:44:11 -0400
Received: from 16ng by megatron.ietf.org with local (Exim 4.43)
id 1HlnOk-0001ps-2H
for 16ng-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 10:44:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1HlnOj-0001ph-Od
for 16ng@ietf.org; Wed, 09 May 2007 10:44:09 -0400
Received: from wr-out-0506.google.com ([64.233.184.235])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlnOg-0005ZE-PN
for 16ng@ietf.org; Wed, 09 May 2007 10:44:09 -0400
Received: by wr-out-0506.google.com with SMTP id 71so222771wri
for <16ng@ietf.org>; Wed, 09 May 2007 07:44:06 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition;
b=bAW04tShNbOSCFP6vzVuUck6B7wdXilhr1BLCtvjobChqx06slU7o7fliTXaB3sL0xGKoNevsHtl6mzyydIOJxJzKzZfJWysmWg/gg3rZTZNf3M/zxWVftvJRur3vVRj65e5eZLmIXhmuOFAwwLJFGnRjGi80faGds7IhhDa5ig=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition;
b=O3p328pZ8sm+LLSHBs2rtPbZTxSJJXfO45LEktvdXrW/kofuNUOrfA4fqpniLF/Zgf2InKRPFJ/Z4/gQSatlUbpnjheymynjECN2o/fuLYW2CUoC19wK2M/yeGwLxg9x5aILFYcpZsV47STLZ1kLG/UBL+Y7eJwmij51GblgCY8=
Received: by 10.115.91.2 with SMTP id t2mr190244wal.1178721845513;
Wed, 09 May 2007 07:44:05 -0700 (PDT)
Received: by 10.115.94.7 with HTTP; Wed, 9 May 2007 07:44:05 -0700 (PDT)
Message-ID: <f7c7d76e0705090744y395b6658macaa4fb6e760f2@mail.gmail.com>
Date: Wed, 9 May 2007 16:44:05 +0200
From: "Daniel Park" <soohongp@gmail.com>
To: "=?EUC-KR?B?sei7877w?=" <kim.sangeon@gmail.com>
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2ed9477f79f24ff120e9894ad9dc9cb5
Cc: 16ng@ietf.org
Subject: [16NG] Redundant DAD for RFC3041 in IPv6CS
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="===============0180198921=="
Errors-To: 16ng-bounces@ietf.org
(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-analysis-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