Subject: [renum] review of draft-jiang-6renum-enterprise

From: "Lee Howard" <[email-masked]>
Date: Thu, 29 Dec 2011 13:26:47 -0500

At IETF82, I said I would undertake a review of the documents under
discussion.  Laboriously detailed notes follow.  I have not yet reviewed the
other documents, and can't promise that I will be able to do so soon.

Lee
--

http://tools.ietf.org/html/draft-jiang-6renum-enterprise-02  comments

1.	Introduction
< currently prefer to Provider Independent 
> currently prefer to use Provider Independent

In addition, PI space may not be available to all enterprises, based on the
policy of their Regional Internet Registry (RIR).
"It takes the analysis conclusions from [RFC5887]"
What conclusions are those?  I don't see an analysis or conclusions section.
Please enumerate them.

2.	Enterprise Network Illustration for Renumbering
>	Static address assignment is not considered in this version. 

Why is it not considered?
It isn't clear whether you mean "this version of the diagram," or "this
version of the document," or "this version of possible renumbering
strategies."  That needs to be clear.
>	The
>	   complicated IPv4/IPv6 co-existence scenarios are out of scope.
>	
>	   This document focuses on the unicast addresses; site-local, link-
>	   local, multicast and anycast addresses are out of scope.

I agree with leaving these out of scope, but it would be nice to explain why
they're out of scope.  And I would move this to the Introduction.
This diagram assumes an enterprise has a single hub, which may be
multihomed.  Is it rare for an enterprise network to have multiple offices,
each with local connectivity?  Maybe those sites should have two GUA
prefixes: one for locally-destined Internet, and one for VPN/private
network/Internet access through remote connection.

3.1 Renumbering caused by External Network Factors
> The typical scenario is that the DHCPv6
>       server in the ISP delegates a new prefix to the enterprise network.

Is that typical?  Do ISPs typically allocate prefixes to their enterprise
customers through DHCPv6?  Or is it often done manually?  I would definitely
think that any BGP multihomed enterprise is not using DHCPv6 to learn its
prefix.  One could debate whether multihomed enterprises are likely to use
PA space, but the goal of the document was to make PA space more usable.
Also, enterprised may dual-home to the same ISP.

>	If the administrators
>	      only want part of the network to have multiple prefixes, the
>	      renumbering process should be carefully managed.

I don't understand the implications of this sentence.  Can you describe a
scenario where an administrator would want that?  How would the
administrator "carefully manage" that?  And does that mean that other cases
do not need to be "carefully managed?"

Neither 3.1 or 3.2 describes the case of being assigned a new,
non-contiguous block of addresses.  What if an ISP or enterprise has to
renumber into a larger block (e.g., give back a /32 in order to get a /28,
or give back a /48 to get a /44).

4.1 Considerations and Best Current Practices during Network Design The
prefix delegation paragraph needs more detail.  It says both "carefully
managed" and "delegated from router to router."  As a new reader, these seem
to be in opposition.  
Guidance on good address planning would be helpful here.  
Note that prefix delegation works in a hub-and-spoke (or centralized, or
hierarchical) network, but not as well in a distributed network.  

>	DHCPv6 PD options may also be used between the
>	      enterprise routers and their upstream ISPs.

Provide examples, and show how they would be useful.

>	Fully-Qualified Domain Names (FQDNs) are recommended
>	      to be used to configure network connectivity

I agree.  I'm not sure rfc5996 is the best example, if only one is going to
be used.  Use of FQDN for services should imply use (or at least
consideration) of DNSSEC; you should note that here or in Security
Considerations.  I'd like to see more examples of places where FQDN is
better than IP address.  Identification of database servers, or
applications, come to mind.

> Service Location Protocol [RFC2608] and multicast DNS with SRV
>      records for service discovery can reduce the number of places that
>      IP addresses need to be configured.

This may be an excellent recommendation, but it is fairly novel, and
requires more examples.  mDNS is link-local only, isn't it?  That limitation
should be noted; it's severely limiting in the enterprise network, which
you've already noted is defined as having "multiple internal links."  

> Manual-configured addresses are not scalable in medium to large
>      sites, hence are out of scope. 

