headers
VithalPrasad Gaitonde | 2 Nov 2011 14:23
Picon

Re: Character Encoding of DNS domain option (option 15) RFC 2132

Hi Marc, Ted,
 
Can you please respond to the below.
 
Thanks,
Prasad

On Mon, Oct 31, 2011 at 6:43 PM, VithalPrasad Gaitonde <gvithal <at> gmail.com> wrote:
Thanks Marc. Would the same apply to the Domain Name field in option 81 defined in RFC 4702 as well.
 
Prasad

On Fri, Oct 28, 2011 at 6:06 PM, Marc Blanchet <marc.blanchet <at> viagenie.ca> wrote:

Le 2011-10-28 à 04:22, VithalPrasad Gaitonde a écrit :

> Thanks for the responses, Marc, Ted.
>
> Does that imply then that in case internationalized domain names, punycode should be used ?

punycode encoding is used for internationalized domain names. the punycode encoded idn conforms to the restricted ascii. So from dhcp, dns, ... point of view, an idn is just a regular domain name. therefore, the dhcp option should have restricted ascii, whatever the domain name is a normal one or an idn.

Marc.


>
> Regards,
> Prasad
>
> On Fri, Oct 28, 2011 at 12:05 AM, Marc Blanchet <marc.blanchet <at> viagenie.ca> wrote:
> to me, you are just looking into big troubles if you use a character encoding for DNS names in DHCP that is different than the standardized character encoding for DNS names everywhere else. so I would stick to restricted ascii. no utf8. nothing else.
>
> Marc.
>
> Le 2011-10-27 à 13:01, VithalPrasad Gaitonde a écrit :
>
> > I am still a bit confused here...
> > To ensure interoperability with standards compliant DHCP clients, what is the character encoding that the server should use...and the converse.
> >
> > Or are we saying that interoperability is broken here as the standard is silent on the issue leaving implementations to take a possibly different approach and thereby be non-interoperable.
> >
> > Thanks,
> > Prasad
> >
> >
> > On Mon, Oct 24, 2011 at 1:19 AM, Marc Blanchet <marc.blanchet <at> viagenie.ca> wrote:
> > I read it, but maybe I misunderstood. Anyway, back to the original question, my point is that the character encoding of DNS domain option in dhcp must be restricted ascii (and that includes the support of idn).
> >
> > Marc.
> >
> > Le 2011-10-23 à 15:36, Ted Lemon a écrit :
> >
> > > On Oct 23, 2011, at 3:30 PM, Marc Blanchet wrote:
> > >> don't agree about UTF-8. idns are encoded on the wire as normal domain names, i.e. restricted ascii.
> > >
> > > Clearly you didn't read what I said in the first paragraph.   :)   As you say, for DNS you can't use UTF-8.
> > >
> >
> >
>
>



_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
Permalink | Reply | 0 comments |
headers
Ted Lemon | 2 Nov 2011 21:34

IETF 82 Agenda

I just uploaded the agenda, which is quite short.   I think I must have missed some submissions, but I can't find them.   If you think you're on the agenda, please check.

Thanks!


_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
Permalink | Reply | 2 comments |
headers
Tomasz Mrugalski | 3 Nov 2011 22:01
Picon

Re: IETF 82 Agenda

On 11-11-02 21:34, Ted Lemon wrote:
> I just uploaded the agenda, which is quite short.   I think I must have
> missed some submissions, but I can't find them.   If you think you're on
> the agenda, please check.
> 
> Thanks!
> 
> http://www.ietf.org/proceedings/82/agenda/dhc.html
Ted,
I can present following things. Please add them to the agenda, if you
believe they are worthy topics for discussion.

1. Post-WGLC status of Redundancy Considerations draft
Not sure if that presentation is required. Changes are rather editorial,
with one substantial clarification.
Draft: draft-ietf-dhc-dhcpv6-redundancy-consider-02
Time slot: 5 minutes

2. DHCPv6 suboptions clarification draft.
Draft: draft-mrugalski-dhc-dhcpv6-suboptions-02
There was strong support that this clarification draft is needed.
Unfortunately, there's no concensus on how proceed with this. This
presentation will be a summary of current opinions and a request for
guideance regarding next steps.
Time slot: 5 minutes

3. DHCPv6 route options draft.
Draft: draft-ietf-mif-dhcpv6-route-option-03
I'd like to summarize WGLC that is in progress in MIF and will conclude
before Taipei. In particular, I'd like to discuss author's proposal
regarding DHCP preference over RA. It was presented in DHC already, but
routing configuration is an important topic, so I'd like to present it
once more.
Time slot: 5 minutes

