Bernie Volz (volz | 2 Jan 03:08 2008
Picon

RE: draft-ietf-dhc-agent-vpn-id-06.txt posted

So, does that mean per the Vancouver minutes
(http://www3.ietf.org/proceedings/07dec/minutes/dhc.txt) that Evan Hunt,
David Hankins, and myself should start the process to "write a review"
of this document?

Is the other one
(http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-07.txt)
ready also or is a revision coming?

- Bernie 

-----Original Message-----
From: Kim Kinnear Jr. (kkinnear) 
Sent: Tuesday, December 18, 2007 1:53 PM
To: dhcwg <at> ietf.org
Cc: Kim Kinnear Jr. (kkinnear)
Subject: [dhcwg] draft-ietf-dhc-agent-vpn-id-06.txt posted

Folks,

I've posted a new copy of draft-ietf-dhc-agent-vpn-id-06.txt
which has been updated with the following two changes:

1.  Fixed the problem pointed out by David Hankins in Vancouver
that the relay-agent-information option RFC [RFC 3046] requires
echoing of the entire relay-agent-information option, so that
there is limited information you can elicit from getting this
sub-option back in an echoed relay-agent-information option.

2.  Fixed typo: RFC 3040 -> RFC 4030.
(Continue reading)

Richard Johnson | 2 Jan 03:38 2008
Picon

Re: draft-ietf-dhc-agent-vpn-id-06.txt posted

I don't know of any further changes that are needed for the "VPN  
Option" draft.  I think it's in, or so to be in, Last Call.  I  
believe we ended up with some volunteers to review it along with  
reviewing the "VPN Relay Sub-option" draft.

/raj

On Jan 1, 2008, at 6:08 PM, Bernie Volz (volz) wrote:

> So, does that mean per the Vancouver minutes
> (http://www3.ietf.org/proceedings/07dec/minutes/dhc.txt) that Evan  
> Hunt,
> David Hankins, and myself should start the process to "write a review"
> of this document?
>
> Is the other one
> (http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-07.txt)
> ready also or is a revision coming?
>
> - Bernie
>
> -----Original Message-----
> From: Kim Kinnear Jr. (kkinnear)
> Sent: Tuesday, December 18, 2007 1:53 PM
> To: dhcwg <at> ietf.org
> Cc: Kim Kinnear Jr. (kkinnear)
> Subject: [dhcwg] draft-ietf-dhc-agent-vpn-id-06.txt posted
>
>
> Folks,
(Continue reading)

Ralph Droms (rdroms | 2 Jan 14:57 2008
Picon

RE: Draft minutes from wg meeting at IETF 70

Minutes from IETF 70 are due by Jan 4.  If there are no comments about the draft minutes at http://www3.ietf.org/proceedings/07dec/minutes/dhc.txt, those draft minutes will become the officially submitted minutes.

- Ralph


-----Original Message-----
From: Stig Venaas [mailto:stig.venaas <at> uninett.no]
Sent: Sun 12/23/2007 8:19 AM
To: DHC WG
Cc: Ralph Droms (rdroms)
Subject: Draft minutes from wg meeting at IETF 70

The draft minutes from IETF 70 have been uploaded at
http://www3.ietf.org/proceedings/07dec/minutes/dhc.txt

Please let Ralph and me know if you have any corrections,
additions etc.

The minutes are also attached for your convenience,

Stig


_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
Kim Kinnear | 2 Jan 17:05 2008
Picon

Re: draft-ietf-dhc-agent-vpn-id-06.txt posted


Bernie, et. al.,

Yes, to the best of my knowledge both drafts are now ready to
review, so the volunteers:

        Bernie Volz
        Evan Hunt
        David Hankins

could start now with the two drafts:

http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-vpn-id-06.txt

http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-07.txt

The draft IETF minutes say that the job of these volunteers is
to:
        "... commit to write a review of the revised version of
        these documents so we can go through WGLC."

I'd like to offer my thanks to these folks for doing this work so
we can go through Working Group Last Call yet again with these
documents.  I'd like to point out that these drafts have already
gone through last call (at least) once.  The current drafts are
the results of revisions made due to comments from the last call
from last August.

Cheers -- Kim

At 09:38 PM 1/1/2008, Richard Johnson wrote:
>I don't know of any further changes that are needed for the "VPN  
>Option" draft.  I think it's in, or so to be in, Last Call.  I  
>believe we ended up with some volunteers to review it along with  
>reviewing the "VPN Relay Sub-option" draft.
>
>/raj
>
>
>On Jan 1, 2008, at 6:08 PM, Bernie Volz (volz) wrote:
>
>>So, does that mean per the Vancouver minutes
>>(http://www3.ietf.org/proceedings/07dec/minutes/dhc.txt) that Evan  
>>Hunt,
>>David Hankins, and myself should start the process to "write a review"
>>of this document?
>>
>>Is the other one
>>(http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-07.txt)
>>ready also or is a revision coming?
>>
>>- Bernie
>>
>>-----Original Message-----
>>From: Kim Kinnear Jr. (kkinnear)
>>Sent: Tuesday, December 18, 2007 1:53 PM
>>To: dhcwg <at> ietf.org
>>Cc: Kim Kinnear Jr. (kkinnear)
>>Subject: [dhcwg] draft-ietf-dhc-agent-vpn-id-06.txt posted
>>
>>
>>Folks,
>>
>>I've posted a new copy of draft-ietf-dhc-agent-vpn-id-06.txt
>>which has been updated with the following two changes:
>>
>>1.  Fixed the problem pointed out by David Hankins in Vancouver
>>that the relay-agent-information option RFC [RFC 3046] requires
>>echoing of the entire relay-agent-information option, so that
>>there is limited information you can elicit from getting this
>>sub-option back in an echoed relay-agent-information option.
>>
>>2.  Fixed typo: RFC 3040 -> RFC 4030.
>>
>>Cheers -- Kim
>>
>>_______________________________________________
>>dhcwg mailing list
>>dhcwg <at> ietf.org
>>https://www1.ietf.org/mailman/listinfo/dhcwg
>>
>>_______________________________________________
>>dhcwg mailing list
>>dhcwg <at> ietf.org
>>https://www1.ietf.org/mailman/listinfo/dhcwg
차현욱 | 3 Jan 01:51 2008

Operational problem caused by inconsistent RA M and O flags

Dear, all.

Though I already posted this issue, I want to re-issue this because I do not think that any clear explanation
were given.
As you know, current IPv6 stack and DHCPv6 clients have been implemented in processing RA M/O flags as
instructed by previous specification RFC2462.   
That is, both ManagedFlag and OtherConfigFlag are copied from the M and O flag fields of the most recently
received Router Advertisement message respectively. 
And a host invokes the DHCPv6 client to request both address and other information when received Router
Advertisement message change an internal state variable(ManagedFlag) from FALSE to TRUE and the DHCPv6
client is not running. 
   
I think that these requirements are based on the assumption that RA M/O flags from different routers on a
link are consistent. 
However, if routers on a link do not belong to the same administrative domain, the assumption may be
incorrect and result in DHCP6 clients' misbehaviors.

Please think about following scenario.   


                                    ------------------ 
                                    | ISP2                  |
   -----------------        | Access_Router2 |      
   | ISP1                |       ------------------              
   | Acess_Router1 |                   |              
   -----------------            CPE_Router
     |RA(P1, M=1)                        |RA(P2, M=0)
   ------------------------------------ link0
          |        |       |       |
         pc1    pc2    pc3   pc4
  
Let us assume that specific hosts pc1 and pc2 are supposed to be assigned global IPv6 addresses by ISP1.   
Originally, Access_Router1 advertises prefix P1 with M flag set to 1 and CPE_Router prefix P2 with M flag
set to 0 On the link (link0).
However, the CPE_Router shoud be fixed to send RA message with M flag set to 1 to avoid host-side confusion
caused by frequent changes of ManagedFlag variable.
For example, the DHCPv6 client in Windows Vista will continue request and release of a global IPv6 address
repeatedly according to M flag value of received RA messages.  
In addition, if users do not want DHCPv6 service from ISP1 more, CPE_Router shoud be fixed to send RA message
with M flag set to 0 because DHCPv6 server is not available. 
Thus, the requirement that RA M, O flags should be consistent on a link cause manual RA reconfiguration cost.

IMO, It is desirable that IPv6 protocol stacks and DHCPv6 clients should operate normally as users expect
without RA reconfigurations. 
Please let me know if you have already considered this issue or know related information or any other opinions.

Thank you in advance.


Joseph HyunWook Cha

The truth will set you free !!!

Software Engineer 
Development Part 1. I/Infra  
Network System Division 
Tel 031-279-3804  Mobile 010-3024-3804
_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
John Jason Brzozowski | 3 Jan 07:02 2008
Picon

Re: Operational problem caused by inconsistent RA M and O flags

Hello Joseph,

I was wondering if you could help clarify your scenario.  If I read your
scenario correctly PC1 and PC2 see router advertisements from
access_router_1 and the cpe_router simultaneously?  Also, is the cpe_router
terminated against access_router_1 or access_router_2 or both?  What about
router advertisements from access_router_2, are there any?

Also, it is not clear why would the cpe_router should always send rotuer
advertisements with the M bit set to 1.  Can you clarify?  Aren't PC1 and
PC2 connected to cpe_router?

Thanks,

John

On 1/2/08 7:51 PM, "차현욱" <hyunwook.cha <at> samsung.com> wrote:

> Dear, all.
> 
> Though I already posted this issue, I want to re-issue this because I do not
> think that any clear explanation were given.
> As you know, current IPv6 stack and DHCPv6 clients have been implemented in
> processing RA M/O flags as instructed by previous specification RFC2462.
> That is, both ManagedFlag and OtherConfigFlag are copied from the M and O flag
> fields of the most recently received Router Advertisement message
> respectively. 
> And a host invokes the DHCPv6 client to request both address and other
> information when received Router Advertisement message change an internal
> state variable(ManagedFlag) from FALSE to TRUE and the DHCPv6 client is not
> running. 
>    
> I think that these requirements are based on the assumption that RA M/O flags
> from different routers on a link are consistent.
> However, if routers on a link do not belong to the same administrative domain,
> the assumption may be incorrect and result in DHCP6 clients' misbehaviors.
> 
> Please think about following scenario.
> 
> 
>                                     ------------------
>                                     | ISP2                  |
>    -----------------        | Access_Router2 |
>    | ISP1                |       ------------------
>    | Acess_Router1 |                   |
>    -----------------            CPE_Router
>      |RA(P1, M=1)                        |RA(P2, M=0)
>    ------------------------------------ link0
>           |        |       |       |
>          pc1    pc2    pc3   pc4
>   
> Let us assume that specific hosts pc1 and pc2 are supposed to be assigned
> global IPv6 addresses by ISP1.
> Originally, Access_Router1 advertises prefix P1 with M flag set to 1 and
> CPE_Router prefix P2 with M flag set to 0 On the link (link0).
> However, the CPE_Router shoud be fixed to send RA message with M flag set to 1
> to avoid host-side confusion caused by frequent changes of ManagedFlag
> variable.
> For example, the DHCPv6 client in Windows Vista will continue request and
> release of a global IPv6 address repeatedly according to M flag value of
> received RA messages.
> In addition, if users do not want DHCPv6 service from ISP1 more, CPE_Router
> shoud be fixed to send RA message with M flag set to 0 because DHCPv6 server
> is not available.
> Thus, the requirement that RA M, O flags should be consistent on a link cause
> manual RA reconfiguration cost.
> 
> IMO, It is desirable that IPv6 protocol stacks and DHCPv6 clients should
> operate normally as users expect without RA reconfigurations.
> Please let me know if you have already considered this issue or know related
> information or any other opinions.
> 
> Thank you in advance.
> 
> 
> Joseph HyunWook Cha
> 
> The truth will set you free !!!
> 
> Software Engineer
> Development Part 1. I/Infra
> Network System Division
> Tel 031-279-3804  Mobile 010-3024-3804
> _______________________________________________
> dhcwg mailing list
> dhcwg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg

=========================================
John Jason Brzozowski (CISSP, RHCT)
Comcast Corporation
e) mailto:john_brzozowski <at> cable.comcast.com
m) 609-377-6594
p) 856-324-2671
=========================================
차현욱 | 3 Jan 08:43 2008

Re: Re: Operational problem caused by inconsistent RA M and O flags

Hello, John.

Thank you for many questions. 
Let me clarify the example customer site.
This site is multi-homed via ISP1 and ISP2. For ISP1, one modem is connected to link0 and all PCs can receive
RAs from access_router1 directly. For ISP2, CPE_Router receives a prefix delegated by access_router2
and advertise derived prefix P2 from the prefix to the link0. So, all PCs can receive RAs from
access_router1 and cpe_router simultaneously. 

The reason why the cpe_router should always send rotuer advertisements with the M bit set to 1 is the
consistency of RA flags. As I posted before, hosts including Windows Vista almost can not use leased IPv6
addresses from ISP1 through DHCPv6, because hosts will continue requesting and releasing stateful
addresses iteratively according to RA M/O flag values.  

If you have another questions or comments, please let me know.

Regards,

------- Original Message -------
Sender : John Jason Brzozowski<john_brzozowski <at> cable.comcast.com> 
Date   : 2008-01-03 15:02 (GMT+09:00)
Title  : Re: [dhcwg] Operational problem caused by inconsistent RA M and O flags

Hello Joseph,

I was wondering if you could help clarify your scenario.  If I read your
scenario correctly PC1 and PC2 see router advertisements from
access_router_1 and the cpe_router simultaneously?  Also, is the cpe_router
terminated against access_router_1 or access_router_2 or both?  What about
router advertisements from access_router_2, are there any?

Also, it is not clear why would the cpe_router should always send rotuer
advertisements with the M bit set to 1.  Can you clarify?  Aren't PC1 and
PC2 connected to cpe_router?

Thanks,

John


On 1/2/08 7:51 PM, "차현욱" <hyunwook.cha <at> samsung.com> wrote:

> Dear, all.
> 
> Though I already posted this issue, I want to re-issue this because I do not
> think that any clear explanation were given.
> As you know, current IPv6 stack and DHCPv6 clients have been implemented in
> processing RA M/O flags as instructed by previous specification RFC2462.
> That is, both ManagedFlag and OtherConfigFlag are copied from the M and O flag
> fields of the most recently received Router Advertisement message
> respectively. 
> And a host invokes the DHCPv6 client to request both address and other
> information when received Router Advertisement message change an internal
> state variable(ManagedFlag) from FALSE to TRUE and the DHCPv6 client is not
> running. 
>    
> I think that these requirements are based on the assumption that RA M/O flags
> from different routers on a link are consistent.
> However, if routers on a link do not belong to the same administrative domain,
> the assumption may be incorrect and result in DHCP6 clients' misbehaviors.
> 
> Please think about following scenario.
> 
> 
>                                     ------------------
>                                     | ISP2                  |
>    -----------------        | Access_Router2 |
>    | ISP1                |       ------------------
>    | Acess_Router1 |                   |
>    -----------------            CPE_Router
>      |RA(P1, M=1)                        |RA(P2, M=0)
>    ------------------------------------ link0
>           |        |       |       |
>          pc1    pc2    pc3   pc4
>   
> Let us assume that specific hosts pc1 and pc2 are supposed to be assigned
> global IPv6 addresses by ISP1.
> Originally, Access_Router1 advertises prefix P1 with M flag set to 1 and
> CPE_Router prefix P2 with M flag set to 0 On the link (link0).
> However, the CPE_Router shoud be fixed to send RA message with M flag set to 1
> to avoid host-side confusion caused by frequent changes of ManagedFlag
> variable.
> For example, the DHCPv6 client in Windows Vista will continue request and
> release of a global IPv6 address repeatedly according to M flag value of
> received RA messages.
> In addition, if users do not want DHCPv6 service from ISP1 more, CPE_Router
> shoud be fixed to send RA message with M flag set to 0 because DHCPv6 server
> is not available.
> Thus, the requirement that RA M, O flags should be consistent on a link cause
> manual RA reconfiguration cost.
> 
> IMO, It is desirable that IPv6 protocol stacks and DHCPv6 clients should
> operate normally as users expect without RA reconfigurations.
> Please let me know if you have already considered this issue or know related
> information or any other opinions.
> 
> Thank you in advance.
> 
> 
> Joseph HyunWook Cha
> 
> The truth will set you free !!!
> 
> Software Engineer
> Development Part 1. I/Infra
> Network System Division
> Tel 031-279-3804  Mobile 010-3024-3804
> _______________________________________________
> dhcwg mailing list
> dhcwg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg


=========================================
John Jason Brzozowski (CISSP, RHCT)
Comcast Corporation
e) mailto:john_brzozowski <at> cable.comcast.com
m) 609-377-6594
p) 856-324-2671
=========================================