True; this should be in the Introduction.

> However, some hosts such as servers may need static addresses.
Manual-configured addresses/hosts should be avoided as much as possible.

I don't know that there's consensus on this point.  I also don't know
whether discussion of it is appropriate here, or should be in a different
document.  Why do servers need static addresses?  It's not so they're
named-you can do that with dDNS.  You already pointed out that you can do
service discovery with mDNS, SRV, and SLP (maybe within certain
limitations).  The reasons for static addresses are 1. Monitoring (which
could often be done by FQDN), 2. Firewall rules.
(yes, dynamic DNS is dependent on having a DNS server that supports dDNS,
either your own, or your generous ISP).

Advice on how to avoid manual configuration as much as possible would be
welcome.

ULAs will need to be renumbered for any Internal Network Factor (section
3.2).  They are useful only for single-site networks (where all traffic is
"local" and/or where a /48 is enough address space).  

> DHCPv6 can also support host-generated address model

This statement is premature, since it is still in draft.  Is there running
code?

> manual on-demand
>      updating model is considered as a harmful source of problems

This statement is too strong.  Say, "manual on-demand model does not scale,
and increases the chance of errors."

> Normally, the dynamic DNS update
You say, "Normally," but then propose a different mechanism as BCP.
Instead, say, "Dynamic DNS updates can be provided by the DHCPv6 client or
by the DHCPv6 server."  Then go on to explain how to do each, and make a
recommendation if you have one.

> In a model including SLAAC
This paragraph describes how to do dDNS.  It's enough to say this isn't
available with SLAAC.  This is a significant consideration in the Address
Configuration Models section.

> exposure to hijacking 
What kind of threat is this?  Man-in-the-middle?  Spoofing?  Escalation of
privilege?  I don't understand the threat clearly from this description.

> seems there's no real deployment
> so far according to the discussion in the IETF meeting. 
Is it that there's no support among router vendors or OS vendors, or just
that administrators aren't turning it on (if the latter, we should recommend
it)?  Need to be a little more authoritative here, and remember that "the
IETF meeting" is vague for a document with a multi-year lifespan.

> RA guard [RFC6105] is a light-weight alternative, however, it also hasn't
been widely deployed

Does RA guard accomplish the same thing as SEND?  Is it not deployed by
router vendors or OS vendors, just that administrators aren't turning it on
(if the latter, we should recommend it)?  

> For DHCPv6, there are built-in secure mechanisms (like Secure
>      DHCPv6 [I-D.ietf-dhc-secure-dhcpv6]), and authentication of DHCPv6
>      messages [RFC3315]could be utilized. But they are also mechanisms
>      that haven't been verified by wide real deployment.

You recommend DHCPv6 above (for its support of Secure DNS Dynamic Update),
but say it doesn't have available security.  Is authentication (rfc3315)
enough?  Here again, a clearer description of threats would allow a clearer
evaluation of security mechanisms.

>   A site or network should also avoid embedding addresses from other
>      sites or networks in its own configuration data.

Amen!

< connectivities 
> connections

4.2 Considerations and Best Current Practices for the Preparation of
Renumbering

> prefix's lifetime 

You're talking about ND, and should explicitly say so.  

> these recommendations are not cost free

I understand and agree, but I think your point is, "Since these
recommendations would increase traffic and server load, they should only be
used in preparation for a renumbering event."

>    - Reduce the address preferred time or valid time or both.

Add considerations for which I should reduce, or when both, and what values
I should use.  For instance, the valid_time should be less than the shortest
possible reconfiguration window.  Again, a little extra detail for the
network administrator would be handy.

> Reduce the DNS configuration lifetime on the hosts.
Good idea, but in RAs it's the "Lifetime value of the RDNSS Option."  In
DHCPv6, I think the lifetime would be the DHCPv6 lease time.  What value
should it be set to?  Two hours?

What about reducing the TTL on any DNS records?

4.Considerations and Best Current Practices during Renumbering  Operation

< service/connectivity will be out for a period till 
> service/connectivity will be unavailable for a period until

The discussion of whether to have a flag day would be better placed in the
preparation phase, since it relates to the lifetime settings.

