Subject: [BEHAVE] Wkp

From: cam byrne <[email-masked]>
Date: Wed, 23 Dec 2009 09:30:17 -0500

-------- Original Message --------
Subject: Wkp
From: cam byrne <[email-masked]>
To: [email-masked]
CC: null

Is 64:ff9b::/96 the only well known prefix or is any subnet of it wkp?  For example, if I can do 2 nat64 systems using 64:ff9b:1::/96 and 64:ff9b:2::/96 it helps me scale multiple nat64 spystems in the same region, which is critical for a service provider.  Without this, it cannot be expected that a service provider will use the wkp since scale will be bounded by vendor box limitations.  

I understand that if we do this, the host wont be able to automatically discover the local wkp unless we alias the base wkp as anycast on all nat64 systems in addition to dns64 handing out sub-wkp, which may make everyone happy.   This way we can scale linearly, identify nat'd flows at the host, and enable the host to pass nat64 manually without dns64.

Thoughts?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 Dec 2009 15:53:39 +0100

On 23 dec 2009, at 15:30, cam byrne wrote:

> Is 64:ff9b::/96 the only well known prefix or is any subnet of it wkp?  For example, if I can do 2 nat64 systems using 64:ff9b:1::/96 and 64:ff9b:2::/96 it helps me scale multiple nat64 spystems in the same region

We had some discussion about "weak WKP" and "strong WKP" where strong = everyone knows the values of all the 96 bits, and weak = you can recognize the WKP when you see it, but there are some additional bits in there that you can't predict so you still need to explicitly learn the WKP before you can use it.

The current draft doesn't address this.

With a strong WKP referrals between hosts served by different translators should work, with a weak WKP this is not necessarily the case.

---

From: <[email-masked]>
Date: Wed, 23 Dec 2009 15:54:27 +0100

Dear Cameron,

The current version of I-D.ietf-behave-address-format does not prevent you to use sub prefixes belonging to the WKP. Nevertheless, operational issues induced by the enforcement of such policy (e.g., for traffic engineering purposes) are out of scope of I-D.ietf-behave-address-format. 

IMHO, these considerations (and others such as how to ensure traffic symmetry for stateful NAT64) should be captured in a BCP like document. 

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de cam byrne
Envoyé : mercredi 23 décembre 2009 15:30
À : [email-masked]
Objet : [BEHAVE] Wkp

-------- Original Message --------
Subject: Wkp
From: cam byrne <[email-masked]>
To: [email-masked]
CC: null

Thoughts?   
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 23 Dec 2009 07:07:12 -0800

> With a strong WKP referrals between hosts served by different translators should work, with a weak WKP this is not necessarily the case.

Can you please explain in more detail how this scaling works with
strong WKP?  My goal is to scale linearly (n number of independent
NAT64 boxes).  Right now, i believe WKP does not support this.  The
weak WKP might help here, but you said there are some missing bits...
can you be more explcit on what the down fall is?

Is there still an issue if the n number of NAT64 boxes accept
translations from the WKP?  Or if one of n number of NAT64 in a region
announces the WKN prexfix?

Otherwise, i believe large service providers cannot use WKP.  It is
not practical for scaling.

Thanks,
Cameron

---

From: Christian Huitema <[email-masked]>
Date: Wed, 23 Dec 2009 15:35:18 +0000

> Is 64:ff9b::/96 the only well known prefix or is any subnet of it wkp?  For example, if I can do 2 nat64 
> systems using 64:ff9b:1::/96 and 64:ff9b:2::/96 it helps me scale multiple nat64 spystems in the same region, 
> which is critical for a service provider.  Without this, it cannot be expected that a service provider will 
> use the wkp since scale will be bounded by vendor box limitations.  

The document is unambiguous. 64:ff9b::/96 and 64:ff9b:1::/96 are different prefixes. To match 64:ff9b::/96, you need to match all 96 bits, not just 32 of them. If you want to do what you describe, you need to use network specific prefixes.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Wed, 23 Dec 2009 15:39:20 +0000

> can you be more explcit on what the down fall is?

We actually discuss this issue in the "stateless network translation" section. If you want multiple boxes to use the same prefix, you need them to coordinate their mappings. If you want administrative control, use multiple network specific prefixes.