_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
David W. Hankins | 3 Jan 17:22 2008

Re: Operational problem caused by inconsistent RA M and O flags

On Thu, Jan 03, 2008 at 12:51:53AM +0000, 차현욱 wrote:
>                                     ------------------ 
>                                     | ISP2                  |
>    -----------------        | Access_Router2 |      
>    | ISP1                |       ------------------              
>    | Acess_Router1 |                   |              
>    -----------------            CPE_Router
>      |RA(P1, M=1)                        |RA(P2, M=0)
>    ------------------------------------ link0
>           |        |       |       |
>          pc1    pc2    pc3   pc4

that's a problem.  i would characterize the root cause as being a
design factor of RS/RA...the client does not maintain a per-router
state machine, only global and per-prefix states.

one solution is to introduce per-router state...so that when AR2
advertises an "M bit" of zero, AR1's advertisement is not overridden.
this means on every RA reception, the client would have to traverse
a list of router states and only switch edge detections if all routers
agree.

another solution is to copy the M and O state down into the state
regarding the PIOs advertised within that RA.  this means the client
would have to traverse a list of all prefixes on that link, and
again only detect edges if any or no prefixes advertised 1's.

and a third solution is to simply always run DHCPv6 and ignore M/O
bits entirely.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
--

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
Thomas Narten | 3 Jan 17:47 2008
Picon

