Re: [BEHAVE] Wkp

Xu Xiaohu <xuxh@huawei.com> Thu, 24 December 2009 02:07 UTC

Date: Thu, 24 Dec 2009 10:06:48 +0800
From: Xu Xiaohu <xuxh@huawei.com>
In-reply-to: <4B32744A.8070904@gmail.com>
To: 'cam byrne' <cb.list6@gmail.com>, 'Brian E Carpenter' <brian.e.carpenter@gmail.com>, 'Iljitsch van Beijnum' <iljitsch@muada.com>
Message-id: <003e01ca843d$c037e300$e30c6f0a@china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset="gb2312"
Content-transfer-encoding: quoted-printable
Thread-index: AcqEDhIBNtIZELofR+iupWVoT14cEQAKWqMg
Cc: mohamed.boucadair@orange-ftgroup.com, behave@ietf.org
Subject: Re: [BEHAVE] Wkp
Precedence: list

> -----邮件原件-----
> 发件人: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] 代表 cam
> byrne
> 发送时间: 2009年12月24日 4:25
> 收件人: Brian E Carpenter; Iljitsch van Beijnum
> 抄送: cam byrne; behave@ietf.org; mohamed.boucadair@orange-ftgroup.com
> 主题: Re: [BEHAVE] Wkp
> 
> I agree with Brian. Strong wkp may work for enterprise but not service
provider
> who are designing to cgn / lsn scale.  Nsp is the only option for linear
scaling
> at this point.  Wkp will work today for enterprise  scale deployments, but
the
> positive attributes of wkp are not available to large scale service
providers
> today since there is not a weak wkp.

Support. Besides the WKP (e.g., 64:ff9b::/96) and NSP already defined in the
draft-ietf-behave-address-format, we need a third option (temporarily called
hybrid type prefix, HTP in short). As depicted in the following figure, it
starts with a well-know binary value (e.g., 0x15) but the following part is
network specific. Note that the boundary between the well-known binary value
and the Network Specific Part is just an example. This HTP can be used for
the load-balancing in the IPv6 network to IPv4 internet scenario. To ease
the deployment further, a special /80 prefix(e.g., 15::/80) can be reserved,
the rightmost 8 bits of the Network Specific Parts can used to assign
different values to different NAT boxes. This special /80 prefix can be used
independently by different IPv6 site networks.

+--------+--------------------------------+-----------------+
|00010101|Network Specific Parts (88 bits)|IPv4 addr (32bit)|
+--------+--------------------------------+-----------------+
             (HTP Example)

+--------+-----------------------+--------+-----------------+
|00010101|  All zero (80 bits)   |(8 bits)|IPv4 addr (32bit)|
+--------+-----------------------+--------+-----------------+
( A specific HTP reserved for load-balancing usage in IPv6 network to IPv4
internet scenario).

In fact, this hybrid type prefix has been discussed in other thread
"Reason(s) for Modified EUI-64 format to apply to ALLnon-0::/3 IPv6
addresses ?". For more details, please see
http://www.ietf.org/mail-archive/web/behave/current/msg07800.html  

Xiaohu

> also, yet another load balancer or stateful device is not an option at the
scale
> service providers are designing for.  The dns64 must be able to naturally
drive
> the traffic in discrete increments statelessly to the stateful nat64.
> Breaking this massive amount of state into smaller chunks is the only way
we
> can solve the scaling issue.  Creating yet another layer of load balancer
state
> will not scale.
> 
> Cb
> 
> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> >On 2009-12-24 07:07, Iljitsch van Beijnum wrote:
> >> On 23 dec 2009, at 18:59, Christian Huitema wrote:
> >>
> >>> But that will be a different draft, not the current addressing draft.
> >>
> >> The current draft isn't set in stone yet, if there is rough consensus
that
> this is a useful feature we can incorporate it, IMO.
> >>
> >> As far as I'm concerned, I don't think adding load balancing bits
breaks
> anything, so I would support it if others want this in this document.
> >
> >Well, for example, it makes using a WKP-based address in a referral even
> >more alarming. What if those load-balancing bits are valid in the context
> >of the referring host but meaningless in the context of the host that
> >receives the referral?
> >
> >Isn't this exactly why we need to document the NSP case?
> >
> >   Brian
> >
> >
> >   Brian

Re: [BEHAVE] Wkp Iljitsch van Beijnum
[BEHAVE] Comments on draft-ietf-behave-ftp64-00 Reinaldo Penno
[BEHAVE] Wkp cam byrne
Re: [BEHAVE] Wkp mohamed.boucadair
Re: [BEHAVE] Wkp Cameron Byrne
Re: [BEHAVE] Wkp Christian Huitema
Re: [BEHAVE] Wkp Christian Huitema
Re: [BEHAVE] Wkp Iljitsch van Beijnum
Re: [BEHAVE] Wkp GangChen
Re: [BEHAVE] Wkp marcelo bagnulo braun
Re: [BEHAVE] Wkp Christian Huitema
Re: [BEHAVE] Wkp Iljitsch van Beijnum
[BEHAVE] RE : Wkp mohamed.boucadair
Re: [BEHAVE] Wkp marcelo bagnulo braun
Re: [BEHAVE] Wkp Iljitsch van Beijnum
Re: [BEHAVE] RE : Wkp marcelo bagnulo braun
Re: [BEHAVE] Wkp Brian E Carpenter
Re: [BEHAVE] Wkp Iljitsch van Beijnum
Re: [BEHAVE] Wkp Brian E Carpenter
Re: [BEHAVE] Wkp Xu Xiaohu
Re: [BEHAVE] Wkp Dan Wing
Re: [BEHAVE] Wkp Xu Xiaohu