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

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Nov 2011 18:32:06 -0600

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); [email-masked]; 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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Nov 2011 20:06:59 -0600

Mark,

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 IPv6

egress 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: [email-masked] [mailto:[email-masked]] On Behalf
Of Hemant Singh (shemant)
Sent: Wednesday, November 16, 2011 8:32 AM
To: [email-masked]
Subject: [v6ops] FW: latest copy of rfc6204bis included

Hemant

Lorenzo -

if M=0 

- Wes

---

From: rajabu kitindi <[email-masked]>
Date: Wed, 16 Nov 2011 05:11:43 +0300

I am going through CPE WAN requirement, reading W - 1, my opinion would be
router should not act as a host, stateless IP address allocation on router
my be problematic as it does not provide visibility to what IP address has
been allocated to which device interface. This brings complications during
network troubleshooting.

/Rajabu

On Wed, Nov 16, 2011 at 5:06 AM, Hemant Singh (shemant)
<[email-masked]>wrote:

> Mark,****
> ** **
> mistake.  Doesn’t fly – the delta between rfc6204 and rfc6204bis that is
> 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?*
>
> ** **
>
> 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 IPv6****
>
> egress is preferred for traffic outside the 6rd domain when 6rd****
>
> and native IPv6 interfaces are active.]****
>
> ** **
>
> 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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Hemant Singh (shemant)
> *Sent:* Wednesday, November 16, 2011 8:32 AM
> *To:* [email-masked]
> *Subject:* [v6ops] FW: latest copy of rfc6204bis included****
>
> ** **
>
> For anyone who thinks the IPv6 ND RA’s M or the O bits can signal
> 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); [email-masked]; 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
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

-- 
MOTD: When we stop to think, we often miss our opportunity

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 16 Nov 2011 02:17:06 +0000

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:[email-masked]
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================

On 11/16/11 10:06 AM, "Hemant Singh (shemant)" <[email-masked]> wrote:

