Subject: [v6ops] draft-byrne-v6ops-clatip-01

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 21 Apr 2014 16:16:18 +0000

Following up from the recent meeting.

We discussed clatip. The outcome was that we wanted to know what softwire wanted done with it, and I took the action to ask. 

The response from the softwire chairs was that they wanted to consider the draft there, and advance it from there. However, it appears to be bottlenecked. So, the softwire chairs have stepped back.

I want the opinion of v6ops. Do we need this, or not? If we need this, we should adopt it, and then (I think) go to an immediate WGLC and potentially advance it. If it’s not needed, we should say it is not needed.

Please reply in this thread.

On Apr 21, 2014, at 5:55 AM, Yong Cui <[email-masked]> wrote:

> Hi Fred,
> 
> Thanks for your email and reminding.
> 
> You are right that we are glad to take this work in Softwire as we discussed in March. However, for some reasons we need to focus on MAP package right now. There is the consensus that Softwire will NOT take any new work before we submit the MAP package to IESG. There are even some other wg items blocked in Softwire at this moment. We are trying to solve the MAP issues asap and accelerate the process. But I'm afraid we still need some time.
> 
> So if you'd like to take this work in v6ops, please do so. Otherwise, we still need to wait for some time before taking it in Softwire.
> 
> Thanks for understanding and let us know your decision.
> 
> Yong 
> 
> On 2014-4-19, at 上午12:23, Fred Baker (fred) <[email-masked]> wrote:
> 
>> Softwire chairs:
>> 
>> In March, you indicated that you wanted to progress this in softwire. The authors haven’t heard from you and are looking for guidance. Pick one: do you want it, or do you want it done for you?
>> 
>> Fred
>> 
>> 
>> On Apr 18, 2014, at 4:55 AM, TheIpv6guy . <[email-masked]> wrote:
>> 
>>> *fixing the softwire chair email address since it bounced.
>>> 
>>> On Fri, Apr 4, 2014 at 5:44 PM, Fred Baker (fred) <[email-masked]> wrote:
>>>> 
>>>> On Apr 4, 2014, at 6:34 AM, Cb B <[email-masked]> wrote:
>>>> 
>>>> Hello folks,
>>>> 
>>>> No follow-up in a week. I assume the below explanation and exisiting text
>>>> are ok.
>>>> 
>>>> To restate, this I-D simply generalizes the scope of 192.0.0.0/29.  There is
>>>> no guidance on how specific addresses may be used. It is assumed the
>>>> deploying party will not cause a conflict on the host by assiging the same
>>>> address to the host multipls times.... as that is a general ip configuration
>>>> rule.
>>>> 
>>>> I will ask v6ops to accept this i-d and direct them to this thread to see
>>>> the softwire view.
>>>> 
>>>> 
>>>> My understanding is that softwires wants to progress this one. I guess I’d
>>>> like to hear from the softwires chairs before bringing it back.
>>>> 
>>> 
>>> 
>>> Fred,
>>> 
>>> It has been 14 days since your  email.  I am not sure if you sent the
>>> email to the wrong address of fixed it.  Either way, i would like to
>>> make progress on this I-D in v6ops since this I-D is about a
>>> generalized approach that exceeds the bounds of softwires.  This has
>>> also been presented twice in person to v6ops.
>>> 
>>> Cameron
>>> 
>>>> CB
>>>> 
>>>> On Mar 29, 2014 4:59 AM, "Cb B" <[email-masked]> wrote:
>>>>> 
>>>>> On Thu, Mar 27, 2014 at 3:38 PM, Dave Thaler <[email-masked]>
>>>>> wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Softwires [mailto:[email-masked]] On Behalf Of Cb B
>>>>>>> Sent: Thursday, March 27, 2014 10:58 AM
>>>>>>> To: [email-masked]
>>>>>>> Subject: [Softwires] draft-byrne-v6ops-clatip-01
>>>>>>> 
>>>>>>> Hi Softwires,
>>>>>>> 
>>>>>>> Ales presented draft-byrne-v6ops-clatip-01 in softwires at the last
>>>>>>> IETF
>>>>>>> meeting.
>>>>>>> 
>>>>>>> I am attempting to have this I-D adopted by v6ops, but v6ops requested
>>>>>>> feedback from softwires first.
>>>>>>> 
>>>>>>> Pertaining to the minutes, i would like to address some topics to make
>>>>>>> sure it
>>>>>>> is ok  for v6ops to move forward with adoption
>>>>>>> 
>>>>>>> 
>>>>>>> https://tools.ietf.org/wg/softwire/minutes?item=minutes-89-softwire.html
>>>>>>> 
>>>>>>> The addresses, both in DS-lite and 464xlat, never appears on the wire
>>>>>>> so
>>>>>>> there is no chance of overlap or collision.
>>>>>> 
>>>>>> Disagree, that conclusion doesn't follow (and in my experience it's
>>>>>> wrong).
>>>>>> Overlap/collision happens when there are two interfaces on the same host
>>>>>> (even if they're not in use simultaneously).   The collisions can affect
>>>>>> the routing table (if the host implements in such a way), ACLs like in
>>>>>> host firewall policies and such, and various application-layer uses.
>>>>>> 
>>>>> 
>>>>> Ah, i see your point.  If the host is itself both a B4 and a CLAT at
>>>>> the same time, then this collision may occur within the host, not on
>>>>> the wire.
>>>>> 
>>>>>> It's fine to specify use as the default range (e.g. for 464xlat or
>>>>>> DS-lite) but
>>>>>> important to never constrain it to only that range, assuming the range
>>>>>> is made
>>>>>> non-DS-lite specific.
>>>>>> 
>>>>>> -Dave
>>>>> 
>>>>> Is there such a constraint that would cause a problem?
>>>>> 
>>>>> Looking at RFC6333 and draft-byrne-v6ops-clatip, i see that RFC6333
>>>>> says the B4 SHOULD use 192.0.0.2.  To a rational person, a good reason
>>>>> to not use  192.0.0.2 is that it is in use for a CLAT interface on the
>>>>> same host, which fits with the SHOULD wording.
>>>>> 
>>>>> Is there some text that you could suggest that may clarify this
>>>>> situation in draft-byrne-v6ops-clatip or is it ok for v6ops to adopt
>>>>> as-is?  As it stands, the I-D simply says that 192.0.0.0/29 will be
>>>>> generalized without making any further statements how addresses may be
>>>>> used within that range.
>>>>> 
>>>>> CB
>>>> 
>>>> 
>>>> ------------------------------------------------------
>>>> 8 issues in virtual infrastructure
>>>> http://dcrocker.net/#fallacies
>>>> 
>> 
>> ------------------------------------------------------
>> 8 issues in virtual infrastructure
>> http://dcrocker.net/#fallacies
>> 
> 
> 

