comments about draft-ietf-v6ops-v6inixp-03.txt

[Eduardo Ascenço Reis <eduardo@intron.com.br>]

Hi Roque and Fellows,

Here are some comments about draft-ietf-v6ops-v6inixp-03.txt:

+++++++++++++++++++++++++++++++++++++

2.  Switch Fabric Configuration

...
However, some management
   functions require explicit IPv6 support (such as switch management,
   SNMP [RFC1157] support and flow analysis exportation)
...
These management tasks can still be done in IPv4.

...
If participants are using
       untagged interconnections with the IXP switch and wish to
       continue doing so, they will need to facilitate a separate
       physical port to access the IPv6-specific LAN.
...
Suggestion to replace facilitate with provide.

+++++++++++++++++++++++++++++++++++++

3.  Addressing Plan

...
Longer
   prefixes (/65-/127), are technically feasible but are normally
   discouraged because of operational practices.
...
Why?


...
   When selecting the use of static Interface Identifiers (IIDs), there
   are different options on how to "intelligently" fill its 64 bits
...
I suggest to remove "intelligently" from the sentence.


...
   o  IXPs may decide that LANs should not to be globally routed in
      order to limit the possible origins of a Distributed Denial of
      Service (DDoS) attack to its particpant' AS boundries.
...
Words participants and boundaries with typos.


...
In this
      configuration participants may route these prefixes inside their
      networks (e. g. using BGP no-export communities or routing the IXP
      LANs within the participants' IGP) to perform fault management.
...
I recommend for AS to use next-hop-self on iBGP sessions, by doing
that there will be no need to redistribute IXP prefix into their IGP.


...
IXP may decide that LANs should be globally routed.  In this case,
      IXP LANs monitoring from outside its participants' AS boundaries
      is possible but the IXP LANs will be vulnerable to DDoS from
      outside of those broundries.
...
Words participants and boundaries with typos.

+++++++++++++++++++++++++++++++++++++

6.  Route Server

...
The use of MD5 [RFC2385] or IPSEC [RFC4301] to
   authenticate the BGP sessions and the use of GTSM (The Generalized
   TTL Security Mechanism) [RFC3682] should be considered.
...
For sure that these mechanisms are important to help securing the BGP
session, but as they are related to the BGP session itself and not to
IPv6 address families they do not seem to fit well on this document.


...
Route Server
Router-Server
...
These terms may be confusing for the reader to identify from the ones
used for MLPA and for others tasks.
I recommend to highlight the idea that MLPA route servers should not
have external (Internet) access to them for security matters.

+++++++++++++++++++++++++++++++++++++

8.  IXP Policies and IPv6

I strongly recommend to include IPv6 prefixes number
control/limitation (maximum-prefix) between neighbours.
I understand that this feature may be useful for some IPv4 BGP
sessions, but it is mandatory for IPv6 sessions, because of the huge
amount of prefixes that may be advertised per netblock (e.g. /32 le
/64).

+++++++++++++++++++++++++++++++++++++

Thanks,

-- 

Eduardo Ascenço Reis