>Re: latest copy of rfc6204bis includedMark,
> 
>mistake.  Doesn¹t fly  the delta between rfc6204 and rfc6204bis that is
>IPv6 CE router document do changing the DHC or the ND protocols?
>the O bits in the RA just can¹t be used to signal start/stop to a DHCv6
>at this IETF for this goal?
> 
>[A 6rd CE MUST assign a forwarding metric such that native IPv6egress is
>preferred for traffic outside the 6rd domain when 6rd
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Hemant Singh (shemant)
>For anyone who thinks the IPv6 ND RA¹s M or the O bits can signal
>router design team discussion.  It¹s is bad idea.
> 
>Hemant
> 
>The reason you do not see such text is that we don¹t want to introduce
>multi-homing case.  Even though it¹s ³out of scope² - we don¹t want to
>invalidate the whole document when it becomes ³in scope².
>
>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
>router MUST do DHCPv6 by default.  That¹s all that needs to be said, and
>that¹s all that can be said.
>
>- Wes 
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Nov 2011 20:17:12 -0600

From: rajabu kitindi [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 10:12 AM
To: Hemant Singh (shemant)
Cc: [email-masked]; Mark Townsley (townsley)
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included

>I am going through CPE WAN requirement, reading W - 1, my opinion would
be  router should not act as a host, stateless IP >address allocation on
router my be problematic as >it does not provide visibility to what IP
address has been allocated to >which device interface. This brings
complications during network troubleshooting. 

Go back to years ago in v6ops archive and see this issue has already
been put to bed.  The DSL BBF asked of this requirement on the CE WAN
and it does make sense.  Each BNG/DSLAM or a CMTS  (both are access
concentrators) will support a DAD proxy and thus the SP first-hop IPv6
router does know about any SLAAC address.  The WAN interface will issue
a DAD probe for the SLAAC address.  Further when an interface on a
router is acquiring an IPv6 address the interface is acting as a host.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Nov 2011 20:21:29 -0600

Mark,

From: Hemant Singh (shemant) 
Sent: Wednesday, November 16, 2011 10:07 AM
To: Hemant Singh (shemant); [email-masked]
Cc: Mark Townsley (townsley)
Subject: RE: [v6ops] FW: latest copy of rfc6204bis included

>We should stop harking at rfc6204 that the document made quite a few
mistake.     

Sorry, Ole told me you were talking about rfc6204bis when speaking of
mistakes. Hmm, we authors of the document were only doing what the v6ops
WG tells us.  From Quebec City the WG told us to add IP transition tech
and much before that one Int area AD pointed to Softwires that the
rfc6204bis has a Coexistence section to deal with IP transition tech and
native IP .  We'd be happy to work with you to flush out sunsetting tech
for 6rd and native IPv6.  

Hemant

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 16 Nov 2011 10:22:19 +0800

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Nov 2011 20:27:55 -0600

-----Original Message-----
From: Brzozowski, John [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 10:17 AM
To: Hemant Singh (shemant); [email-masked]
Cc: Mark Townsley (townsley)
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included

>we are/were actively discussing allow it to live on in BIS.

I totally don't have a problem admitting to a mistake but for this
specific case, it's a problem with protocols that a v6ops document such
as rfc6204 does not deal with.  We have already acknowledged the Comcast
dhcpv6 server storm problem but the problem can't be solved by adding
new text related to the M and the O bits to rfc6204bis-02.  I personally
like Ralph's idea for the MAX_SOL_RT.  

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Nov 2011 20:31:55 -0600

Victor,

-----Original Message-----
From: Victor Kuarsingh [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 10:22 AM
To: Brzozowski, John; Hemant Singh (shemant); [email-masked]
Cc: Mark Townsley (townsley)
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included

>Ignoring real world problems is a mistake.  

I, Ole, and Wes Beebee have already acknowledged the operational
problem. It's the solution were are looking into and some solutions just
do not make sense.  See this email I sent today included between squared
braces below.

[Lorenzo -

if M=0 

- Wes]

Regards back,

Hemant

---

From: "Frank Bulk" <[email-masked]>
Date: Tue, 15 Nov 2011 23:08:11 -0600

Hemant:

Bridging two ISPs?  That doesn't sound wise, and if that's a real concern
(users would do it!), we should spell out what the failure state looks like
in the home router, perhaps failing over to a working WAN connection.

This hysteresis issue can be addressed by requiring a unique WAN interface
(physical or virtual) per ISP so that DHCPv6 Solicit decisions are made
independently, on a per-interface basis.

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hemant Singh (shemant)
Sent: Tuesday, November 15, 2011 8:32 PM
To: Victor Kuarsingh; Brzozowski, John; [email-masked]
Cc: Mark Townsley (townsley)
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included

Victor,

-----Original Message-----
From: Victor Kuarsingh [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 10:22 AM
To: Brzozowski, John; Hemant Singh (shemant); [email-masked]
Cc: Mark Townsley (townsley)
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included

[Lorenzo -

if M=0 

- Wes]

Regards back,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Nov 2011 23:34:30 -0600

Frank,

-----Original Message-----
From: Frank Bulk [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 1:08 PM
To: Hemant Singh (shemant)
Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John;
[email-masked]

>Bridging two ISPs?  

Stuff happens.  One designs protocol that are immune to naive network
setup.  The DHCPv6 server storm problem will need to work on some
protocol(s) and that is why the use case is certainly valid.  

Hemant

---

From: "Frank Bulk" <[email-masked]>
Date: Tue, 15 Nov 2011 23:49:40 -0600

We shouldn't enable bad configurations.  If bridging two ISPs is "bad" we
shouldn't let that be a use case to hold back on what's a reality (i.e.
DHCPv6 storming) for millions of good configurations.

Yes, we need to able to have routers with one WAN that can handle RAs from
more than one device (e.g. some kind of change on service provider router
that causes the RA to come from a different address), but we can put in
language in rfc6204 that minimizes the effects of the use case you shared.

Frank

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: Tuesday, November 15, 2011 11:35 PM
To: Frank Bulk
Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John;
[email-masked]

Frank,

-----Original Message-----
From: Frank Bulk [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 1:08 PM
To: Hemant Singh (shemant)
Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John;
[email-masked]

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Nov 2011 23:54:42 -0600

-----Original Message-----
From: Frank Bulk [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 1:50 PM
To: Hemant Singh (shemant)
Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John;
[email-masked]

>language in rfc6204 that minimizes the effects of the use case you
shared.

The CE router has two WAN interfaces (future scope) and the same problem
still occurs.  A host behind the CE router receives every 1/2 sec an RA
with M bit set and in the next 1/2 sec receives and RA with the M bit
cleared. 

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 16 Nov 2011 00:04:58 -0600

Frank,

Also why would Ralph's new document in the DHC server not solve the
DHCPv6 server storm due to a single DHCv6 client? 

http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hemant Singh (shemant)
Sent: Wednesday, November 16, 2011 1:55 PM
To: Frank Bulk
Cc: Mark Townsley (townsley); [email-masked]
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included

-----Original Message-----
From: Frank Bulk [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 1:50 PM
To: Hemant Singh (shemant)
Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John;
[email-masked]

Hemant

---

From: Wuyts Carl <[email-masked]>
Date: Wed, 16 Nov 2011 10:01:04 +0100

+1, we've finally come to a stage to be able to roll-out a solid IPv6 residential CPE, so indeed some extra corrections to this RFC seems unavoidable.

Carl Wuyts
GCD System Architect Networking
CONNECT DIVISION
[email-masked]
tel.: +32 3 443 65 90

Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium
Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpen

Help preserve the color of our world - Think before you print.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor Kuarsingh
Sent: woensdag 16 november 2011 3:22
To: Brzozowski, John; Hemant Singh (shemant); [email-masked]
Cc: W. Mark Townsley
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included

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"
<[email-masked]> wrote:

>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.
>
>>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
>>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
>>[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
>>Cc: Wojciech Dec (wdec); [email-masked]; Erik Kline; 
>>John Jason Brzozowski
>>>> 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?
>>
>>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 
>>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
>>

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 Nov 2011 18:27:34 +0800

John,

> Ignoring real world experience and feedback is not part of this process

I'll be the first to accept that we make mistakes (those who know me know that to be a lie, but let's assume that I do for the purpose of this discussion). ;-)

from a standards perspective:
  I do NOT accept that there are any mistakes with regards to DHCP address assignment and prefix delegation behaviour in RFC6204.
  RFC6204 is an informational document and a "device profile" document.

  RFC6204 does _not_ specify document behaviour. it certainly does _not_ specify how DHCP should work.
  _iff_ the correct solution to this problem were that the protocol called DHCPv6 PD defined in RFC3633 should be triggered by existing or
  new bits in Router Advertisements, then that has to be done as new standard track documents in DHC / 6man.

  _iff_ the correct solution to this problem were that the meaning of the M/O bits must change, then that has to be done in 6man.

  when that is done, a respin of 6204 can obviously reference that work.

operationally, yes I accept and agree there are issues. short-term there are many operational workarounds. mid-term they can be fixed by the before-mentioned new DHCP option. assuming that every IPv6 implementation will support it.

can we stop this now? so that I can continue on the draft-troan-global-ban-on-ever-talking-about-m&o-bits-ever-again-00

cheers,
Ole

---

From: "Frank Bulk" <[email-masked]>
Date: Wed, 16 Nov 2011 08:13:49 -0600

It resolves the DHCP storm issue, just that it if an operator mis-configures
a host or pool in the DHCP configuration it may not be easy for them to get
the CPE to re-request an IP address again.  The use of RA is more immediate
(M&O=0 => stop SOLICITing) (M|O=1 => start SOLICITing).

Frank

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 12:05 AM
To: Hemant Singh (shemant); Frank Bulk
Cc: Mark Townsley (townsley); [email-masked]
Subject: RE: [v6ops] FW: latest copy of rfc6204bis included

Frank,

Thanks,

Hemant

-----Original Message-----
From: Frank Bulk [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 1:50 PM
To: Hemant Singh (shemant)
Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John;
[email-masked]

Hemant

---

From: Wuyts Carl <[email-masked]>
Date: Wed, 16 Nov 2011 15:21:29 +0100

Hm, but doesn't this boil down again to my Q from before: why linking DHCP to RA (you could maybe make this optional/configurable), and what if no RA on the link (e.g. in PTP scenario) ?

Carl Wuyts

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Frank Bulk
Sent: woensdag 16 november 2011 15:14
To: 'Hemant Singh (shemant)'
Cc: Mark Townsley (townsley); [email-masked]
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included

It resolves the DHCP storm issue, just that it if an operator mis-configures a host or pool in the DHCP configuration it may not be easy for them to get the CPE to re-request an IP address again.  The use of RA is more immediate
(M&O=0 => stop SOLICITing) (M|O=1 => start SOLICITing).

Frank

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Wednesday, November 16, 2011 12:05 AM
To: Hemant Singh (shemant); Frank Bulk
Cc: Mark Townsley (townsley); [email-masked]
Subject: RE: [v6ops] FW: latest copy of rfc6204bis included

Frank,

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Wednesday, November 16, 2011 1:55 PM
To: Frank Bulk
Cc: Mark Townsley (townsley); [email-masked]
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included

-----Original Message-----
From: Frank Bulk [mailto:[email-masked]]
Sent: Wednesday, November 16, 2011 1:50 PM
To: Hemant Singh (shemant)
Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John; [email-masked]
Subject: RE: [v6ops] FW: latest copy of rfc6204bis included

>language in rfc6204 that minimizes the effects of the use case you
shared.

The CE router has two WAN interfaces (future scope) and the same problem still occurs.  A host behind the CE router receives every 1/2 sec an RA with M bit set and in the next 1/2 sec receives and RA with the M bit cleared. 

Hemant

---

From: "Frank Bulk" <[email-masked]>
Date: Wed, 16 Nov 2011 08:29:24 -0600

We want to link DHCPv6 to RA because we want different behaviors to happen.
That's why the M and O bits are hints, and already used to suggest to the
client whether it's a managed link and whether there are optional bits to
pick up.  Using M and O bits to cause action is nothing new here.

If there's no RA in the link there's nothing in rfc6402bis that prevents the
CPE from initiating DHCPv6.

Frank

-----Original Message-----
From: Wuyts Carl [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 8:21 AM
To: [email-masked]; 'Hemant Singh (shemant)'
Cc: Mark Townsley (townsley); [email-masked]
Subject: RE: [v6ops] FW: latest copy of rfc6204bis included

Hm, but doesn't this boil down again to my Q from before: why linking DHCP
to RA (you could maybe make this optional/configurable), and what if no RA
on the link (e.g. in PTP scenario) ?

Carl Wuyts

Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium
Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650
Edegem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpen

-----Original Message-----
Frank Bulk

Frank

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Wednesday, November 16, 2011 12:05 AM
To: Hemant Singh (shemant); Frank Bulk
Cc: Mark Townsley (townsley); [email-masked]
Subject: RE: [v6ops] FW: latest copy of rfc6204bis included

Frank,

Thanks,

Hemant

-----Original Message-----
From: Frank Bulk [mailto:[email-masked]]
Sent: Wednesday, November 16, 2011 1:50 PM
To: Hemant Singh (shemant)
Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John;
[email-masked]

The CE router has two WAN interfaces (future scope) and the same problem
still occurs.  A host behind the CE router receives every 1/2 sec an RA with
M bit set and in the next 1/2 sec receives and RA with the M bit cleared. 

Hemant

---

From: Wuyts Carl <[email-masked]>
Date: Wed, 16 Nov 2011 15:30:45 +0100

Ok, as long as it it's an optional thing, it's perfectly fine.

Carl Wuyts

-----Original Message-----
From: Frank Bulk [mailto:[email-masked]] 
Sent: woensdag 16 november 2011 15:29
To: Wuyts Carl; 'Hemant Singh (shemant)'
Cc: Mark Townsley (townsley); [email-masked]
Subject: RE: [v6ops] FW: latest copy of rfc6204bis included

We want to link DHCPv6 to RA because we want different behaviors to happen.
That's why the M and O bits are hints, and already used to suggest to the client whether it's a managed link and whether there are optional bits to pick up.  Using M and O bits to cause action is nothing new here.

If there's no RA in the link there's nothing in rfc6402bis that prevents the CPE from initiating DHCPv6.

Frank

-----Original Message-----
From: Wuyts Carl [mailto:[email-masked]]
Sent: Wednesday, November 16, 2011 8:21 AM
To: [email-masked]; 'Hemant Singh (shemant)'
Cc: Mark Townsley (townsley); [email-masked]
Subject: RE: [v6ops] FW: latest copy of rfc6204bis included

Carl Wuyts

Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Frank Bulk
Sent: woensdag 16 november 2011 15:14
To: 'Hemant Singh (shemant)'
Cc: Mark Townsley (townsley); [email-masked]
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included

Frank

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Wednesday, November 16, 2011 12:05 AM
To: Hemant Singh (shemant); Frank Bulk
Cc: Mark Townsley (townsley); [email-masked]
Subject: RE: [v6ops] FW: latest copy of rfc6204bis included

Frank,

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Wednesday, November 16, 2011 1:55 PM
To: Frank Bulk
Cc: Mark Townsley (townsley); [email-masked]
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included

-----Original Message-----
From: Frank Bulk [mailto:[email-masked]]
Sent: Wednesday, November 16, 2011 1:50 PM
To: Hemant Singh (shemant)
Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John; [email-masked]
Subject: RE: [v6ops] FW: latest copy of rfc6204bis included

Hemant

---

From: "Frank Bulk" <[email-masked]>
Date: Wed, 16 Nov 2011 12:15:15 -0600

Hemant:

I don't want to spend too much time talking about future scope items but I
still think it's wise to give some passing thought to possible future
use/break cases.

A CE router with two WAN interfaces does not necessarily replicate on the
LAN interface(s) the M/O bits that were received on the WAN interface(s).
In fact, in all the SOHO routers I've looked at, the LAN behavior is
independently configured.  Because I'm not aware of any RFC requirements
that say that M/O bits need to be replicated from the WAN to LAN, I don't
think that any of the hosts behind the CE will DHCPv6 thrash.

Diagram:

ISP #1	ISP #2
M=O=0		M|0=1
  |		  |
   \         /
    \       /
     |     |
   WAN 1  WAN 2
     =======
     | CPE |  
     =======
       LAN
        |
      M=O=1
        |
Host with stateful CPE support

As facilitated by the current version of rfc6204bis, WAN 1 is not required
to issue DHCPv6 solicits.  This is the out that the cable folk are needing.
But WAN 1 could issue DHCPv6 solicats, and the BBF folk require that.
rfc6204bis requires DHCPv6 to start on WAN2. What the LAN does with its RA
is independent of WAN1 and WAN2, and which prefixes are or are not
advertised -- well, we can discuss that on homenet at a future time.

Frank

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: Tuesday, November 15, 2011 11:55 PM
To: Frank Bulk
Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John;
[email-masked]

-----Original Message-----
From: Frank Bulk [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 1:50 PM
To: Hemant Singh (shemant)
Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John;
[email-masked]

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 16 Nov 2011 18:06:47 -0600

The DSL Broadband forum has already decoupled DHCPv6 from IPv6 ND RA in their standards.  I have nothing further to say on using the M and the O bits to start/stop DHCPv6 beyond what I have said already - bad idea.

Hemant

-----Original Message-----
From: Wuyts Carl [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 9:21 AM
To: [email-masked]; Hemant Singh (shemant)
Cc: Mark Townsley (townsley); [email-masked]
Subject: RE: [v6ops] FW: latest copy of rfc6204bis included

Carl Wuyts

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Frank Bulk
Sent: woensdag 16 november 2011 15:14
To: 'Hemant Singh (shemant)'
Cc: Mark Townsley (townsley); [email-masked]
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included

Frank

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Wednesday, November 16, 2011 12:05 AM
To: Hemant Singh (shemant); Frank Bulk
Cc: Mark Townsley (townsley); [email-masked]
Subject: RE: [v6ops] FW: latest copy of rfc6204bis included

Frank,

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Wednesday, November 16, 2011 1:55 PM
To: Frank Bulk
Cc: Mark Townsley (townsley); [email-masked]
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included

-----Original Message-----
From: Frank Bulk [mailto:[email-masked]]
Sent: Wednesday, November 16, 2011 1:50 PM
To: Hemant Singh (shemant)
Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John; [email-masked]
Subject: RE: [v6ops] FW: latest copy of rfc6204bis included

Hemant

---

From: Thomas Narten <[email-masked]>
Date: Mon, 21 Nov 2011 10:55:48 -0500

> storm for the service provider.

If broadband operators are stupid enough to configure the sending of
RAs every second as described above, they get what they deserve.

Let's please not come up with bogus scenarios to justify putting
things in documents.

(If there are other reasonable rationales, please use them.)

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 21 Nov 2011 12:27:15 -0600

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Monday, November 21, 2011 10:56 AM
To: Hemant Singh (shemant)
Cc: Victor Kuarsingh; Brzozowski, John; [email-masked]; Mark Townsley (townsley)
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included

>Let's please not come up with bogus scenarios to justify putting

Totally agreed. We did not add any such scenario in the Enhanced DAD draft or any other IETF document.   However, whether the scenario was bogus is a separate discussion - see

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

>(If there are other reasonable rationales, please use them.)

Agreed as well.  Not related to the M/O bits, but the reflected DAD probe problem.  One cable broadband problem outlined in the Intro section of the Enhanced DAD draft was a naïve user in the home who connected two broadband modems in his/her home to a network hub and caused the SP concentrator network interface's DAD probe to be reflected back.  This is a real problem.  Also one has to design protocols around dumb network configuration.  The use of the hub in any network causes, for one, a DHCPv6 client not detecting link up/down state but RFC 3315 outlines DHCPv6 procedures for link up/down state.  Likewise there was a naïve proposal to use link up/down state to converge OSPFv3 for prefix delegation in a home router LAN but the hub blocks reporting any link up/down state. 

Hemant

---

From: Wes Beebee <[email-masked]>
Date: Mon, 21 Nov 2011 14:40:43 -0500

> Totally agreed. We did not add any such scenario in the Enhanced DAD draft or
> any other IETF document.   However, whether the scenario was bogus is a
> separate discussion - see
> 

Multiple interfaces (MIF working group) and multi-homing, especially as it
applies to home networks, are areas of increasing focus within IETF.  They
are not "bogus scenarios".  Let's not continue the mistake of previous core
IPv6 specifications in not considering the impact of these scenarios on our
work.  Even if they're not explicitly "in-scope", we shouldn't do anything
which deliberately breaks them.

- Wes

---

From: Thomas Narten <[email-masked]>
Date: Mon, 21 Nov 2011 14:44:45 -0500

> are not "bogus scenarios".

Please go back and read what I quoted and said. The term "bogus
scenarios" does not refer to the scenario of multi-homing in
general. It refers specifically to the case of competing/conflicting
RAs being sent every second. That, IMO, is a bogus scenario.

Thomas