Subject: [v6ops] BIH pointer in 464XLAT

From: Cameron Byrne <[email-masked]>
Date: Thu, 13 Sep 2012 08:50:45 -0700

Joel wrote:

---------- Forwarded message ----------
From: joel jaeggli <[email-masked]>
Date: Wed, Sep 12, 2012 at 6:19 PM
Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope
To: Lorenzo Colitti <[email-masked]>
Cc: IPv6 Ops WG <[email-masked]>

On 9/12/12 6:06 PM, Lorenzo Colitti wrote:
>
> On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I think that there are two consensuses that we have reached. One
>     is that 464XLAT, although we still need a -08 to finalize it,
>     enjoys a rough consensus; you are the primary person objecting to it.
>
>
> 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, or 2^24+2^20+2^16)

with my wg chair hat off, I don't see this as desirable.

> 2. Whether to mention BIH or not.

again in the same role, I think specifying it should be outside the
scope of the document. mentioning it is not the same as specifying it.

Regarding 1, the plan is to remove prefix sharing and move the ideas
learned there with reserved IID to a specific and seperate I-D

Regarding 2, the authors would like to mention BIH for completeness to
provide a pointer to how the ietf has defined all stateful v4 and v6
translation permutations, as shown in the traffic treatment table
http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-9.2

Since this is a wg doc, we need the wg view.

I believe Remi's text is acceptable.  Others' thoughts?

http://www.ietf.org/mail-archive/web/v6ops/current/msg14252.html

CB

---

From: Hui Deng <[email-masked]>
Date: Thu, 13 Sep 2012 18:26:27 +0100

For 2, I second Cameron's recommendation here.

I don't see the reasonable exucse to change this unnormative text, and
those text which has been adopted before with the discussion. For the
operation consideration, it's quite clear that two future users
(operators) of this specification expressed they want this.
-Hui
2012/9/13 Cameron Byrne <[email-masked]>

> > On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) <[email-masked]<mailto:
> [email-masked]>> wrote:
> >
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 14 Sep 2012 09:45:53 +0900

I disagree. As I said before, I see no reason to mention BIH in this
specification.

The reason is that the suggested text provides no useful information. All
it says is "you can use BIH with 464xlat if you want". This is
superfluous. BIH is a standards track RFC. Operators are welcome to deploy
it, either with 464xlat or without. We don't need to state that obvious
fact here. If there was some useful text on *how* to integrate the two, or
caveats on how *not* to integrate the two, I could see value in mentioning
BIH. As it is, all we have is an advertisement for another transition
method (whose applicability, as many have noted in this thread, is far in
the future).

As for the specific points in this email:

1. Saying "we agreed to this text in the past, so we cannot remove it now"
not relevant for two reasons. First, the text was not agreed to by the WG.
It was put in by the authors on the suggestion of some WG participants, but
other WG participants are disagreeing to it. Secondly, if we agreed to some
text in the past, but don't agree to it now, then we should change it.
Internet-drafts are work in progress, and the WG must be able to change the
draft as it sees fit up to the close of last call. If we don't agree on the
text now, we should not shrink from removing it just to save face.

2. Saying "operators want to use BIH" is not a reason to cite BIH. If
operators want to use BIH, they are free to deploy it. It's a standards
track RFC.

---

From: GangChen <[email-masked]>
Date: Fri, 14 Sep 2012 11:53:16 +0800

Your statement just helps to confirm the divergence from original
texts is unreasonable, but the draft needs to progress.  Every time
you say "disagree", there are plenty of technical answers provided to
clarify. However, whatever we said you just ignore it without
justifications and definitely would say *I disagree* in next time,
like you said *I don't think "restarting the discussion" is going to
help convince me *

I don't want to manage to convince you. But your statement below
somehow lets me think what you have described is FUD, and you suggest
that because "we cannot have it, since somebody would take the
advantage of advertisement". I have no idea of the "advertisement",
but the truth is the draft originally covers the table and would like
to fill out it. Afterwards, a participant (no business with
"advertisement" intention) technically proposed the RFC6535 fill the
gap. And the authors agreed and you acquiesce it (at lease it doesn't
matter to you). Some operators who doing those things see such chance
and put efforts like to progress the work better. But last minute, you
say "Stop it, don't do the thing".

Saying "If there was some useful text on *how* to integrate the two,
or caveats on how *not* to integrate the two, I could see value in
mentioning BIH.” It's worth to note current words are actually coming
from your suggestion
http://www.ietf.org/mail-archive/web/v6ops/current/msg14200.html.

What have to say already sufficiently clarified after the intensive
discussions. Leaving aside the operators things and all FUD, please
note people just want to fill out the table technically using IETF
technology. This table was appeared since draft-00. And people who
want adoptions of 464xlat really expect the progress.

Many thanks

Gang

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 14 Sep 2012 13:01:05 +0900

On Fri, Sep 14, 2012 at 12:53 PM, GangChen <[email-masked]> wrote:

> discussions.

Ok then. Let's stop this discussion and ask the chairs to gauge whether
they see consensus on this. If the chairs say they think there is, then we
can all shut up and move on.

Fred, Joel: is it your determination as chairs that there is consensus
within the WG to include mention of BIH in this document?

Cheers,
Lorenzo

---

From: GangChen <[email-masked]>
Date: Fri, 14 Sep 2012 13:03:10 +0800

> within the WG to include mention of BIH in this document?

To be fair, the questions should be
1) Is consensus within the WG to keep the mention of BIH in this document?
2) Is consensus within the WG to remove the mention of BIH in this document?

Best Regards

Gang

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Sep 2012 14:20:44 +0900

