Subject: Re: [BEHAVE] Wkp

From: Xu Xiaohu <[email-masked]>
Date: Thu, 24 Dec 2009 18:05:19 +0800

Hi all,

I would like to write a draft about this hybrid type prefix, is there
anybody else interested on co-authoring it?

Xiaohu

> -----邮件原件-----
> 发件人: Xu Xiaohu [mailto:[email-masked]]
> 发送时间: 2009年12月24日 10:07
> 收件人: 'cam byrne'; 'Brian E Carpenter'; 'Iljitsch van Beijnum'
> 抄送: [email-masked]'; [email-masked]'
> 主题: re: [BEHAVE] Wkp
> 
> 
> 
> > -----邮件原件-----
> > 发件人: [email-masked] [mailto:[email-masked]] 代表
cam
> > byrne
> > 发送时间: 2009年12月24日 4:25
> > 收件人: Brian E Carpenter; Iljitsch van Beijnum
> > 抄送: cam byrne; [email-masked]; [email-masked]
> > 主题: 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 <[email-masked]> 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