Cheers,
Tomek
Permalink | Reply | 1 comment |
headers
Ted Lemon | 3 Nov 2011 23:38

Re: IETF 82 Agenda

These all look like good items for review/discussion.   Present them in the way that makes the most sense to
you—I don't personally mind non-powerpoint agenda items.   :)
Permalink | Reply | 0 comments |
headers
Ted Lemon | 4 Nov 2011 05:26

Updated agenda...

I uploaded a new agenda earlier today that I think covers all the requested presentations.   Please let me know if you think you should be on it and aren't! 


_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
Permalink | Reply | 0 comments |
headers
VithalPrasad Gaitonde | 4 Nov 2011 09:29
Picon

Re: I-D Action: draft-ietf-dhc-dhcpv6-failover-requirements-00.txt

Hi Tomasz, Kim,
 
Below are my comments on the DHCPv6 failover. Some of the comments may be more pertinent to the design.
 

1.       Configuration synchronization had been left out of the purview of the DHCP6 failover requirements document on the same lines as the DHCPv4 failover document. While the desire to keep the document simple is understandable, configuration synchronization is a critical element of a functional failover so that an administrator can manage the failover subnet(s) as one logical unit instead of having to make identical changes on 2 different servers.

        It will be good to call this out as a requirement in the document.

 

2.       There is a scenario where the DHCP server may be configured to serve clients on one network adapter and communicate with partner server (server-2-server traffic) on a different network adapter. In this scenario, if the server loses connectivity on the network adapter used to communicate with the clients because of network adapter (hardware) failure, there is no intimation of the loss of service to the partner in the DHCPv4 failover protocol. Since the servers are able to communicate with each other, the partner remains ignorant of the loss of service to clients. This scenario needs to be addressed to ensure high availability in case of network adapter failure.

 

3.       In the partner down scenario, when both servers operate in partner down, there is a chance of duplicate addresses on the network. This leads to a potential conflict (unresponsive) state when they re-establish contact. The duplicate address issue can be postponed to a large extent by the servers giving new leases from your own pool before giving new leases from partner’s pool.

 

4.       In case of hot standby (Active-Passive) model, while majority of addresses are owned by the primary server, secondary server will need a portion of addresses to serve new clients while operating in communication-interrupted state as also in partner down state before it can take over the entire address pool (expiry of MCLT). The concept of a percentage of IP address pool reserved for the secondary for handing out new leases during failover needs to be captured in the information model of the protocol.

 

5.       Unlike many other IETF documents,  the DHCPv4 failover document did not clearly callout the information model in the document. IMHO, the DHCPv6 document should call out the information model which should be designed to cater to both the high availability as well as failover monitoring aspects.

 
Thanks,
Prasad

On Mon, Oct 24, 2011 at 10:20 PM, <internet-drafts <at> ietf.org> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

       Title           : DHCPv6 Failover Requirements
       Author(s)       : Tomasz Mrugalski
                         Kim Kinnear
       Filename        : draft-ietf-dhc-dhcpv6-failover-requirements-00.txt
       Pages           : 19
       Date            : 2011-10-18

  The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers
  to operate on a single network, however it does not define any way to
  decide which server responds to which client queries.  Some sites are
  interested in running multiple servers in such a way as to provide
  increased availability in case of server failure.  In order for this
  to work reliably, the cooperating primary and secondary servers must
  maintain a consistent database of the lease information.  [RFC3315]
  allows for but does not define any redundancy or failover mechanisms.
  This document outlines requirements for DHCPv6 failover, enumerates
  related problems, and discusses the proposed scope of work to be
  conducted.  This document does not define a DHCPv6 failover protocol.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-failover-requirements-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-failover-requirements-00.txt
_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
Permalink | Reply | 1 comment |
headers
Ralph Droms | 4 Nov 2011 12:33
Picon

Proposed change to MAX_SOL_RT

I've asked the chairs for a short slot in the Taipei WG meeting to discuss
draft-droms-dhc-dhcpv6-maxsolrt-update-00.  While the doc won't officially be published until I-D
publication quiet period ends, the important text of the draft is only 2 paragraphs, so I'm posting it now
to encourage discussion prior to the WG meeting.

Here is text of the doc:

Abstract

  This document updates RFC 3315 by defining a new default value for
  SOL_MAX_RT.

1.  Introduction

  Section 5.5 of the DHCP specification [RFC3315] defines the default
  value of MAX_SOL_RT to be 120 seconds.  In some circumstances, this
  default will lead to an unacceptably high volume of aggregated
  traffic at a DHCPv6 server.