There is no concept of "weak WKP" in the addressing draft. The point never came, and the definition of WKP as 96 bit long explicitly excludes the concept.

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 Dec 2009 17:06:47 +0100

On 23 dec 2009, at 16:07, Cameron Byrne wrote:

> NAT64 boxes).  Right now, i believe WKP does not support this.

If you need the NAT64 boxes to be in a place where you can't make routing flow part of your traffic to each, then the strong WKP (where all 96 bits are the same for all translators) won't help you and you would either need to get single big translator or put a load balancer in front of a bunch of smaller ones.

> The

Not sure what you mean by downfall...

What I meant is that you could have 64:ff9b:aaaa::/96 and 64:ff9b:bbbb::/96 etc which are all recognized as part of the WKP because they're all in 64:ff9b::/32.

The issue would be when host A tells host B to connect to host C on 64:ff9b:aaaa::192.0.2.1 while host B uses the 64:ff9b:bbbb::/96 translator prefix. Or to host C across the world where the 64:ff9b:aaaa::/96 prefix isn't used.

In the first case it can work to a certain degree but slightly unexpectedly because this session goes through a different translator and therefore uses a different IPv4 address. In the second case if the aaaa translator address goes nowhere the referral fails, so you'd have to cover the whole 64:9bff::/32 to avoid that. So rather than 64:9bff:aaaa::/96 and 64:9bff:bbbb::/96 you would probably want to use 64:9bff::/33 and 64:9bff:8000::/33 to cover that whole /32.

> announces the WKN prexfix?

I don't know...

---

From: GangChen <[email-masked]>
Date: Thu, 24 Dec 2009 00:36:31 +0800

2009/12/23 Iljitsch van Beijnum <[email-masked]>

> > Is 64:ff9b::/96 the only well known prefix or is any subnet of it wkp?
>  For example, if I can do 2 nat64 systems using 64:ff9b:1::/96 and
> 64:ff9b:2::/96 it helps me scale multiple nat64 spystems in the same region
>
> We had some discussion about "weak WKP" and "strong WKP" where strong =
> everyone knows the values of all the 96 bits, and weak = you can recognize
> the WKP when you see it, but there are some additional bits in there that
> you can't predict so you still need to explicitly learn the WKP before you
> can use it.
>
> With a strong WKP referrals between hosts served by different translators
> should work, with a weak WKP this is not necessarily the case.
>

  I think the concepts of "Weak WKP" and "Strong WKP" are reasonable.
 Acoording to the draft, WKP is only adopted to stateful translation
deployments.
 All 96bits-matched rules make multiple nat64 load-balance impossible.
 These concepts could give more flexible usage of WKP.

BRs

Gang

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Dec 2009 18:06:13 +0100

[email-masked] escribió:
> Dear Cameron,
>
> The current version of I-D.ietf-behave-address-format does not prevent you to use sub prefixes belonging to the WKP.
well, actually, it does.
The current draft assigns the WKP to be 64:ff9b::/96
Hence,  64:ff9b:1::/96 for example, has not been assigned for this 
purpose and would still be in the IANA pool.
You could of course use it (as you could use any other prefix for that 
matter), but this is not supported by the current draft (or allocation 
policies)

In order to do that, we would need to change the WKP to be 64:ff9b::/32 
and then define the algorithm to be:
WKP+zero padding+IPv4 address
Then you could change the zero padding to whatever other padding you 
want, and then you are on track.

Regards, marcelo
>  Nevertheless, operational issues induced by the enforcement of such policy (e.g., for traffic engineering purposes) are out of scope of I-D.ietf-behave-address-format. 
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 23 Dec 2009 17:59:47 +0000

> want, and then you are on track.

We could, but this is certainly not what we set up to do, or what we decided. An important benefit about a well known prefix is that every translator using it will translate a given 32 bit IPv4 address into a specific 128 bit IPv6 address, with all bits exactly defined. In short, everybody can rely on this translation being understood everywhere. But for that, we need to specify all 96 bits of the prefix.

Med and Cameron are looking for a different design, in which part of the mapped addressed are used to indicate specific translators, or maybe some other purpose. There may be a market for that, but the Well Known Prefix is not designed to address it. In the short term, they can get their wishes by using network specific prefixes. If they want to get IETF reserved prefixes, they can do that by going through the process, submit a draft, get WG consensus, etc. But that will be a different draft, not the current addressing draft.

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 Dec 2009 19:07:19 +0100

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.

