Re: [address-policy-wg] 2014-09 New Policy Proposal (Language Clarification in “IPv6 Address Space Policy For Internet Exchange Points”)
On 23/10/2014 14:28, Marco Schmidt wrote:
A proposed change to RIPE Document IPv6 Address Space Policy For Internet Exchange Points is now available for discussion.
the tl;dr for my objection on this proposal is that it doesn't make much sense from the IXP point of view. The equivalent ipv4 policy notes: "This space will be used to run an IXP peering LAN; other uses are forbidden". That's kind-of ok for ipv4 - not perfect by any means, but ok (as a reference anecdata point, INEX is still using a single /24 assigned in 2004 for both peering and management, because it was hard to justify more at the time). For IPv6, it would be normal to assign a /64 per peering LAN, leaving 65535 other /64 subnets unused in the /48 assignment. For better or worse, many IXPs in the RIPE NCC service region use some of the other space in their /48 for management purposes. If this policy change goes through, then the RIPE NCC is mandating that they renumber this management into other space. The RIPE community doesn't have the authority to mandate this for existing IXPs. For future start-up IXPs, it often makes more sense to use a single prefix to provide address space for both peering and management, where management connectivity is handled by policy routing from the IXP's ASN. Maybe it might be appropriate for the IXP to use separate prefixes at the stage when an IXP has grown to the point that it attracts enough DDoS traffic directed at the IXP lan to cause trouble, but not before. Even then, this is a decision that the IXP should make: it's not the job of the RIPE community to tell the IXP how to manage their policy routing. Nick
On Oct 23, 2014, at 3:53 PM, Nick Hilliard <nick@inex.ie> wrote:
On 23/10/2014 14:28, Marco Schmidt wrote:
A proposed change to RIPE Document IPv6 Address Space Policy For Internet Exchange Points is now available for discussion.
the tl;dr for my objection on this proposal is that it doesn't make much sense from the IXP point of view.
The equivalent ipv4 policy notes: "This space will be used to run an IXP peering LAN; other uses are forbidden". That's kind-of ok for ipv4 - not perfect by any means, but ok (as a reference anecdata point, INEX is still using a single /24 assigned in 2004 for both peering and management, because it was hard to justify more at the time).
For IPv6, it would be normal to assign a /64 per peering LAN, leaving 65535 other /64 subnets unused in the /48 assignment. For better or worse, many IXPs in the RIPE NCC service region use some of the other space in their /48 for management purposes.
If this policy change goes through, then the RIPE NCC is mandating that they renumber this management into other space. The RIPE community doesn't have the authority to mandate this for existing IXPs.
For future start-up IXPs, it often makes more sense to use a single prefix to provide address space for both peering and management, where management connectivity is handled by policy routing from the IXP's ASN.
Maybe it might be appropriate for the IXP to use separate prefixes at the stage when an IXP has grown to the point that it attracts enough DDoS traffic directed at the IXP lan to cause trouble, but not before. Even then, this is a decision that the IXP should make: it's not the job of the RIPE community to tell the IXP how to manage their policy routing.
Nick
+1 - the other thing I'd add is that "three ISPs" is an out of date and restrictive measure for assigning IP address space as well. I'd like to see the language reflect current standards and BCPs which define an IXP as more than 2 autonomous systems. (OIX-1 and a few BCPs floating around). Best, -M<
La seconda Il 23/10/2014 22.36, Hannigan, Martin ha scritto:
On Oct 23, 2014, at 3:53 PM, Nick Hilliard <nick@inex.ie> wrote:
A proposed change to RIPE Document IPv6 Address Space Policy For Internet Exchange Points is now available for discussion.
On 23/10/2014 14:28, Marco Schmidt wrote: the tl;dr for my objection on this proposal is that it doesn't make much sense from the IXP point of view.
The equivalent ipv4 policy notes: "This space will be used to run an IXP peering LAN; other uses are forbidden". That's kind-of ok for ipv4 - not perfect by any means, but ok (as a reference anecdata point, INEX is still using a single /24 assigned in 2004 for both peering and management, because it was hard to justify more at the time).
For IPv6, it would be normal to assign a /64 per peering LAN, leaving 65535 other /64 subnets unused in the /48 assignment. For better or worse, many IXPs in the RIPE NCC service region use some of the other space in their /48 for management purposes.
If this policy change goes through, then the RIPE NCC is mandating that they renumber this management into other space. The RIPE community doesn't have the authority to mandate this for existing IXPs.
For future start-up IXPs, it often makes more sense to use a single prefix to provide address space for both peering and management, where management connectivity is handled by policy routing from the IXP's ASN.
Maybe it might be appropriate for the IXP to use separate prefixes at the stage when an IXP has grown to the point that it attracts enough DDoS traffic directed at the IXP lan to cause trouble, but not before. Even then, this is a decision that the IXP should make: it's not the job of the RIPE community to tell the IXP how to manage their policy routing.
Nick
+1 - the other thing I'd add is that "three ISPs" is an out of date and restrictive measure for assigning IP address space as well. I'd like to see the language reflect current standards and BCPs which define an IXP as more than 2 autonomous systems. (OIX-1 and a few BCPs floating around).
Best,
-M<
-- Ing. Gabriele Rocca Consorzio TOP-IX Via Bogino 9 - 10123 Torino - Italy Mobile: +39 3346293329 Fax: +39 0118802619 Skype: gabrieleroc LinkedIn: http://www.linkedin.com/in/rocca Ai sensi del D.Lgs. 196/2003 le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i, sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceveste questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Qualsiasi utilizzo non autorizzato del contenuto di questo messaggio costituisce violazione dell'obbligo di non prendere cognizione della corrispondenza tra altri soggetti, salvo più grave illecito, ed espone il responsabile alle relative conseguenze civili e penali.
Hi, On Thu, Oct 23, 2014 at 08:53:23PM +0100, Nick Hilliard wrote:
stage when an IXP has grown to the point that it attracts enough DDoS traffic directed at the IXP lan to cause trouble, but not before. Even then, this is a decision that the IXP should make: it's not the job of the RIPE community to tell the IXP how to manage their policy routing.
But it *is* the job of the RIPE community to tell receivers of address space what strings are attached to it, in no uncertain terms, where the existing text obviously wasn't clear enough. I maintain that the intention of the existing policy text for IXP prefixes and root name server prefixes was all the time "you get a special exception for that which makes you special (IXP fabric, and root name server), and for *everything* *else*, you're just a normal participant and do what any other Internet-connected company would do to get connectivity and space" - strictly a MUST in RFC2119 terms, not a "we politely ask you and if you do not want that, feel free to ignore it". But that was ages ago, so it's good to actually revisit this and decide what we want the policy to be, and make it very explicitly so. Gert Doering APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
La terza Il 23/10/2014 23.30, Gert Doering ha scritto:
Hi,
On Thu, Oct 23, 2014 at 08:53:23PM +0100, Nick Hilliard wrote:
stage when an IXP has grown to the point that it attracts enough DDoS traffic directed at the IXP lan to cause trouble, but not before. Even then, this is a decision that the IXP should make: it's not the job of the RIPE community to tell the IXP how to manage their policy routing. But it *is* the job of the RIPE community to tell receivers of address space what strings are attached to it, in no uncertain terms, where the existing text obviously wasn't clear enough.
I maintain that the intention of the existing policy text for IXP prefixes and root name server prefixes was all the time "you get a special exception for that which makes you special (IXP fabric, and root name server), and for *everything* *else*, you're just a normal participant and do what any other Internet-connected company would do to get connectivity and space" - strictly a MUST in RFC2119 terms, not a "we politely ask you and if you do not want that, feel free to ignore it".
But that was ages ago, so it's good to actually revisit this and decide what we want the policy to be, and make it very explicitly so.
Gert Doering APWG chair
-- Ing. Gabriele Rocca Consorzio TOP-IX Via Bogino 9 - 10123 Torino - Italy Mobile: +39 3346293329 Fax: +39 0118802619 Skype: gabrieleroc LinkedIn: http://www.linkedin.com/in/rocca Ai sensi del D.Lgs. 196/2003 le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i, sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceveste questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Qualsiasi utilizzo non autorizzato del contenuto di questo messaggio costituisce violazione dell'obbligo di non prendere cognizione della corrispondenza tra altri soggetti, salvo più grave illecito, ed espone il responsabile alle relative conseguenze civili e penali.
On Thu, Oct 23, 2014 at 08:53:23PM +0100, Nick Hilliard wrote:
The equivalent ipv4 policy notes: "This space will be used to run an IXP peering LAN; other uses are forbidden". That's kind-of ok for ipv4 - not perfect by any means, but ok (as a reference anecdata point, INEX is still using a single /24 assigned in 2004 for both peering and management, because it was hard to justify more at the time).
I would remove this prohibition in existing v4 policy as well.
For future start-up IXPs, it often makes more sense to use a single prefix to provide address space for both peering and management, where management connectivity is handled by policy routing from the IXP's ASN.
I agree with Nick's points and oppose this proposal as well. Furthermore, I would propose that the IPv4 and IPv6 policies, as regards IXPs, be changed to explicitly permit use of the assignments for mgmt purposes. Prohibiting this creates additional work for IXPs to no apparent purpose. rgds, Sascha Luck
Hi,
Op 23 okt. 2014, om 23:40 heeft Sascha Luck <lists-ripe@c4inet.net> het volgende geschreven:
I agree with Nick's points and oppose this proposal as well. Furthermore, I would propose that the IPv4 and IPv6 policies, as regards IXPs, be changed to explicitly permit use of the assignments for mgmt purposes. Prohibiting this creates additional work for IXPs to no apparent purpose.
Ok, it seems that this language clarification proposal has uncovered some concerns about the current policy. If we want policy to be interpreted as 'the IXP prefix should be used for the peering LAN, but using it for IXP management purposes is also fine' then we need a policy change because as I read it the current text is explicitly saying the opposite. Any volunteers for writing a policy proposal? :) Cheers, Sander
participants (6)
-
Gabriele Rocca -
Gert Doering -
Hannigan, Martin -
Nick Hilliard -
Sander Steffann -
Sascha Luck