headers
Ralph Droms | 1 Dec 2006 15:03
Picon
Favicon

Implementation of DHCPv6 authentication

Hideshi Enokihara and the IPv6 Ready Logo team are considering the
requirements for DHCPv6 authentication in the DHCPv6 IPv6 Ready logo
program.  He's trying to determine the availability of DHCPv6
authentication, both the Delayed Authentication Protocol (RFC 3315, sec.
21.4) and the Reconfigure Key Authentication Protocol (RFC 3315, sec. 21.5).
If you have knowledge of the availability of these protocols in existing or
planned DHCPv6 implementations, please respond directly to
<Hideshi.Enokihara <at> jp.yokogawa.com>.  All responses will be used only for
analysis of DHCPv6 IPv6 Ready requirements and individual responses will be
kept confidential.

Thanks...

- Ralph
Permalink | Reply | 4 comments |
headers
Markus Stenberg | 4 Dec 2006 08:28
Picon
Favicon

Re: draft-stenberg-pd-route-maintenance

"David W. Hankins" <David_Hankins <at> isc.org> writes:
> As threatened in the WG meeting, some comments to work on section
> 2.1 of this document, offered in a playful spirit even if my
> writing style doesn't convey that.

Thanks for the comments! I have been fairly busy with random stuff that
actually has deadlines, so I have been shifting through my backlog
gradually. This one I've postponed because I wanted to evaluate your
comments thoroughly :)

Disclaimer: I'm apparently from different background, as I have some idea
about how some big ISPs work, but very, very little idea about what happens
in the cable-land. Therefore, you may have read to my draft something that
wasn't there in the first place.

> In general, I'd like to see this document try and imagine the "best"
> deployment of the described architecture, and then point out flaws
> in it, rather than to imagine all the worst ideas and point out
> just how bad it could get if you really tried.
>
> I get the idea also that while writing this section, the author
> switched between the idea of, say, perl scripts writing DR
> configuration syntax down an SSH channel, and a routing protocol
> approach.  I think in that case you should separate this into two
> different sections (as the first few bulletpoints apply to the
> former but not the latter).

Well, I'm not sure if those two are substantially different. Currently,
there isn't a way of doing it - either within a routing protocol, or
arbitrary configuration-pushing protocol whether it is some super-ugly r/w
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sanjay Tripathi | 4 Dec 2006 12:36

Problem With VLAN

Hi,

    I have one query regarding DHCP and DNS?

I have two DHCP Server (P1 and P2) and 2 DNS Server (D1,D2) in same VLAN.

Both DHCP(P1,P2) and DNS( D1,D2) is ruuning.

DHCP P1 and DNS D1 is configured for 2 thin client to get IP, There we didn’t providing any Dynamic ip or any POLL.

Only for both Thin client is getting Static IP by that DHCP P1 thru MAC address.

 

So here My question is that IS IT POSSIBLE ANY ANOTHER SYSTEM/DESKTOP RATHER THEN THIN CLIENT WILL GET DNS SREVR NAME BY

DHCP 1?  EVEN WE HAVEN’T CONFIGURED ANY DYNAMIC IP POLL ON THAT DHCP SERVER P1?

 

Thanks

STripathi

 

 

 

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
Permalink | Reply | 0 comments |
headers
Alexandru Petrescu | 4 Dec 2006 16:32

Re: Teredo for reducing search space (was: Review of draft-ietf-v6ops-scanning-implications)

Teredo and 6to4 are listed in "Transition Methods".

I would list knowledge of Teredo right in the section "Reducing the IPv6
Search Space".  An IPv6 worm knowing an IPv4 hitlist address could try
the full /128 IPv6 as a hitlist address too.

/64 Teredo Node Identifier not only uses the IPv4 address to derive the
IPv6 address but also a UDP port number (not mentioned in the draft, it
just says "2002:V4ADDR::V4ADDR").  Teredo also offers to discover all
Teredo Clients within a subnet, via a publicly-known reserved IPv4
multicast address.  A worm would take advantage of that too, to reduce
number of scans.

Alex

