Re: [v6ops] FW: latest copy of rfc6204bis included

[Victor Kuarsingh <[e-mail]>]

I will need to concur with John here.

Ignoring real world problems is a mistake.  It has taken considerable
effort for key operators to move IPv6 programs forward.  Having these
programs hampered by avoidable issues risks both those deployments from
moving forward (bad for all of us), and may dampen others from starting
and moving forward.

IPv6 needs to go in.. And it needs to work well.  If we cannot attain
this, and have operational issues related to this it just puts undue
pressure operators in the forefront.

Regards,

Victor K



On 11-11-16 10:17 AM, "Brzozowski, John"
<[e-mail]> wrote:

>Mistakes with RFC6204 were made from the earliest versions, there is no
>harm admitting where mistakes were made.  In fact, this is healthy to
>ensure we do not make them again.
>
>The DHCPv6 client problem is a mistake in RFC6204 and my concern is that
>we are/were actively discussing allow it to live on in BIS.
>
>Ignoring real world experience and feedback is not part of this process
>last time I checked.
>
>John
>=========================================
>John Jason Brzozowski
>Comcast Cable
>e) mailto:[e-mail]
>o) 609-377-6594
>m) 484-962-0060
>w) http://www.comcast6.net
>=========================================
>
>
>
>
>On 11/16/11 10:06 AM, "Hemant Singh (shemant)" <[e-mail]> wrote:
>
>>Re: latest copy of rfc6204bis includedMark,
>> 
>>We should stop harking at rfc6204 that the document made quite a few
>>mistake.  Doesn¹t fly ­ the delta between rfc6204 and rfc6204bis that is
>>not transition tech is minor tweaks.  The DHCPv6 server storm problem
>>raised recently by Comcast is a not any mistake in RFC 6204.  What can an
>>IPv6 CE router document do changing the DHC or the ND protocols?
>>Further, I, Wes Beebee and Ole have already said several times the M and
>>the O bits in the RA just can¹t be used to signal start/stop to a DHCv6
>>client.  See use case below.
>> 
>>Also, at the last IETF it was v6ops who told us to fasttrack transition
>>tech in rfc6204bis and ship a new copy out ASAP.  So why are we thrashing
>>at this IETF for this goal?
>> 
>>Further, the rfc6204bis  document is already good for 6rd sunsetting, so
>>what specifically do we need from your new draft?  You new draft is also
>>in conflict with rfc6204bis.   Your document includes the text below
>>shown between squared braces.
>> 
>>[A 6rd CE MUST assign a forwarding metric such that native IPv6egress is
>>preferred for traffic outside the 6rd domain when 6rd
>>and native IPv6 interfaces are active.]
>> 
>>Sunsetting 6rd involves concurrent operation of 6rd and native IPv6.  In
>>such an operation the switching in the IPv6 CE router is source-based
>>routing while your text above speaks of destination based routing.   Our
>>document says
>> 
>>[5.  Selection of 6rd tunnel or native IPv6 output interface on the CE
>> router is determined by the source IPv6 address of the packet
>>     from a host.]
>> 
>>Hemant
>> 
>>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>Hemant Singh (shemant)
>>Sent: Wednesday, November 16, 2011 8:32 AM
>>To: [e-mail]
>>Subject: [v6ops] FW: latest copy of rfc6204bis included
>>
>>
>> 
>>For anyone who thinks the IPv6 ND RA¹s M or the O bits can signal
>>start/stop DHCPv6 to a client, please see this email from our IPv6 CE
>>router design team discussion.  It¹s is bad idea.
>> 
>>Hemant
>> 
>>From: Wes Beebee (wbeebee)
>>Sent: Wednesday, November 09, 2011 3:19 AM
>>To: Lorenzo Colitti; Hemant Singh (shemant)
>>Cc: Wojciech Dec (wdec); [e-mail]; Erik Kline; John
>>Jason Brzozowski
>>Subject: Re: latest copy of rfc6204bis included
>>
>>
>> 
>>Lorenzo -
>>
>>>> I don't see any text that requires the CE router not to do DHCPv6 PD
>>>>if M=0 
>>>> and O=0. Where is it?
>>
>>The reason you do not see such text is that we don¹t want to introduce
>>anything deliberately in RFC 6204bis that will explicitly break in the
>>multi-homing case.  Even though it¹s ³out of scope² - we don¹t want to
>>invalidate the whole document when it becomes ³in scope².
>>
>>For example, imagine a case where a home router is connected to a hub and
>>to two modems which go to two different service providers.  One provider
>>sets M=O=0 and the other provider sets M=O=1.  If setting M=O=0 turns off
>>DHCPv6 and M=O=1 triggers a reinitialization, then imagine the case where
>>each service provider sets the RA interval to 1 second and the RA¹s come
>>in alternating every 0.5 second.  In that case, the CE router will be
>>re-doing DHCPv6 every second and will create a DHCPv6 storm for the
>>service provider.
>>
>>That¹s why we explicitly don¹t re-trigger or turn off/on DHCPv6 based on
>>some trigger.  All that we say is that in the case of M=O=1, the CE
>>router MUST do DHCPv6 by default.  That¹s all that needs to be said, and
>>that¹s all that can be said.
>>
>>- Wes 
>>
>>_______________________________________________
>>v6ops mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/v6ops
>
>_______________________________________________
>v6ops mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/v6ops