[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New Version Notification for draft-ietf-v6ops-v6inixp-02



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

alain,

Thanks for your reviews.

I will correct all the typos that you pointed out.

Also, refering to your comment on the last paragraph of section 3 I am introducing the text that we discussed in the list:

- ---------
IPv6 prefixes for IXP LANs are typically publicly well known and taken from dedicated IPv6 blocks for IXP assignments reserved for this purpose by the different RIRs.The current practice that applies to IPv4 about publishing IXP allocations to the DFZ (Default Free Zone) should also apply to the IPv6 allocation. When considering the routing of the IXP LANs two options are identified:
	
- 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's AS boundries. 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. Using this configuration, the monitoring of the IXP LANs from outside of its participants' AS boundaries is not possible. - 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.
	
IXP external services (such as dns, web pages, ftp servers) need to be globally routed. Strict prefix length filtering could be the reason for requesting more than one /48 assignment from a RIR (i.e. requesting one /48 assignment for the IXPs LANs that may not be globally routed and a different /48 assignment for the IXP external services that will be globally routed).
- ---------

Regards,
Roque

On Oct 5, 2009, at 10:40 PM, ALAIN AINA wrote:


On Sep 9, 2009, at 2:25 AM, Roque Gagliano wrote:

Hi,

I issued a new ID of the draft with the changes that came up at the Stockholm meeting. Changes were:
- I explained why ULA is not a good idea.
- I added that addressing can use two different /48, one for the LANs and the second one for the internal services and not necessarily one /47, as comments at the meeting.
- I included comments from Nick Hilliar about BGP sessions.
- I added text about having different participants in different solocited-node multicast group.
- I mention of RA-Guard based on comments from Nick Hilliar.

I will now request Alain and Bernard to review the doc as they are the WG volunteers.


attached is a .doc version with my comments


hope this helps

--alain
<aina-review-of-draft-ietf-v6ops-v6inixp-02.doc>


Regards,

Roque.




Begin forwarded message:

From: IETF I-D Submission Tool <idsubmission@ietf.org>
Date: September 8, 2009 11:00:14 PM GMT-03:00
To: roque@lacnic.net
Subject: New Version Notification for draft-ietf-v6ops-v6inixp-02


A new version of I-D, draft-ietf-v6ops-v6inixp-02.txt has been successfuly submitted by Roque Gagliano and posted to the IETF repository.

Filename:	 draft-ietf-v6ops-v6inixp
Revision:	 02
Title:		 IPv6 Deployment in Internet Exchange Points (IXPs)
Creation_date:	 2009-09-08
WG ID:		 v6ops
Number_of_pages: 10

Abstract:
This document provides a guide for IPv6 deployment in Internet
Exchange Points (IXP).  It includes information regarding the switch
fabric configuration, the addressing plan and general organizational
tasks to be performed.  IXPs are mainly a layer 2 infrastructure and
in many case the best recommendations state that the IPv6 data,
control and management plane should not be handled differently than
in IPv4.



The IETF Secretariat.


-------------------------------------------------------------
Roque Gagliano
LACNIC
roque@lacnic.net
GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 6CEE



- -------------------------------------------------------------
Roque Gagliano
LACNIC
roque@lacnic.net
GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 6CEE

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEUEARECAAYFAkrhsmMACgkQnk+WSgHpbO7aygCYyI1TtFrarx2z5xCcArpn0IV+
zQCgggTUcboEcDN7VzSfHll0VHD28+c=
=OqXk
-----END PGP SIGNATURE-----