Fred Baker wrote:
> The v6ops working group is approaching a working group last call on 
> draft-ietf-v6ops-scanning-implications within the coming few weeks.
> We would appreciate a review from your working group of this document
>  before we do so. How that is done is up to you; you may designate
> one or more reviewers, or simply conduct the review on your mailing
> list, or whatever else suits you. But please respond to the authors
> copying v6ops within the coming four weeks if you would.
> 
> Thank you for your help in this.
> 
> _______________________________________________ dhcwg mailing list 
> dhcwg <at> ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
>
Permalink | Reply | 0 comments |
headers
Hideshi.Enokihara | 5 Dec 2006 09:18

RE: Implementation of DHCPv6 authentication

Hi all,

Now, I'm working for making conformance test specification for DHCPv6
Logo in IPv6 Ready Logo Program (www.ipv6ready.org).

Logo committee has decided to cover Reconfiugre function(message) as
DHCPv6 Logo requirements.
So, we'd like to know the availavility of DHCPv6 authentication
protocols both the Delayed Authentication Protocol and the Reconfigure
Key Authentication Protocol.
Do you have some plan to support the Delayed Authentication Protocol
and/or the Reconfigure Key Authentication Protocol for
sending/receiveing Reconfigure message?
Do you know some implementations that support DHCPv6 authenticaiton
protocols for Reconfigure message?

These informations obtained form you will be used to make the DHCPv6
Logo specification,
which Auhtentication protocol should be covered, both should be covered
or one of thme should be coverd?

I'm waiting for your full cooperation.

#Thank you very much for your help > Ralph

Best regards,

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms <at> cisco.com] 
> Sent: Friday, December 01, 2006 11:03 PM
> To: dhcwg
> Cc: Enokihara, Hideshi (Hideshi.Enokihara <at> jp.yokogawa.com)
> Subject: Implementation of DHCPv6 authentication
> 
> Hideshi Enokihara and the IPv6 Ready Logo team are considering the
> requirements for DHCPv6 authentication in the DHCPv6 IPv6 Ready logo
> program.  He's trying to determine the availability of DHCPv6
> authentication, both the Delayed Authentication Protocol (RFC 
> 3315, sec.
> 21.4) and the Reconfigure Key Authentication Protocol (RFC 
> 3315, sec. 21.5).
> If you have knowledge of the availability of these protocols 
> in existing or
> planned DHCPv6 implementations, please respond directly to
> <Hideshi.Enokihara <at> jp.yokogawa.com>.  All responses will be 
> used only for
> analysis of DHCPv6 IPv6 Ready requirements and individual 
> responses will be
> kept confidential.
> 
> Thanks...
> 
> - Ralph
>
Permalink | Reply | 3 comments |
headers
Shane Kerr | 5 Dec 2006 11:46

Re: RE: Implementation of DHCPv6 authentication


Hideshi Enokihara,

Hideshi.Enokihara <at> jp.yokogawa.com wrote:
> Hi all,
> 
> Now, I'm working for making conformance test specification for DHCPv6
> Logo in IPv6 Ready Logo Program (www.ipv6ready.org).
> 
> Logo committee has decided to cover Reconfiugre function(message) as
> DHCPv6 Logo requirements.
> So, we'd like to know the availavility of DHCPv6 authentication
> protocols both the Delayed Authentication Protocol and the Reconfigure
> Key Authentication Protocol.
> Do you have some plan to support the Delayed Authentication Protocol
> and/or the Reconfigure Key Authentication Protocol for
> sending/receiveing Reconfigure message?
> Do you know some implementations that support DHCPv6 authenticaiton
> protocols for Reconfigure message?
> 
> These informations obtained form you will be used to make the DHCPv6
> Logo specification,
> which Auhtentication protocol should be covered, both should be covered
> or one of thme should be coverd?

I think there are not many useful cases for DHCPv6 (and DHCP) authentication.

A typical case might be to use client authentication for a few important hosts
in a network. Here there are a few benefits, like preventing other clients from
seeing the configuration or being able to use the DHCP server to update DNS.

But, I do not think a shared-secret authentication mechanism has much general
applicability for DHCP. Authenticating the server in an environment where every
client has the server key seems futile... or is the idea to give a different
server key for each client? In any case, having to configure a client is kind of
contrary to the goals of DHCP.

FWIW, we are planning on supporting DHCP (and DHCPv6) authentication on ISC
DHCP, but it has not been a high priority.

--
Shane
Permalink | Reply | 2 comments |
headers
Christian Vogt | 5 Dec 2006 18:29
Picon
Favicon

Desynchronization in DHCPv6

DHCP folks,

