Subject: Re: [apps-discuss] Last Call: <draft-ietf-6renum-static-problem-02.txt> (Problem Statement for Renumbering IPv6 Hosts with Static Addresses) to Informational RFC

From: SM <[email-masked]>
Date: Thu, 13 Dec 2012 14:22:45 -0800

At 07:25 28-11-2012, The IESG wrote:
>The IESG has received a request from the IPv6 Site Renumbering WG
>(6renum) to consider the following document:
>- 'Problem Statement for Renumbering IPv6 Hosts with Static Addresses'
>   <draft-ietf-6renum-static-problem-02.txt> as Informational RFC

These comments are after the Last Call.  As such I am ok if they are 
ignored.  There is a Cc to apps-discuss in case anyone is interested 
to comment about the application perspective.

I am aware that renumbering is difficult.  I have read about the 
claim that "addresses are stable over long periods of time" in RFC 
6250.  The Introduction Section of the draft mentions that:

   "Static addresses may be configured automatically, for example by
    stateful DHCPv6."

It's fine to assign IP addresses to printers through DHCPv6.  The 
printer is a one-function device and it usually isn't critical.  I 
wouldn't use DHCPv6 for servers to be on the safe side.  If I had to 
choose between walking to the server to be able to access it when 
things go wrong and pushing an IP configuration manually, I would 
choose the former as it would have a lower impact on service 
availability.  Note that the server may be running multiple services 
which could interact with each other.

In Section 2.3:

   "However, it is very widespread operational practice that servers have
    static IP addresses."

   "Such server addresses can be managed centrally even if they are
    static, by using DHCPv6 in stateful mode, and by generating both
    DHCPv6 data and DNS data from a common configuration database using a
    suitable configuration tool."

This draft argues for DHCPv6 as the solution to make renumbering 
easier.  The draft seems to focus more on the client perspective 
where DHCPv6 (or SLAAC) is a worthwhile alternative for address 
assignment.   There's more to a server than assigning an IP address 
to the host.  If I configure a "Listen" address for an application 
and there is a DNS failure, the application does not start.  The 
problem statement (Section 4) mentions among other things printers 
and desktops.  The server part relies on DHCPv6 and DNS for 
configuration management.  In my humble opinion, that's a recipe for 
service outage.

Regards,
-sm

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Dec 2012 08:02:13 +0000

> The server part relies on DHCPv6 and DNS for configuration management.  In my humble opinion, that's a recipe for service outage.

In my world, DHCP and DNS have been mission critical for twenty years.

Regards
   Brian Carpenter

On 13/12/2012 22:22, SM wrote:
> ignored.  There is a Cc to apps-discuss in case anyone is interested to
> comment about the application perspective.
> 
> I am aware that renumbering is difficult.  I have read about the claim
> that "addresses are stable over long periods of time" in RFC 6250.  The
> Introduction Section of the draft mentions that:
> 
> choose between walking to the server to be able to access it when things
> go wrong and pushing an IP configuration manually, I would choose the
> former as it would have a lower impact on service availability.  Note
> that the server may be running multiple services which could interact
> with each other.
> 
> In Section 2.3:
> 
> easier.  The draft seems to focus more on the client perspective where
> DHCPv6 (or SLAAC) is a worthwhile alternative for address assignment.  
> There's more to a server than assigning an IP address to the host.  If I
> configure a "Listen" address for an application and there is a DNS
> failure, the application does not start.  The problem statement (Section
> 4) mentions among other things printers and desktops.  The server part
> relies on DHCPv6 and DNS for configuration management.  In my humble
> opinion, that's a recipe for service outage.
> 
> Regards,
> -sm
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>