[v6ops] comments about draft-ietf-v6ops-enterprise-incremental-ipv6-01

[Tassos Chatzithomaoglou <[e-mail]>]

Generally i like the phased approach of this draft.
We have done similar phases in our own corporate network, although not all sub-phases apply to us.

Here are my general comments...

3.6 should be moved in the beginning. Project (not program) planning should be the first thing to do.

Security parts got me a little bit confused. There are things are are repeated many times, although applicable at all of them.
Maybe put them under a general security section and just add differences per phase.
Also it would be better if the security section was in the same position at every phase (i.e. last or first).

I didn't see any reference (or better warning) on operational costs vs needs. Introduction includes 1-2 sentences, but i don't find them always applicable.
This may be an easy job for some networks, but in same cases it will take time and effort...without having a good reason.
I understand that this might push back the willing of an enterprise to move to IPv6, but every case should be examined under a general umbrella.
An administrator might be considering IPv6 on his own, but this doesn't necessarily apply to the whole enterprise.

I got the impressions throughout the text that translation is preferred vs tunneling, something i agree with in most cases, and especially in isp environments.
But there are many enterprises, where the tunneling approach might be a better/easier/cheaper solution.

Lastly, until IPv6 is fully implemented into the enterprise, a recommendation should be made about the expansion/maintenance of IPv4 network/systems in such a way that the IPv6 deployment is taken into account.


And some specific comments....

 The most common drivers are due
   to the fact that when Internet service providers, including mobile
   wireless carriers, run out of IPv4 addresses, they will provide
   native IPv6 and non-native IPv4. 

I don't think most enterprises will fall under this type (non-native IPv4) of connectivity.
ISPs are mostly facing issues with residential services in terms of address availability.

 The non-native IPv4 service may be
   NAT64, NAT444, Dual-stack Lite, or other transition technology, but
   whether tunneled or translated, the native traffic will be perform
   better and more reliably than non-native. 

This assumption poses questions whether all those translation/tunneling solutions by IETF are worth considering.
Maybe add a probability factor there.

  A specific case of congruence is the IPv6 ULA [http://tools.ietf.org/html/rfc4193" title='"Unique Local IPv6 Unicast Addresses"' rel="nofollow">RFC4193] and IPv4
   private addressing [http://tools.ietf.org/html/rfc1918" title='"Address Allocation for Private Internets"' rel="nofollow">RFC1918] that do not provide any security by
   'magic'.  In both case, the edge router must apply strict data plane
   and routing policy to block those private addresses to leave and
   enter the network.  This filtering can be done by the enterprise or
   by the ISP.

IPv6 addresses can be spoofed as easily as IPv4 addresses and there
   are packets with bogons IPv6 addresses (see [http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-01#ref-CYMRU" title='"THE BOGON REFERENCE"' rel="nofollow">CYMRU]).  The anti-bogon
   filtering must be done in the data and routing planes.  It can be
   done by the enterprise or by the ISP.

case = > cases
edge router => border routers

Might want to rephrase "data" as "forwarding" or "routing" as "control" in order to use common wording.

Some recommendations are expressed like "can be done by the enterprise or by the ISP". I think it should be noted that the enterprise should always try to do these, regardless of the ISP. Ok, it might not be always easy for the enterprise to do these (due to expertise, costs, etc), but i don't think the enterprise should solely depend on the ISP doing these.

An alternative is to try to prevent the use
   of privacy extension addresses is to send the Router Advertisement
   with the M-bit set (to force the use of DHCPv6 to get an address) and
   with all advertized prefixes without the A-bit set (to prevent the
   use of stateless auto-configuration); this technique requires that
   all hosts support stateful DHCPv6.

I think it's better to remove the M-bit reference and just refer DHCPv6.
If i remember right, there was a talk about the M/O bits being controversial lately

Another DoS
   vulnerabilities are related to NDP cache exhaustion
   ([http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-01#ref-I-D.gashinsky-v6ops-v6nd-problems" rel="nofollow">I-D.gashinsky-v6ops-v6nd-problems]) and they can be mitigated by
   careful tuning of the NDP cache.  In 2012, there are already several
   vendors offering those features on their switches.

RFC 6583 proposes various options for mitigation of NDP issues; i think a general reference should be made instead.

The enterprise administrator will want to evaluate whether the
   enterprise will request address space from its ISP (or Local Internet
   Registry (LIR)), or whether to request address space from the local
   Internet Registry (whether a Regional Internet Registry such as
   AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC, or a National Internet
   Registry, operated in some countries). 

Probably it should be rewritten as

The enterprise administrator will want to evaluate whether the
   enterprise will request address space from a LIR (Local Internet
   Registry, such as an ISP), a RIR (Regional Internet Registry, such as
   AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC) or a NIR (National Internet Registry, operated in some countries).

Each location, no matter how small, should get at least a /48.

Does this apply to every enterprise?
Maybe add a reference to RFC6177 & RFC 5375?

   All user access networks MUST be a /64.  Point-to-point links without
   MAC addresses (this is where Neighbor Discovery Protocol does not
   run) SHOULD be a /127 (see also [http://tools.ietf.org/html/rfc6164" title='"Using 127-Bit IPv6 Prefixes on Inter- Router Links"' rel="nofollow">RFC6164]).

Why a reference on mac-addresses? Can't ethernet p2p links use /127?

Also, for any part of the network where
   DNS (or reverse DNS) zones may be delegated, it is important to
   delegate addresses on nibble boundaries (this is on a multiple of 4
   bits), to ensure propose name delegation.

propose => proposed?
Maybe want to explain this a little bit more?

   ** Add some comment about setting MTU to 1280 to avoid tunnel pMTUd
   black holes? **

Personally, i don't like the idea of setting the MTU to the minimum. It's better to describe the issues and the importance of ICMP/pMTUd and leave the MTU minimization as a last resort.

 The security policies must be congruent for IPv4
   and IPv6 (else the attacker will use the less protected protocol
   stack) except that ICMPv6 messages must be allowed through and to the
   filtering device (see [http://tools.ietf.org/html/rfc4890" title='"Recommendations for Filtering ICMPv6 Messages in Firewalls"' rel="nofollow">RFC4890]):

except that ICMPv6 messages => except that some ICMPv6 messages

The peering router must also implement anti-spoofing technique based
   on [http://tools.ietf.org/html/rfc2827" title='"Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing"' rel="nofollow">RFC2827].

What's a peering router in the enterprise? There is only a single reference of it. Are you referring to border routers?

This includes the use of IP flow export
   [http://tools.ietf.org/html/rfc5102" title='"Information Model for IP Flow Information Export"' rel="nofollow">RFC5102] to detect abnormal traffic pattern (such as port scanning,
   SYN-flooding) 

IP flow export => IP Flow Information eXport (IPFIX)

While
   technology and process transformations are taking place is it
   critical that people training takes place as well. 

is it critical => it is critical

   malevolent person has now two attack vectors: IPv4 and IPv6.  This
   simply means that all routers and hosts operating in a dual-stack
   environment with both protocol families enabled (even if by default)
   must have a congruent security policy for both protocol version. 

version => versions

 There may be a registration
   fee for requesting provider-independent (PI) space from and NIR/RIR,

and => a

In the case of PI, the organization will need to support BGP based
   connectivity for the most part since the address space is assigned
   direction from the Regional Registry to the local network. 

direction => directly

Native IPv6
   connectivity is preferred since it provides the most rebuts form of
   connectivity.

rebuts => robust ?

--
Tassos