------------------------------------------------------
8 issues in virtual infrastructure
http://dcrocker.net/#fallacies

---

From: Tore Anderson <[email-masked]>
Date: Tue, 22 Apr 2014 07:29:10 +0200

* Fred Baker (fred)

> Do we need this, or not?

I think this is useful, yes.

Tore

---

From: "Heatley, Nick" <[email-masked]>
Date: Tue, 22 Apr 2014 15:27:05 +0000

Needed, I'd like to see this standardised here.

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
Sent: 21 April 2014 17:16
To: V6 Ops List
Subject: [v6ops] draft-byrne-v6ops-clatip-01

On Apr 21, 2014, at 5:55 AM, Yong Cui <[email-masked]> wrote:

>>>> No follow-up in a week. I assume the below explanation and 
>>>> exisiting text are ok.
>>>> 
>>>> To restate, this I-D simply generalizes the scope of 192.0.0.0/29.  
>>>> There is no guidance on how specific addresses may be used. It is 
>>>> assumed the deploying party will not cause a conflict on the host 
>>>> by assiging the same address to the host multipls times.... as that 
>>>> is a general ip configuration rule.
>>>> 
>>>> I will ask v6ops to accept this i-d and direct them to this thread 
>>>> to see the softwire view.
>>>> 
>>>> 
>>>> My understanding is that softwires wants to progress this one. I 
>>>> guess I’d like to hear from the softwires chairs before bringing it back.
>>>> 
>>> 
>>> 
>>> Fred,
>>> 
>>> It has been 14 days since your  email.  I am not sure if you sent 
>>> the email to the wrong address of fixed it.  Either way, i would 
>>> like to make progress on this I-D in v6ops since this I-D is about a 
>>>>>>> Ales presented draft-byrne-v6ops-clatip-01 in softwires at the 
>>>>>>> last IETF meeting.
>>>>>>> 
>>>>>>> I am attempting to have this I-D adopted by v6ops, but v6ops 
>>>>>>> requested feedback from softwires first.
>>>>>>> 
>>>>>>> Pertaining to the minutes, i would like to address some topics 
>>>>>>> to make sure it is ok  for v6ops to move forward with adoption
>>>>>>> 
>>>>>>> 
>>>>>>> The addresses, both in DS-lite and 464xlat, never appears on the 
>>>>>>> wire so there is no chance of overlap or collision.
>>>>>> 
>>>>>> Disagree, that conclusion doesn't follow (and in my experience 
>>>>>> it's wrong).
>>>>>> the routing table (if the host implements in such a way), ACLs 
>>>>>> like in host firewall policies and such, and various application-layer uses.
>>>>>> 
>>>>> 
>>>>> Ah, i see your point.  If the host is itself both a B4 and a CLAT 
>>>>> at the same time, then this collision may occur within the host, 
>>>>> not on the wire.
>>>>> 
>>>>>> important to never constrain it to only that range, assuming the 
>>>>>> range is made non-DS-lite specific.
>>>>>> 
>>>>>> -Dave
>>>>> 
>>>>> Looking at RFC6333 and draft-byrne-v6ops-clatip, i see that 
>>>>> RFC6333 says the B4 SHOULD use 192.0.0.2.  To a rational person, a 
>>>>> good reason to not use  192.0.0.2 is that it is in use for a CLAT 
>>>>> interface on the same host, which fits with the SHOULD wording.
>>>>> 
>>>>> situation in draft-byrne-v6ops-clatip or is it ok for v6ops to 
>>>>> adopt as-is?  As it stands, the I-D simply says that 192.0.0.0/29 
>>>>> will be generalized without making any further statements how 
>>>>> addresses may be used within that range.
>>>>> 
>>>>> CB
>>>> 
>>>> 

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 23 Apr 2014 08:20:14 +0200