I might be missing something, but I am wondering how DHCPv6 realizes
desynchronization between the Advertise messages of multiple servers:

When a DHCPv6 client initiates a 4-way handshake, it sends a Solicit
message and waits for responding Advertise messages for a period of 1.0
to 1.1 s.

At first glance, it seems that the purpose of this delay is to allow
multiple on-link DHCPv6 servers to randomly delay their Advertise
messages a bit in an effort to avoid collisions with the Advertise
messages of neighboring servers.

OTOH, according to RFC 3315, a DHCPv6 server sends its Advertise message
promptly upon receiving a Solicit message.  Hence my questions:

(1)  Why does a client have to wait for between 1.0 and 1.1 s after
sending the Solicit message?

(2)  And if not through randomly delaying Advertise messages, how does
DHCPv6 guarantee desynchronization between the Advertise messages of
multiple servers?

Thanks a lot in advance!

- Christian

--

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/
Permalink | Reply | 6 comments |
headers
Andre Kostur | 5 Dec 2006 19:06
Favicon

RE: Desynchronization in DHCPv6

> -----Original Message-----
> From: Christian Vogt [mailto:chvogt <at> tm.uka.de] 
> Sent: Tuesday, December 05, 2006 9:30 AM
> To: dhcwg <at> ietf.org
> Subject: [dhcwg] Desynchronization in DHCPv6
> 
> DHCP folks,
> 
> I might be missing something, but I am wondering how DHCPv6 
> realizes desynchronization between the Advertise messages of 
> multiple servers:
> 
> When a DHCPv6 client initiates a 4-way handshake, it sends a 
> Solicit message and waits for responding Advertise messages 
> for a period of 1.0 to 1.1 s.
> 
> At first glance, it seems that the purpose of this delay is 
> to allow multiple on-link DHCPv6 servers to randomly delay 
> their Advertise messages a bit in an effort to avoid 
> collisions with the Advertise messages of neighboring servers.

Uh, I thought the delay was to allow the client to potentially receive
Advertises from multiple servers, possibly of different Preference
values, or potentially some other criteria that the client wishes to use
to select between different servers.
Permalink | Reply | 5 comments |
headers
Christian Vogt | 5 Dec 2006 19:36
Picon
Favicon

Re: Desynchronization in DHCPv6

Hello Andre,

clients certainly need to collect Advertise messages from multiple 
servers, and this requires them to wait for a little while after 
sending the Solicit message.  But given that servers transmit their 
Advertise messages immediately upon receiving the Solicit message, why 
does the wait period have to as long as 1 s?

Kind regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

Andre Kostur wrote:
>> DHCP folks,
>>
>> I might be missing something, but I am wondering how DHCPv6 
>> realizes desynchronization between the Advertise messages of 
>> multiple servers:
>>
>> When a DHCPv6 client initiates a 4-way handshake, it sends a 
>> Solicit message and waits for responding Advertise messages 
>> for a period of 1.0 to 1.1 s.
>>
>> At first glance, it seems that the purpose of this delay is 
>> to allow multiple on-link DHCPv6 servers to randomly delay 
>> their Advertise messages a bit in an effort to avoid 
>> collisions with the Advertise messages of neighboring servers.
> 
> Uh, I thought the delay was to allow the client to potentially receive
> Advertises from multiple servers, possibly of different Preference
> values, or potentially some other criteria that the client wishes to use
> to select between different servers.
Permalink | Reply | 4 comments |
headers
Andre Kostur | 5 Dec 2006 19:45
Favicon

RE: Desynchronization in DHCPv6


> -----Original Message-----
> From: Christian Vogt [mailto:chvogt <at> tm.uka.de] 
> Sent: Tuesday, December 05, 2006 10:37 AM
> To: Andre Kostur
> Cc: dhcwg <at> ietf.org
> Subject: Re: [dhcwg] Desynchronization in DHCPv6
> 
> Hello Andre,
> 
> clients certainly need to collect Advertise messages from 
> multiple servers, and this requires them to wait for a little 
> while after sending the Solicit message.  But given that 
> servers transmit their Advertise messages immediately upon 
> receiving the Solicit message, why does the wait period have 
> to as long as 1 s?

To allow for propogation times from the clients to the servers, which
may cross one or more Relays, which may also be on slow links.  (Think
sattelite links: There's 1/2 second or more return trip time....)
Permalink | Reply | 3 comments |

Gmane