Re: Request for discussion: patch - remove "also request dhcpv6.server-id"

2014-07-18 Thread Bjørn Mork
Dan Williams  writes:

> The also_request() is saying "please server, send me your DUID!" so it
> shouldn't contravene the RFC here.  However, I don't think we care a lot
> about the server DUID in NM itself, so I think the patch should be fine.
> If dhclient needs the server DUID, dhclient will figure out how to get
> it.

The server DUID is mandatory in the replies from the server, so adding
it to the Option Request option is in best case redundant.

From RFC 3315:

 15.3. Advertise Message

   Clients MUST discard any received Advertise messages that meet any of
   the following conditions:

   -  the message does not include a Server Identifier option.
 ..

 17.2.2. Creation and Transmission of Advertise Messages
 ..
   The server includes its server identifier in a Server Identifier
   option and copies the Client Identifier from the Solicit message into
   the Advertise message.



Bjørn
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Request for discussion: patch - remove "also request dhcpv6.server-id"

2014-07-17 Thread Dan Williams
On Wed, 2014-07-16 at 22:38 +0200, Thomas Schäfer wrote:
> Hi,
> 
> As already observed in the thread "dhcpv6-problem"  some devices are confused 
> by option request dhcpv6.server-id.
> 
> I looked a little bit in to RFC 3736 and 3315. But I still don't know what is 
> correct. 
> Do you need the server-id, in case they are more than one servers in your LAN?
> 
> Is a empty server-id request a valid request? ( in case of a selection: does 
> empty mean all or nothing?)
> 
> Why doesn't windows send this request?
> 
> Because I don't see any disadvantages I propose to remove this request.
> 
> At the moment I know three devices which would work with this patch.
> ZTE 823D
> ZTEMF93E
> alcatel one touch W800Z (tct-mobile) alias Telekom Speedsick LTE IV
> 
> and I don't know any device which would stop working.
> 
> Regards,
> Thomas Schäfer

Thanks for tracking this down!  I've pushed this to git master, 0.9.10,
and 0.9.8.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Request for discussion: patch - remove "also request dhcpv6.server-id"

2014-07-17 Thread Dan Williams
On Wed, 2014-07-16 at 23:07 +0200, Thomas Schäfer wrote:
> Hi,
> 
> 
> http://www.ietf.org/rfc/rfc3315.txt
> 
> 15.12. Information-request Message
> 
>Clients MUST discard any received Information-request messages.
> 
>Servers MUST discard any received Information-request message that
>meets any of the following conditions:
> 
>-  The message includes a Server Identifier option and the DUID in
>   the option does not match the server's DUID.
>-  The message includes an IA option.
> 
> Is the behavior of the devices correct? 
> Are there other RFCs
> (e.g. RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227 ) 
> with different updated rules?
> 
> Or I am completely wrong? 
> (because of mixing Server Identifier and Option Request Server Identifier?)

The also_request() is saying "please server, send me your DUID!" so it
shouldn't contravene the RFC here.  However, I don't think we care a lot
about the server DUID in NM itself, so I think the patch should be fine.
If dhclient needs the server DUID, dhclient will figure out how to get
it.

Dan


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Request for discussion: patch - remove "also request dhcpv6.server-id"

2014-07-16 Thread Thomas Schäfer
Hi,


http://www.ietf.org/rfc/rfc3315.txt

15.12. Information-request Message

   Clients MUST discard any received Information-request messages.

   Servers MUST discard any received Information-request message that
   meets any of the following conditions:

   -  The message includes a Server Identifier option and the DUID in
  the option does not match the server's DUID.
   -  The message includes an IA option.

Is the behavior of the devices correct? 
Are there other RFCs
(e.g. RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227 ) 
with different updated rules?

Or I am completely wrong? 
(because of mixing Server Identifier and Option Request Server Identifier?)

Regards,
Thomas
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Request for discussion: patch - remove "also request dhcpv6.server-id"

2014-07-16 Thread Thomas Schäfer
Hi,

As already observed in the thread "dhcpv6-problem"  some devices are confused 
by option request dhcpv6.server-id.

I looked a little bit in to RFC 3736 and 3315. But I still don't know what is 
correct. 
Do you need the server-id, in case they are more than one servers in your LAN?

Is a empty server-id request a valid request? ( in case of a selection: does 
empty mean all or nothing?)

Why doesn't windows send this request?

Because I don't see any disadvantages I propose to remove this request.

At the moment I know three devices which would work with this patch.
ZTE 823D
ZTEMF93E
alcatel one touch W800Z (tct-mobile) alias Telekom Speedsick LTE IV

and I don't know any device which would stop working.

Regards,
Thomas Schäfer







diff -ur a/NetworkManager-0.9.10/src/dhcp-manager/nm-dhcp-dhclient-utils.c b/NetworkManager-0.9.10/src/dhcp-manager/nm-dhcp-dhclient-utils.c
--- a/NetworkManager-0.9.10/src/dhcp-manager/nm-dhcp-dhclient-utils.c	2014-07-04 02:32:13.0 +0200
+++ b/NetworkManager-0.9.10/src/dhcp-manager/nm-dhcp-dhclient-utils.c	2014-07-16 22:00:08.333854069 +0200
@@ -225,7 +225,6 @@
 		add_also_request (alsoreq, "dhcp6.name-servers");
 		add_also_request (alsoreq, "dhcp6.domain-search");
 		add_also_request (alsoreq, "dhcp6.client-id");
-		add_also_request (alsoreq, "dhcp6.server-id");
 	} else {
 		add_ip4_config (new_contents, dhcp_client_id, hostname);
 		add_also_request (alsoreq, "rfc3442-classless-static-routes");
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list