> Sent: Monday, April 21, 2014 6:16 PM
> To: V6 Ops List
> We discussed clatip. The outcome was that we wanted to know
> what softwire wanted done with it, and I took the action to
> ask.
>
> The response from the softwire chairs was that they wanted to
> consider the draft there, and advance it from there. However,
> it appears to be bottlenecked. So, the softwire chairs have
> stepped back.
>
> I want the opinion of v6ops. Do we need this, or not? If we
> need this, we should adopt it, and then (I think) go to an
> immediate WGLC and potentially advance it. If it’s not
> needed, we should say it is not needed.
>

192.0.0.0/29 seems to be a natural choice for IPv6 transition
solutions that require a non-routed numbered IPv4 interface.
(such as 464XLAT)

I support advancing of this work.

Ales

Zásady komunikace, které společnost T-Mobile Czech Republic a.s. užívá při sjednávání smluv, jsou uvedeny zde  http://www.t-mobile.cz/zasady. Není-li v zásadách uvedeno jinak, nepředstavuje tato zpráva konečný návrh na uzavření či změnu smlouvy ani přijetí takového návrhu. The communication principles which T-Mobile Czech Republic a.s. applies when negotiating contracts are defined here http://www.t-mobile.cz/principles. Unless otherwise stated in the principles, this message does not constitute the final offer to contract or an amendment of a contract or acceptance of such offer.

---

From: <[email-masked]>
Date: Wed, 23 Apr 2014 08:31:38 +0200

Hello *,

yes, I would like to see this advanced please. Necessary to bring forward IPv6-only access solutions reliably.

Holger

---

From: <[email-masked]>
Date: Wed, 23 Apr 2014 10:10:49 +0200

This proposition is useful for IPv6-only design and I support its adoption. 
David

-----Message d'origine-----
De : v6ops [mailto:[email-masked]] De la part de Fred Baker (fred)
Envoyé : lundi 21 avril 2014 18:16
À : V6 Ops List
Objet : [v6ops] draft-byrne-v6ops-clatip-01

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Wed, 23 Apr 2014 11:18:45 +0200

Dear Fred, all,

I support the adoption of this draft. 

Once comment about the proposed name of the IPv4 prefix, I would vote for "IPv4 service continuity Prefix" (or something similar) instead of "IPv6 Transitional Technology IPv4 Prefix".

Cheers,
Med

>We discussed clatip. The outcome was that we wanted to know what softwire
>wanted done with it, and I took the action to ask.
>
>The response from the softwire chairs was that they wanted to consider the
>draft there, and advance it from there. However, it appears to be
>bottlenecked. So, the softwire chairs have stepped back.
>
>I want the opinion of v6ops. Do we need this, or not? If we need this, we
>should adopt it, and then (I think) go to an immediate WGLC and potentially
>advance it. If it’s not needed, we should say it is not needed.
>
>> You are right that we are glad to take this work in Softwire as we
>discussed in March. However, for some reasons we need to focus on MAP
>package right now. There is the consensus that Softwire will NOT take any
>new work before we submit the MAP package to IESG. There are even some
>other wg items blocked in Softwire at this moment. We are trying to solve
>the MAP issues asap and accelerate the process. But I'm afraid we still
>need some time.
>>
>> So if you'd like to take this work in v6ops, please do so. Otherwise, we
>still need to wait for some time before taking it in Softwire.
>>
>>> In March, you indicated that you wanted to progress this in softwire.
>The authors haven’t heard from you and are looking for guidance. Pick one:
>do you want it, or do you want it done for you?
>>>
>>> Fred
>>>
>>>
>There is
>wire
>range