Re: Operational problem caused by inconsistent RA M and O flags

Well, it is clear that it is preferable that all routers advertise
consistent values for the M&O bits.  But, wishing that were so,
doesn't prevent it from happening in some scenarios.

That said, I'm not sure I agree with your analysis:

> Let us assume that specific hosts pc1 and pc2 are supposed to be
> assigned global IPv6 addresses by ISP1.  Originally, Access_Router1
> advertises prefix P1 with M flag set to 1 and CPE_Router prefix P2
> with M flag set to 0 On the link (link0).  However, the CPE_Router
> shoud be fixed to send RA message with M flag set to 1 to avoid
> host-side confusion caused by frequent changes of ManagedFlag
> variable.

> For example, the DHCPv6 client in Windows Vista will continue request and
> release of a global IPv6 address repeatedly according to M flag value of
> received RA messages.

IMO, this is incorrect.  If one looks at RFC 2462, it says:

     5.5.3.  Router Advertisement Processing

     On receipt of a valid Router Advertisement (as defined in
     [DISCOVERY]), a host copies the value of the advertisement's M
     bit into ManagedFlag. If the value of ManagedFlag changes from
     FALSE to TRUE, and the host is not already running the stateful
     address autoconfiguration protocol, the host should invoke the
     stateful address autoconfiguration protocol, requesting both
     address information and other information.  If the value of the
     ManagedFlag changes from TRUE to FALSE, the host should continue
     running the stateful address autoconfiguration, i.e., the change
     in the value of the ManagedFlag has no effect.  If the value of
     the flag stays unchanged, no special action takes place. In
     particular, a host MUST NOT reinvoke stateful address
     configuration if it is already participating in the stateful
     protocol as a result of an earlier advertisement.