---

From: <[email-masked]>
Date: Wed, 23 Dec 2009 19:07:48 +0100

Dear Marcelo, 

I was referring to the absence of any statement in the draft to forbid the address translator to accept a PREFIX starting with 64:ff9b (emulating then an NSP) as input for the NSP-based address mappings.

Cheers,
Med

________________________________________
De : marcelo bagnulo braun [[email-masked]]
Date d'envoi : mercredi 23 décembre 2009 18:06
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : cam byrne; [email-masked]
Objet : Re: [BEHAVE] Wkp

well, actually, it does.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Dec 2009 19:11:16 +0100

Christian Huitema escribió:
> We could, but this is certainly not what we set up to do, or what we decided. 
Right, this issue was discussed at large in the hisorhima meeting and 
the rough consensus was that the WKP was a /96, knowing that this would 
prevent using different prefixes within the WKP for different translators.

Regards, marcelo

> An important benefit about a well known prefix is that every translator using it will translate a given 32 bit IPv4 address into a specific 128 bit IPv6 address, with all bits exactly defined. In short, everybody can rely on this translation being understood everywhere. But for that, we need to specify all 96 bits of the prefix.
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 Dec 2009 19:15:55 +0100

> Right, this issue was discussed at large in the hisorhima meeting and the rough consensus was that the WKP was a /96, knowing that this would prevent using different prefixes within the WKP for different translators.

Decisions are made on the mailinglist, not in meetings.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Dec 2009 19:19:17 +0100

> I was referring to the absence of any statement in the draft to forbid the address translator to accept a PREFIX starting with 64:ff9b (emulating then an NSP) as input for the NSP-based address map…
but the problem there is that 64:ff9b:2::/96 in the exmaple below 
belongs to IANA and not the ISP that is deploying the transaltion services.
You could do this with the NSP as Christian mentions, but not with any 
prefix starting with 64:ff9b: cause we are only asking for a 64:ff9b::/96.

in other words, is a problem of prefix allocation, not that the 
mechanisms doesn't support it (for some definition of support)

makes sense?

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Dec 2009 08:49:30 +1300

> 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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 Dec 2009 22:05:41 +0100

> of the referring host but meaningless in the context of the host that

I think I covered that in my message to Cameron earlier today. Or are you getting at something else?

At least in the non-/96 WKP case there is a chance to get it right, with an NSP you can only fail.

> Isn't this exactly why we need to document the NSP case?

You mean the non-/96 NSP business? No, I don't think so. Documenting it won't help with referrals, because those don't work with an NSP period.

Iljitsch (who is going to travel without a computer until sunday so don't expect detailed responses until next week.)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Dec 2009 14:13:43 +1300

> You mean the non-/96 NSP business? No, I don't think so. Documenting it won't help with referrals, because those don't work with an NSP period.

Yes, but inspecting the NSP will give a clue *why* it fails.

Referrals and NATs don't mix well, I think we agree on that. Happy holidays.

    Brian

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 24 Dec 2009 10:06:48 +0800

> -----邮件原件-----
> 发件人: [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:
> 
> >> 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.
> >

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 23 Dec 2009 21:39:39 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Iljitsch van Beijnum
> Sent: Wednesday, December 23, 2009 1:06 PM
> To: Brian E Carpenter
> Cc: cam byrne; [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] Wkp
> 
> >> 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.
> 
> I think I covered that in my message to Cameron earlier 
> today. Or are you getting at something else?
> 
> You mean the non-/96 NSP business? No, I don't think so. 
> Documenting it won't help with referrals, because those don't 
> work with an NSP period.

I agree that referrals of the NSP IPv6 will fail when the
peer is on a different network (and thus can't use the
origin network's prefix).

That's why IPv4 address referrals are useful when referring
to IPv4 peers.  And is what SIP does. 

And, I expect, what IPv6 applications will do -- if they
want to work with IPv4-only instances of the same application,
or want to work with IPv6-only instances of the same application,
or with dual-stack instances of the same application.

IPv6-only referrals are a myth.

-d

> Iljitsch (who is going to travel without a computer until 
> sunday so don't expect detailed responses until next week.)