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

[KK <[e-mail]>]

Tassos,

Thank you very much for your detailed feedback and apologies for the
delayed response.

There are many good points that you raise here. We will go through these
individually and come back to you with further clarifications as we
incorporate your suggested changes in the next rev.

Regards,
KK



On Sun, Sep 16, 2012 at 3:05 AM, Tassos Chatzithomaoglou <
[e-mail]> wrote:

>
> 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 [RFC4193 <http://tools.ietf.org/html/rfc4193>] and IPv4
>    private addressing [RFC1918 <http://tools.ietf.org/html/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 [CYMRU <http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-01#ref-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
>    ([I-D.gashinsky-v6ops-v6nd-problems <http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-01#ref-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 [RFC6164 <http://tools.ietf.org/html/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 [RFC4890 <http://tools.ietf.org/html/rfc4890>]):
>
>
> except that ICMPv6 messages => except that some ICMPv6 messages
>
>  The peering router must also implement anti-spoofing technique based
>    on [RFC2827 <http://tools.ietf.org/html/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
>    [RFC5102 <http://tools.ietf.org/html/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
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>