> Address deprecation 
Is this term defined somewhere?  

> The DNS records should be deprecated as
>      early as possible, before the addresses themselves.

Needs more detail, i.e., DNS TTL should be less than valid_lifetime or
DHCPv6 lease time.  How do you reduce DNS TTL on dynamic DNS?  For DNS
records that are not dynamically updated, the sequence should be:
1.	Reduce TTL to (e.g.) 3600
2.	After adding new addresses, create new DNS records.
3.	Wait for an amount of time equal to the previous TTL.
4.	 Remove old DNS records.  By this time, anyone who had the old
records with the old TTL has expired, looked up the new records, and has the
new TTL (and hopefully, the new address).
5.	Wait 3600.  This lets the old records expire, after which they
shouldn't be cached anywhere.
6.	End use of old addresses.  To end use before this risks that someone
has the old record cached somewhere.  It is entirely possible that hosts on
the Internet will cache for longer than your TTL, but if you give advice
(TTL 3600) and someone ignores it and breaks protocol, you can't fix it.

> enforcement messages, either in Router Advertisement messages 

I'm unfamiliar with RA enforcement messages, please cite.

>      - DNS record update and DNS configuration on hosts
Should this be combined with the "Transition period" paragraph above it?

> A notification mechanism may be needed to indicate to the hosts that
> a renumbering event of local recursive DNS happens or is going to
> take place.

>From the context, are "the hosts" the ones doing DNS lookups, or are they
the devices being renumbered?  Why is a mechanism needed?  What kind of
mechanism?  Is this a gap?

> all border routers should
> be aware of partial renumbering in order to correctly handle
> inbound packets. Internal forwarding tables need to be updated.

How should they be made aware?  In what way should forwarding tables be
updated?  Avoid the passive voice.

> The egress router connecting to ISP A should be notified 

How should it be notified?  

>      - Tunnel concentrator renumbering
Even if the tunnel concentrator was specified by FQDN in the client
configuration, there may be other configuration elements referring to the IP
address.  Any existing sessions will have to be dropped and re-established
to the new address (certainly for IPSec, a new security association is
required, and the AH uses the IP address; even for other kinds of tunnels, I
don't know of any that could stay up when an endpoint is renumbered).  

> relevant hosts or routers
I'd say "client hosts and routers," to clarify that you don't mean "routers
providing paths to the concentrator."

Security Considerations
Mostly notes as above.
> Dynamic DNS update may bring risk of DoS attack to the DNS server.
Increased risk of DoS attack, or increased risk of DoS when many hosts are
simultaneously renumbered?  
> along with the update authentication, session filtering/limitation
>   may also be needed.
Block dDNS messages from outside the network.  And make sure your server can
handle the load if every host sends an update in a 2-hour period.  This may
also happen after a blackout or other network outage.

> co-existence of old and new
>   prefixes may cause potential risk to the enterprise routing system.
What risk?  Routing tables that are too large for memory?  Too many updates
for the CPU to handle?  Be specific.

> enterprise scenarios may not involve the extreme situation;
>   this issue needs to be identified in the future.
More detail, since I'm not clear on what "this issue" is.  

Not discussed:
Firewall rules
Ingress/egress filters/ACLs
Updating IGP, BGP
Monitoring systems
The many cases where configuration parameters require an IP address, not a
name.  The "preparation phase" here is "complain to the vendor."

I like the overall organization: during network design, for preparation of
renumbering, and during renumbering operation, gaps.  Within the sections, I
would have preferred considerations for workstations (SLAAC vs DHCPv6,
dDNS), peripherals (ditto plus service discovery), and servers (including
DNS, firewalls (and other security systems like IPS and tests), NMS/OSS).
I don't know if there are different considerations for Internet-facing
servers than for internal-only servers (such as accounting and payroll
systems).  The framework is the right one, and the considerations are what I
would hope for.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 01 Jan 2012 08:12:00 +1300

Lee,

Thnaks for that very detailed review. We will definitely deal with each point
for the next release.

> The framework is the right one, and the considerations are what I
> would hope for.

Could you comment on the WG adoption call that Wes sent?

Regards
   Brian Carpenter