2.  Update to RC 3315

  This document changes section 5.5 of RFC 3315 as follows:

  OLD:
     SOL_MAX_RT      120 secs  Max Solicit timeout value

  NEW:
     SOL_MAX_RT     3600 secs  Max Solicit timeout value

  With this change, a DHCPv6 client that does not receive a
  satisfactory response will send Solicit messages with the same
  initial frequency and exponential backoff as specified in RFC 3315.
  However, the long term behavior of these DHCPv6 clients will be to
  send a Solicit message every 3600 seconds rather than every 120
  seconds, significantly reducing the aggregated traffic at the DHCPv6
  server.

  The change to MAX_SOL_RT is in response to DHCPv6 message rates
  observed at a DHCPv6 server in a deployment in which many DHCPv6
  clients are sending Solicit messages but the DHCPv6 server has been
  configured not to respond to those Solicit messages.  RFC 3315 was
  written with the expectation that the 'M' and 'O' flags in NDP
  [RFC2461] would control the use of DHCPv6 by hosts.  However, the
  current definition of the 'M' and 'O' flags in RFC 4861 [RFC4861]
  does not explicitly preclude the use of DHCPv6 by a host.  Some
  devices will initiate DHCPv6 even if RAs are received with the 'M'
  and 'O' bits set to 0.  In some circumstances, it is desirable to
  enable the assignment of IPv6 addresses through DHCPv6 to some
  nodes on a link but not to others, which cannot be implemented
  through the 'M' and 'O' bits.

Two issues to consider:

1. Is 3600 seconds the right number?  How about 7200 seconds?

2. In a scenario in which the DHCPv6 service is unresponsive for SOL_MAX_RT and the DHCPv6 clients are all
now sending a Solicit every SOL_MAX_RT, the average wait time for those clients to complete the DHCPv6
message exchange after the DHCPv6 service comes back up will be MAX_SOL_RT/2.  Is that situation
acceptable or should we define some other trigger through which the DHCPv6 clients can be signaled
explicitly to restart the Solicit transmission algorithm in section 17.1.2 of RFC 3315.  My personal
opinion is that an additional trigger is unnecessary.

- Ralph
Permalink | Reply | 4 comments |
headers
Ted Lemon | 4 Nov 2011 13:47

Re: I-D Action: draft-ietf-dhc-dhcpv6-failover-requirements-00.txt

On Nov 4, 2011, at 1:29 AM, "VithalPrasad Gaitonde" <gvithal <at> gmail.com> wrote:
> Configuration synchronization had been left out of the purview of the DHCP6 failover requirements
document on the same lines as the DHCPv4 failover document. While the desire to keep the document simple is
understandable, configuration synchronization is a critical element of a functional failover so that
an administrator can manage the failover subnet(s) as one logical unit instead of having to make
identical changes on 2 different servers.

This is an open-ended problem, since different servers have very different config data models.  We
declared this out of scope for DHCPv4, and I think that was the right decision.   I think it still is the right
decision for DHCPv6.
Permalink | Reply | 0 comments |
headers
Ted Lemon | 8 Nov 2011 12:44

Re: DHC WGLC: draft-ietf-dhc-forcerenew-nonce-01

On Sep 23, 2011, at 10:29 AM, "Ted Lemon" <Ted.Lemon <at> nominum.com> wrote:

> This document has been ready for WGLC for some time and fell through the cracks.   Please give it one last read
and let us know if you find any issues.   The document basically ports the nonce functionality of DHCPv6
Reconfigure back to DHCPv4.
> 
> Otherwise, if you support the document, please indicate that you do on the mailing list.   If you think it's a
bad idea, please let us know as well.   We will do a consensus call on October 7, 2011.

This WGLC got zero responses.   Is it really the case that this document has no support from the working group,
even the authors?   FWIW, I think it's important work and should advance, but I can't make the call on my own.
Permalink | Reply | 4 comments |
headers
Ted Lemon | 8 Nov 2011 13:02

Re: dhc-dhcpv6-redundancy-consider-02 draft (post WGLC)

On Oct 17, 2011, at 11:11 AM, "Tomasz Mrugalski" <tomasz.mrugalski <at> gmail.com> wrote:
> This draft seem to successfully pass WGLC
> (http://www.ietf.org/mail-archive/web/dhcwg/current/msg11930.html).

Only one person actually expressed support for this document, so in fact it did not pass WGLC. however there
were a number of comments, so I presume there actually is support.  Cpuld those who want this to be published
please formally indicate that they do?

Thanks!
Permalink | Reply | 6 comments |

Gmane