Note especially that if the value of ManagedFlag changes from TRUE to
FALSE and back again, DHCP is not supposed to be stopped and
restarted.

Given that RFC4862 has no words about the ManagedFlag, I'd say the
2462 guidance surely makes the most sense to follow.

Thomas
Hemant Singh (shemant | 3 Jan 20:24 2008
Picon

RE: Operational problem caused by inconsistent RA M and Oflags

I agree with Thomas' analysis. Section 5.5.3 in RFC 2462 makes sense and
the guidance this section gives to this issue is also adequate. 

Vista IPv6 stack needs looking into.

Hemant 

-----Original Message-----
From: Thomas Narten [mailto:narten <at> us.ibm.com] 
Sent: Thursday, January 03, 2008 11:48 AM
To: hyunwook.cha <at> samsung.com
Cc: ???; ???; ???; ???; dhc WG
Subject: Re: [dhcwg] Operational problem caused by inconsistent RA M and
Oflags

Well, it is clear that it is preferable that all routers advertise
consistent values for the M&O bits.  But, wishing that were so, doesn't
prevent it from happening in some scenarios.

That said, I'm not sure I agree with your analysis:

> Let us assume that specific hosts pc1 and pc2 are supposed to be 
> assigned global IPv6 addresses by ISP1.  Originally, Access_Router1 
> advertises prefix P1 with M flag set to 1 and CPE_Router prefix P2 
> with M flag set to 0 On the link (link0).  However, the CPE_Router 
> shoud be fixed to send RA message with M flag set to 1 to avoid 
> host-side confusion caused by frequent changes of ManagedFlag 
> variable.

> For example, the DHCPv6 client in Windows Vista will continue request 
> and release of a global IPv6 address repeatedly according to M flag 
> value of received RA messages.

IMO, this is incorrect.  If one looks at RFC 2462, it says:

     5.5.3.  Router Advertisement Processing

     On receipt of a valid Router Advertisement (as defined in
     [DISCOVERY]), a host copies the value of the advertisement's M
     bit into ManagedFlag. If the value of ManagedFlag changes from
     FALSE to TRUE, and the host is not already running the stateful
     address autoconfiguration protocol, the host should invoke the
     stateful address autoconfiguration protocol, requesting both
     address information and other information.  If the value of the
     ManagedFlag changes from TRUE to FALSE, the host should continue
     running the stateful address autoconfiguration, i.e., the change
     in the value of the ManagedFlag has no effect.  If the value of
     the flag stays unchanged, no special action takes place. In
     particular, a host MUST NOT reinvoke stateful address
     configuration if it is already participating in the stateful
     protocol as a result of an earlier advertisement.

Note especially that if the value of ManagedFlag changes from TRUE to
FALSE and back again, DHCP is not supposed to be stopped and restarted.

Given that RFC4862 has no words about the ManagedFlag, I'd say the
2462 guidance surely makes the most sense to follow.

Thomas

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

Gmane