> they see consensus on this. 

-1 to the bih text, does not make an already complex subject easier to
   understand

randy

---

From: Tim Chown <[email-masked]>
Date: Fri, 14 Sep 2012 07:55:58 +0100

On 14 Sep 2012, at 01:45, Lorenzo Colitti <[email-masked]> wrote:

> I disagree. As I said before, I see no reason to mention BIH in this specification.

+1

Were this text Informational, I would be more relaxed about mentioning BIH, but since it's a BCP the bar to include such references should be much higher.

Hence my suggestion to write a separate Informational text on the applicability of BIH - and perhaps other alternatives - in this context.

Tim

---

From: Hui Deng <[email-masked]>
Date: Fri, 14 Sep 2012 08:06:28 +0100

I am the only author of BIH discussing here, guess Cameron and Remi are
not, advertisement is overstated and may not be appropriate here. And the
only real users of those specification had said they want this. I would
expect others's comment would better "if you don't use this, please dont'
comment on this unnormative text here"

I agree " If there was some useful text on *how* to integrate the two, or
caveats on how *not* to integrate the two, "
Here is proposal:

When 464xlat integrates with other IPv6only access transition technology
such as BIH, IPv4-only app with BIHprocessing could communicate with
IPv6-server. A DNS query initiated by theapplication would be processed by
BIH ENR to generate both A and AAAA and needsconsidering below

1) When A responses are received, 464xlatwould take the role
2) When A and AAAA responses are received,464xlat would take the role
3) When only AAAA responses are received,it's the case of IPv4-IPv6
communication. ENR embedded in BIH would interceptsAAAA records and create
the synthetic IPv4 address and corresponding themapping. Afterwards, IPv4
applications send the packages to the synthetic IPv4address. Protocol
translator would take the rule of IPv4-IPv6 translation andachieve
IPv4-IPv6 communication.

I am in the business trip out of China and will take long time flight
shortly, so may not reply in time.

thanks a lot

-Hui

2012/9/14 Lorenzo Colitti <[email-masked]>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 14 Sep 2012 16:22:14 +0900

> translator would take the rule of IPv4-IPv6 translation andachieve

Has this been tested and verified to work? Is there an implementation?

We should not include text in a BCP if it has never been implemented or
tested.

---

From: Rémi Després <[email-masked]>
Date: Fri, 14 Sep 2012 09:37:48 +0200

Le 2012-09-14 à 09:22, Lorenzo Colitti a écrit :

> When 464xlat integrates with other IPv6only access transition technology such as BIH, IPv4-only app with BIHprocessing could communicate with IPv6-server. A DNS query initiated by theapplication would be processed by BIH ENR to generate both A and AAAA and needsconsidering below
> 
> 3) When only AAAA responses are received,it's the case of IPv4-IPv6 communication. ENR embedded in BIH would interceptsAAAA records and create the synthetic IPv4 address and corresponding themapping. Afterwards, IPv4 applications send the packages to the synthetic IPv4address. Protocol translator would take the rule of IPv4-IPv6 translation andachieve IPv4-IPv6 communication.
> 
> We should not include text in a BCP if it has never been implemented or tested.

---

From: Rémi Després <[email-masked]>
Date: Fri, 14 Sep 2012 09:41:22 +0200

OOPS, I was just reading this mail, without intention to send an answer.

---

From: Hui Deng <[email-masked]>
Date: Fri, 14 Sep 2012 11:10:29 +0100

> We should not include text in a BCP if it has never been implemented or

==> we are working on the integration of this two code, and for current
proposed text about this logic part, it has been implemented and works, I
believe our code could finish before this draft moving to RFC editor.

thanks,

-Hui

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 14 Sep 2012 12:20:42 +0200

Fully agree with Lorenzo.

-Woj.

---

From: t.petch <[email-masked]>
Date: Fri, 14 Sep 2012 11:22:15 +0100

----- Original Message -----
From: "Lorenzo Colitti" <[email-masked]>
To: "Hui Deng" <[email-masked]>
Cc: "IPv6 Ops WG" <[email-masked]>
Sent: Friday, September 14, 2012 1:45 AM

> method (whose applicability, as many have noted in this thread, is far
in

Lorenzo,

I agree, and would go further. I think that text such as that proposed
gets close to being an endorsement of BIH, which I do not believe that
I, we, are in a position to give.  This area of melding two disparate
technologies is a difficult one, one where there are likely to be
pitfalls.  Thus DHCPv6-PD is an excellent solution - ah, not available
just yet.  Proxy ND looks good - ah, sets up loops. This information
comes from discussions on the list, discussions which we have not yet
had about BIH; it has gotten a mention and that is it.  So what is wrong
with BIH? I believe that we do not yet know - the RFC is Feb 2012 - and
so should be wary about saying anything that has overtones of 'here is
another good solution'.  Play safe, stick to what we have discussed and
omit BIH.

Tom Petch

> >> >     enjoys a rough consensus; you are the primary person
objecting to
> >> it.
> >> >
> >> > 1. Whether to ask IANA to reserve IIDs, and if so, how many (1,
2^32,
> >> or 2^24+2^20+2^16)

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 14 Sep 2012 11:20:30 -0500

I favor keeping BIH text.
The authors believe in it that's why they included the text. Reading
Hui's mail, there is at least one implementation, which removes
Lorenzo's concern, I think.

Regards,

Behcet

---

From: Hui Deng <[email-masked]>
Date: Sat, 15 Sep 2012 02:51:11 +0200

we are working on the integration of two works, for this written text part,
it has finished and works

thanks,

-Hui

tested.