Brasil/Mexico/Argentina connectivity

[Olivier CALVANO]

Hi

I am search one or more carrier for connect 3 sites in Brasil, Mexico
and Argentina to one of our pop
in USA or Spain.

if you have a name and contact ;=)

best regards
Olivier

Re: "authority" to route?

[Robert Glover]

Another big-name-big-$$$ vendor whose name begins with "C".  Sounds like 
a "c"onspiracy to me


On 11/14/2012 5:09 PM, Mark Gauvin wrote:

Careful though cause the crayons must be crayola approved

Sent from my iPhone

On 2012-11-14, at 5:28 PM, "joel jaeggli"  wrote:


On 11/14/12 2:40 PM, Joe Abley wrote:

On 2012-11-12, at 14:43, Jim Mercer  wrote:


Is there a common practice of providers to vet / validate requests to advertise
blocks?

Yes, most providers whose customers request a particular route to be pointed 
towards them will ask for ambiguous instructions, written on letterhead with 
crayon, and signed illegibly by someone who may or may not have authority to do 
so but who in any case cannot be identified clearly by their scrawl.

Some providers ask for route objects and appropriate import/export
policy in RADB. that fandamently no higher quality an attestation than a
LOA but it's a lot easier to read.

Ideally the letterhead should be crudely constructed in photoshop and then 
faxed across a noisy analogue line.

Once you have one of those babies in your file, no lawyer can touch you.


Joe

Re: "authority" to route?

[Mark Gauvin]

Careful though cause the crayons must be crayola approved

Sent from my iPhone

On 2012-11-14, at 5:28 PM, "joel jaeggli"  wrote:

> On 11/14/12 2:40 PM, Joe Abley wrote:
>> On 2012-11-12, at 14:43, Jim Mercer  wrote:
>> 
>>> Is there a common practice of providers to vet / validate requests to 
>>> advertise
>>> blocks?
>> Yes, most providers whose customers request a particular route to be pointed 
>> towards them will ask for ambiguous instructions, written on letterhead with 
>> crayon, and signed illegibly by someone who may or may not have authority to 
>> do so but who in any case cannot be identified clearly by their scrawl.
> Some providers ask for route objects and appropriate import/export 
> policy in RADB. that fandamently no higher quality an attestation than a 
> LOA but it's a lot easier to read.
>> Ideally the letterhead should be crudely constructed in photoshop and then 
>> faxed across a noisy analogue line.
>> 
>> Once you have one of those babies in your file, no lawyer can touch you.
>> 
>> 
>> Joe
>> 
>> 
>> 
> 
> 

Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.

[William Herrin]

On Wed, Nov 14, 2012 at 6:31 PM, Michael Smith  wrote:
>
> On Nov 14, 2012, at 1:50 PM, William Herrin  wrote:
>
>> On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith  wrote:
>>> I guess I'm confused.  I have a /32 that I have broken up
>>> into /47's for my discrete POP locations.  I don't have a
>>> network between them, by design.  And, I won't
>>> announce the /32 covering route because there is
>>> no single POP that can take requests for the entire
>>> /32 - think regionalized anycast.
>>>
>>> So, how is it "worse" to announce the deaggregated
>>> /47's versus getting a /32 for every POP?  In either
>>> case, I'm going to put the same number of routes into the DFZ.
>>
>> If you announce an ISP /32 from each POP (or an end-user /48, /47,
>> etc) then I know that a neutral third party has vetted your proposed
>> network configuration and confirmed that the routes are disaggregated
>> because the network architecture requires it. If you announce a /47
>> from your ISP space, for all I know you're trying to tweak utilization
>> on your ISP uplinks.
>
> Again, I thought the discussion was about PI, not PA.  I don't announce any 
> PA.

Hi Michael,

PI and PA terminology is getting to be as obsolete as Class A, B and
C. Your IPv6 addresses fall in to one of three categories:

"Allocation" from RIR under ISP rules (/32 or more)
"Assignment" from RIR under end-user rules (/48 or more)
"Reassignment" from ISP (any size)

You will find that you can successfully propagate announcements of
allocations in units of /32 or shorter, assignments in units of /48 or
shorter and reassignments in units of /32 or shorter.

Longer prefix announcements won't be rejected by everybody, but
they'll be rejected by enough folks to spoil your day.

So, regardless of which of the three types of addresses you work with,
you should make sure to get enough so that each of your discrete
multihomed networks can announce a prefix as big as or bigger than the
minimum.

And as a purely pragmatic matter, you should never ever try to number
a discrete multihomed IPv6 network using a reassignment. Go get an
allocation or assignment (as appropriate) from the RIR instead.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

RE: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.

[Ben S. Butler]

Hi,

" Again, I thought the discussion was about PI, not PA.  I don't announce any 
PA."

My point, which I feel may be getting lost, and for which ARIN may already have 
policies in place for, is that an IP assignment is made out of a block with a 
defined minimum assignment size.

Now some people simply advertise the assignment that is made to them, some 
people chose to advertise more specifics with a covering route, I have no 
problem with any of this.  What I am saying, is if people chose to deagregate 
to create islands, for which I can completely understand the commercial and 
networking reason and why it is then by extension impossible for them to 
advertise the covering route. Then in these specific cases of "islands" then 
these assignments should be made by the RIR from a block with a minimum prefix 
size of a /48.  Then the application is submitted to the RIR it will justify as 
much space as it justifies, but at this point it should also be established - 
without any judgment positive or negative - if the intention is to advertise 
this unagregated or with a route for the aggregate.  The RIR would then be 
empowered to assign the requested amount of address space from a block which 
can be labelled with a lower minimum prefix size.

I am not judging any of these design practices.  What I am pointing out is that 
the designs are being implemented in assignment blocks that do not reflect the 
recipients implementations intentions and this is neither helpful for them or 
other AS operators when it comes to filtering.  If RIR policies establish this 
intention at the point of assignment then the "island" case will be catered for 
and we absolutely do not want to see an aggregate in the route table for 
assignments from that block.  IF it is TE then it can be made from a 
conventional block with a cover router and more specifics.

What I am seeing in the real world is island networks in address space with 
minimum /32 assigments.  It is my choice if I filter your TE, it is a stupid 
choice if you don't advertise the cover route because you are doing TE.  But 
what we need to facilitate are islands networks which for very sensible 
technical and commercial reasons are unable to advertise an aggregate.  
Policies may be in place to provide for this, however, what I am seeing in the 
route table is telling me that the policies are failing to identify people that 
want to implement their network in this fashion as they are coming from blocks 
with /32 min and they are advertising /48s.  If these announcements came from 
and address block to which they were assigned with a minimum of a /48 because 
of their design intentions then everyone is happy and can announce and filer 
accordingly and end points are reachable.

There is a reason that different blocks have different minimum sizes, I am 
advocating ensuring that we get assignments aligned with the blocks that are 
suit the intended implementation.

It is not my place to judge your business, nor is it anyone elses to expect the 
rest of us to accept TE routes without a coverall and expect to be reachable.

My 2c

Ben

-Original Message-
From: Michael Smith [mailto:mksm...@mac.com] 
Sent: 14 November 2012 23:32
To: William Herrin
Cc: nanog@nanog.org; Michael Smith
Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 
RIR minimums.


On Nov 14, 2012, at 1:50 PM, William Herrin  wrote:

> On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith  wrote:
>> I guess I'm confused.  I have a /32 that I have broken up into /47's 
>> for my discrete POP locations.  I don't have a network between them, 
>> by design.  And, I won't announce the /32 covering route because 
>> there is no single POP that can take requests for the entire
>> /32 - think regionalized anycast.
>> 
>> So, how is it "worse" to announce the deaggregated /47's versus 
>> getting a /32 for every POP?  In either case, I'm going to put the 
>> same number of routes into the DFZ.
> 
> Hi Michael,
> 
> If you announce an ISP /32 from each POP (or an end-user /48, /47,
> etc) then I know that a neutral third party has vetted your proposed 
> network configuration and confirmed that the routes are disaggregated 
> because the network architecture requires it. If you announce a /47 
> from your ISP space, for all I know you're trying to tweak utilization 
> on your ISP uplinks.
> 
Again, I thought the discussion was about PI, not PA.  I don't announce any PA.

> In the former case, the protocols are capable of what they're capable 
> of. Discrete multihomed network, discrete announcement. Like it or 
> lump it.
> 
> In the latter case, I don't particularly need to burn resources on my 
> router half a world away to facilitate your traffic tweaking. Let the 
> ISPs you're paying for the privilege carry your more-specifics.
> 

You have great confidence in the immutability of design and the description 
thereof.

Mike

Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.

[Michael Smith]

On Nov 14, 2012, at 1:50 PM, William Herrin  wrote:

> On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith  wrote:
>> I guess I'm confused.  I have a /32 that I have broken up
>> into /47's for my discrete POP locations.  I don't have a
>> network between them, by design.  And, I won't
>> announce the /32 covering route because there is
>> no single POP that can take requests for the entire
>> /32 - think regionalized anycast.
>> 
>> So, how is it "worse" to announce the deaggregated
>> /47's versus getting a /32 for every POP?  In either
>> case, I'm going to put the same number of routes into the DFZ.
> 
> Hi Michael,
> 
> If you announce an ISP /32 from each POP (or an end-user /48, /47,
> etc) then I know that a neutral third party has vetted your proposed
> network configuration and confirmed that the routes are disaggregated
> because the network architecture requires it. If you announce a /47
> from your ISP space, for all I know you're trying to tweak utilization
> on your ISP uplinks.
> 
Again, I thought the discussion was about PI, not PA.  I don't announce any PA.

> In the former case, the protocols are capable of what they're capable
> of. Discrete multihomed network, discrete announcement. Like it or
> lump it.
> 
> In the latter case, I don't particularly need to burn resources on my
> router half a world away to facilitate your traffic tweaking. Let the
> ISPs you're paying for the privilege carry your more-specifics.
> 

You have great confidence in the immutability of design and the description 
thereof.

Mike

Re: "authority" to route?

[joel jaeggli]

On 11/14/12 2:40 PM, Joe Abley wrote:

On 2012-11-12, at 14:43, Jim Mercer  wrote:


Is there a common practice of providers to vet / validate requests to advertise
blocks?

Yes, most providers whose customers request a particular route to be pointed 
towards them will ask for ambiguous instructions, written on letterhead with 
crayon, and signed illegibly by someone who may or may not have authority to do 
so but who in any case cannot be identified clearly by their scrawl.
Some providers ask for route objects and appropriate import/export 
policy in RADB. that fandamently no higher quality an attestation than a 
LOA but it's a lot easier to read.

Ideally the letterhead should be crudely constructed in photoshop and then 
faxed across a noisy analogue line.

Once you have one of those babies in your file, no lawyer can touch you.


Joe

Re: "authority" to route?

[Joe Abley]

On 2012-11-12, at 14:43, Jim Mercer  wrote:

> Is there a common practice of providers to vet / validate requests to 
> advertise
> blocks?

Yes, most providers whose customers request a particular route to be pointed 
towards them will ask for ambiguous instructions, written on letterhead with 
crayon, and signed illegibly by someone who may or may not have authority to do 
so but who in any case cannot be identified clearly by their scrawl.

Ideally the letterhead should be crudely constructed in photoshop and then 
faxed across a noisy analogue line.

Once you have one of those babies in your file, no lawyer can touch you.


Joe

Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.

[William Herrin]

On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith  wrote:
> I guess I'm confused.  I have a /32 that I have broken up
> into /47's for my discrete POP locations.  I don't have a
> network between them, by design.  And, I won't
> announce the /32 covering route because there is
> no single POP that can take requests for the entire
> /32 - think regionalized anycast.
>
> So, how is it "worse" to announce the deaggregated
> /47's versus getting a /32 for every POP?  In either
> case, I'm going to put the same number of routes into the DFZ.

Hi Michael,

If you announce an ISP /32 from each POP (or an end-user /48, /47,
etc) then I know that a neutral third party has vetted your proposed
network configuration and confirmed that the routes are disaggregated
because the network architecture requires it. If you announce a /47
from your ISP space, for all I know you're trying to tweak utilization
on your ISP uplinks.

In the former case, the protocols are capable of what they're capable
of. Discrete multihomed network, discrete announcement. Like it or
lump it.

In the latter case, I don't particularly need to burn resources on my
router half a world away to facilitate your traffic tweaking. Let the
ISPs you're paying for the privilege carry your more-specifics.

Regards,
Bill Herrin

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Ethernet NID plus POE+ (802.3at)... or POE+ injector with OAM...

[R. Scott Evans]

On Wed, 14 Nov 2012 14:57:06 -0500, "Robert E. Seastrom" 
wrote:
> Hi everyone,
> 
> I'm looking for a gigabit ethernet media converter to go from SFP
> plugable optics to 802.3at POE+.  The application involves wireless
> access points some distance from a central switch for a venue.
> 
> Difficulty: in my old age, I've become allergic to installing
> completely unmanaged bump-in-the-wire devices that can't be monitored
> in some way.  They make for a big nuisance when it comes time to debug
> the installation.
> 
> The metro ethernet folks have brought us 802.1ag, 802.3ah, and Y.1731.
> Even the simplest of these - .1ag L2 ping (LBM/LBR) - is sufficient
> for my purposes of making sure that we're bidirectionally passing
> traffic.
> 
> I'm aware of pluggable optics that do OAM (OEsolution Smart SFP) as
> well as some piggyback devices from other sources.
> 
> I'd like to find a single box though that will do my media conversion,
> POE+ injection, and response to OAM packets all in one convenient tiny
> enclosure.  Bonus points for well-thought-out details such as DIN rail
> mounting capability and cable retention tricks.
> 
> Anyone got any pointers?
> 
> -f

You'll probably have better luck looking for a switch.

http://www.transition.com/TransitionNetworks/Products2/Family.aspx?Name=SISPM1040-384-LRT

-scott

Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.

[Michael Smith]

On Nov 14, 2012, at 10:06 AM, William Herrin  wrote:

> On Wed, Nov 14, 2012 at 12:08 PM, Ben S. Butler
>  wrote:
>> Yes, nice.  But... It does not address the case when this is
>> not the ISPs customers but the ISP (read content provider)
>> that operates globally but without a network interconnecting
>> their routers.
> 
> Hi Ben,
> 
> That case is covered by things like ARIN's multiple discrete networks
> policy which permit an ISP /32 or end-user /48 for _each_ distinct
> network. There are plenty of addresses in IPv6. You should be break up
> a /32 for traffic engineering purposes, not for the sake of handling
> multiple disconnected sites. And when exercising TE, you can offer a
> covering route and expect the network as a whole to still function
> regardless of other folks' suballocation filtering.
> 
> Regards,
> Bill Herrin
> 

I guess I'm confused.  I have a /32 that I have broken up into /47's for my 
discrete POP locations.  I don't have a network between them, by design.  And, 
I won't announce the /32 covering route because there is no single POP that can 
take requests for the entire /32 - think regionalized anycast.

So, how is it "worse" to announce the deaggregated /47's versus getting a /32 
for every POP?  In either case, I'm going to put the same number of routes into 
the DFZ.

Mike

Ethernet NID plus POE+ (802.3at)... or POE+ injector with OAM...

[Robert E. Seastrom]

Hi everyone,

I'm looking for a gigabit ethernet media converter to go from SFP
plugable optics to 802.3at POE+.  The application involves wireless
access points some distance from a central switch for a venue.

Difficulty: in my old age, I've become allergic to installing
completely unmanaged bump-in-the-wire devices that can't be monitored
in some way.  They make for a big nuisance when it comes time to debug
the installation.

The metro ethernet folks have brought us 802.1ag, 802.3ah, and Y.1731.
Even the simplest of these - .1ag L2 ping (LBM/LBR) - is sufficient
for my purposes of making sure that we're bidirectionally passing
traffic.

I'm aware of pluggable optics that do OAM (OEsolution Smart SFP) as
well as some piggyback devices from other sources.

I'd like to find a single box though that will do my media conversion,
POE+ injection, and response to OAM packets all in one convenient tiny
enclosure.  Bonus points for well-thought-out details such as DIN rail
mounting capability and cable retention tricks.

Anyone got any pointers?

-f

Re: DHCPv6 and MAC addresses

[Ray Soucy]

Well I guess someone is already working on it, +1

Since this is a relay-only message, though.  I think it would be
better as a sub-option of RFC 6422 with a requirement that
relay-agents drop the option if the client tries to source it.  But, I
guess it's splitting hairs.




On Wed, Nov 14, 2012 at 1:02 PM, Tim Chown  wrote:
> What about
>
> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-03
>
> ?
>
> --
> Tim
>
> On 14 Nov 2012, at 17:46, Ray Soucy  wrote:
>
> Saw yet another attempt at a solution pop up to try and deal with the
> lack of a MAC address in DHCPv6 messages.
>
> I've been giving this some thought about how this should be best
> accomplished without requiring that host implementations of DHCPv6 be
> modified.
> Taking advantage of the relay-agent seems to be the most elegant solution:
>
> 1) Any DHCPv6 server on a local segment will already have access to
> the MAC address; but having a DHCPv6 server on each segment is not
> ideal.
> 2) Requests that are relayed flow through a relay-agent, which is on a
> device that also has access to the MAC address of the client system.
>
>
>
>
> Option A:
>
> RFC 6422 provides for Realy-Supplied DHCP Options, currently with one
> option code registered with IANA (OPTION_ERP_LOCAL_DOMAIN_NAME).
> You can see the list here:
>
> http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml
>
> I think the quickest solution would be:
>
> 1) Adding an RSOO for the client MAC address
> 2) Get vendors on board to draft and adopt a standard for it on routers,
> 3) Modify DHCPv6 servers to have support for MAC identification based
> on the MAC of the local request OR the MAC of the relayed request when
> the option is present.
>
>
>
>
> Option B:
>
> The current RELAY-FORW message already includes the link-local address
> of the client.  Perhaps there should be a modification to the privacy
> extensions RFC to forbid the use of privacy addressing on the
> link-local scope; at this point we could modify DHCPv6 servers to be
> able to determine the MAC address for relayed requests based on their
> link-local address.
>
> Unfortunately, the cat is out of the bag on this one, so it would take
> time to get host implementations modified.
>
>
>
>
> I might be overlooking something critical... thoughts?
>
>
>
>
> --
> Ray Patrick Soucy
> Network Engineer
> University of Maine System
>
> T: 207-561-3526
> F: 207-561-3531
>
> MaineREN, Maine's Research and Education Network
> www.maineren.net
>



-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.

[William Herrin]

On Wed, Nov 14, 2012 at 12:08 PM, Ben S. Butler
 wrote:
> Yes, nice.  But... It does not address the case when this is
>not the ISPs customers but the ISP (read content provider)
>that operates globally but without a network interconnecting
>their routers.

Hi Ben,

That case is covered by things like ARIN's multiple discrete networks
policy which permit an ISP /32 or end-user /48 for _each_ distinct
network. There are plenty of addresses in IPv6. You should be break up
a /32 for traffic engineering purposes, not for the sake of handling
multiple disconnected sites. And when exercising TE, you can offer a
covering route and expect the network as a whole to still function
regardless of other folks' suballocation filtering.

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: DHCPv6 and MAC addresses

[Tim Chown]

What about

http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-03

?

--
Tim

On 14 Nov 2012, at 17:46, Ray Soucy  wrote:

> Saw yet another attempt at a solution pop up to try and deal with the
> lack of a MAC address in DHCPv6 messages.
> 
> I've been giving this some thought about how this should be best
> accomplished without requiring that host implementations of DHCPv6 be
> modified.
> Taking advantage of the relay-agent seems to be the most elegant solution:
> 
> 1) Any DHCPv6 server on a local segment will already have access to
> the MAC address; but having a DHCPv6 server on each segment is not
> ideal.
> 2) Requests that are relayed flow through a relay-agent, which is on a
> device that also has access to the MAC address of the client system.
> 
> 
> 
> 
> Option A:
> 
> RFC 6422 provides for Realy-Supplied DHCP Options, currently with one
> option code registered with IANA (OPTION_ERP_LOCAL_DOMAIN_NAME).
> You can see the list here:
> 
> http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml
> 
> I think the quickest solution would be:
> 
> 1) Adding an RSOO for the client MAC address
> 2) Get vendors on board to draft and adopt a standard for it on routers,
> 3) Modify DHCPv6 servers to have support for MAC identification based
> on the MAC of the local request OR the MAC of the relayed request when
> the option is present.
> 
> 
> 
> 
> Option B:
> 
> The current RELAY-FORW message already includes the link-local address
> of the client.  Perhaps there should be a modification to the privacy
> extensions RFC to forbid the use of privacy addressing on the
> link-local scope; at this point we could modify DHCPv6 servers to be
> able to determine the MAC address for relayed requests based on their
> link-local address.
> 
> Unfortunately, the cat is out of the bag on this one, so it would take
> time to get host implementations modified.
> 
> 
> 
> 
> I might be overlooking something critical... thoughts?
> 
> 
> 
> 
> -- 
> Ray Patrick Soucy
> Network Engineer
> University of Maine System
> 
> T: 207-561-3526
> F: 207-561-3531
> 
> MaineREN, Maine's Research and Education Network
> www.maineren.net
> 

Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.

[Leo Bicknell]

In a message written on Wed, Nov 14, 2012 at 01:10:57PM +, Ben S. Butler 
wrote:
> I am hoping for a bit of advice.  We are rolling out IPv6 en mass now to 
> peers and I am finding that our "strict" IPv6 ingress prefix filter is 
> meaning a lot of peers are sending me zero prefixes.  Upon investigation I 
> determine they have de-agregrated their /32 for routing reasons / non 
> interconnected islands of address space and in consequence advertise no 
> covering /32 route.  The RIR block that the allocation is from is meant to 
> have a minimum assignment of /32.

You are conflating two different issues, which are essentially
toally unrelated.  There is the smallest size block an RIR will
allocate out of some chuck of address space, and then there is how
people announce it on the Internet.  In the real world they have
almost nothing to do with each other, something folks understand today
in IPv4 but seem to think IPv6 magically fixes, it doesn't.

[Historically there were folks who maintained filters on IPv4 space, but
they gradually disappeared as the filters became so long they were
unmaintinable, and people discovered when your job is to connect people
throwing away routes is a bad thing.]

For instance, there are folks who could use the "multiple discrete
networks" policy to get a /48 for each of their 5 sites.  But instead
they get on /32, use a /48 at each site, and announce them
independantly.  Same prefixes in the table, but filtering on the
RIR /32 boundry means you won't hear them.

I'll point out it's not just longer, but shorter prefixes as well:

> ipv6 prefix-list ipv6-ebgp-strict permit 2001:500::/30 ge 48 le 48

F-Root announces 2001:4f8:500:2e::/47.  You're going to miss it.
There are other servers in this block that are in /47's or /46's.

If connectivity is what you value, here's the right filter:

ipv6 prefix-list ipv6-ebgp-permissive 2001::/12 ge 13 le 48

Yes, the DOD has a /13, and yes, people expect to be able to announce
down to a /48.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpMoWNXRMIDy.pgp
Description: PGP signature

Re: dhcpy6d - a MAC address aware DHCPv6 server

[Ray Soucy]

FWIW ISC DHCPd listens on raw sockets.

On Tue, Nov 6, 2012 at 11:12 AM, George Herbert
 wrote:
> Oh, horrors, part of my infrastructure needs raw socket data?
>
> We should ban that, for security.  Who needs those pesky switches anyways?
>
>
> George William Herbert
> Sent from my iPhone
>
> On Nov 6, 2012, at 5:49 AM, Stephane Bortzmeyer  wrote:
>
>> On Tue, Nov 06, 2012 at 05:38:32AM -0800,
>> Owen DeLong  wrote
>> a message of 68 lines which said:
>>
>>> If you're on local subnet, why not pull the MAC address out of the
>>> received packet?
>>
>> Because it requires access to raw sockets, which should not be
>> necessary for DHCP?
>>
>>
>



-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

DHCPv6 and MAC addresses

[Ray Soucy]

Saw yet another attempt at a solution pop up to try and deal with the
lack of a MAC address in DHCPv6 messages.

I've been giving this some thought about how this should be best
accomplished without requiring that host implementations of DHCPv6 be
modified.
Taking advantage of the relay-agent seems to be the most elegant solution:

1) Any DHCPv6 server on a local segment will already have access to
the MAC address; but having a DHCPv6 server on each segment is not
ideal.
2) Requests that are relayed flow through a relay-agent, which is on a
device that also has access to the MAC address of the client system.




Option A:

RFC 6422 provides for Realy-Supplied DHCP Options, currently with one
option code registered with IANA (OPTION_ERP_LOCAL_DOMAIN_NAME).
You can see the list here:

http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml

I think the quickest solution would be:

1) Adding an RSOO for the client MAC address
2) Get vendors on board to draft and adopt a standard for it on routers,
3) Modify DHCPv6 servers to have support for MAC identification based
on the MAC of the local request OR the MAC of the relayed request when
the option is present.




Option B:

The current RELAY-FORW message already includes the link-local address
of the client.  Perhaps there should be a modification to the privacy
extensions RFC to forbid the use of privacy addressing on the
link-local scope; at this point we could modify DHCPv6 servers to be
able to determine the MAC address for relayed requests based on their
link-local address.

Unfortunately, the cat is out of the bag on this one, so it would take
time to get host implementations modified.




I might be overlooking something critical... thoughts?




-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.

[Frank Habicht]

On 11/14/2012 8:08 PM, Ben S. Butler wrote:
> Hi,
> 
> Yes, nice.  But... It does not address the case when this is not the ISPs 
> customers but the ISP (read content provider) that operates globally but 
> without a network interconnecting their routers.  They then advertise a /24 
> v4 and /48 v6 at each Internet exchange that they are connected to.  That is 
> "fine" for driving router.  The "problem" with this design is that they cant 
> announce their /32 as they are not running a iBGP mesh.  I have seen a number 
> of content providers doing this by design, and in the context of their 
> business I can understand why and see it makes some sense.  The only problem 
> comes with the prefixes ending up under the minimum prefix size for the block 
> they are in.
Yep. Ack.
For the filtering policies it'd be nice to use space from a special prefix
- like for PI assignments.
But that will drive "global" routing table size :-(
But that's what content providers who create islands are bound to do - or
is there a way around without real connectivity or tunnels?

And the "polluters" apparently don't have enough incentives or pain to void
islands...

Frank





> Now when this is a large content provider and we all want the peering, then 
> we relax the filters, fine, but why one rule for them and another for 
> everyone else in the same /12 block.  Would it not make sense for the RIRs to 
> assign a /12 as issuable in /32, /29 to content providers who will 
> specifically deagregate to /48 with no internal network.
> 
> That solves the filtering problem, doesn't force these networks to put an 
> iBGP network in place and lets everyone who does run a network "properly" to 
> announce the proper aggregate blocks / covering routes with more specifics if 
> we have to have them for routing purposes.
> 
> A separate /12 for the "island" type networks would immediately make this 
> problem disappear.
> 
> Am I being overly simplistic?
> 
> Ben
> 
> -Original Message-
> From: Frank Habicht [mailto:ge...@geier.ne.tz] 
> Sent: 14 November 2012 16:56
> To: nanog@nanog.org
> Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 
> RIR minimums.
> 
> On 11/14/2012 6:02 PM, William Herrin wrote:
> 
>> and send a polite email to the POC to the effect of, "Please beware 
>> that because you have not offered a covering route matching your 
>> allocation, your IPv6 network is not reachable from ours. IPv6 is not
>> IPv4: end users requiring /48s for multihoming should get them 
>> directly from the RIR. For complete Internet connectivity, we strongly 
>> encourage you to offer a covering route."
> 
> like that.
> Frank
> 
> 
> 
> 

RE: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.

[Ben S. Butler]

Hi,

Yes, nice.  But... It does not address the case when this is not the ISPs 
customers but the ISP (read content provider) that operates globally but 
without a network interconnecting their routers.  They then advertise a /24 v4 
and /48 v6 at each Internet exchange that they are connected to.  That is 
"fine" for driving router.  The "problem" with this design is that they cant 
announce their /32 as they are not running a iBGP mesh.  I have seen a number 
of content providers doing this by design, and in the context of their business 
I can understand why and see it makes some sense.  The only problem comes with 
the prefixes ending up under the minimum prefix size for the block they are in.

Now when this is a large content provider and we all want the peering, then we 
relax the filters, fine, but why one rule for them and another for everyone 
else in the same /12 block.  Would it not make sense for the RIRs to assign a 
/12 as issuable in /32, /29 to content providers who will specifically 
deagregate to /48 with no internal network.

That solves the filtering problem, doesn't force these networks to put an iBGP 
network in place and lets everyone who does run a network "properly" to 
announce the proper aggregate blocks / covering routes with more specifics if 
we have to have them for routing purposes.

A separate /12 for the "island" type networks would immediately make this 
problem disappear.

Am I being overly simplistic?

Ben

-Original Message-
From: Frank Habicht [mailto:ge...@geier.ne.tz] 
Sent: 14 November 2012 16:56
To: nanog@nanog.org
Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 
RIR minimums.

On 11/14/2012 6:02 PM, William Herrin wrote:

> and send a polite email to the POC to the effect of, "Please beware 
> that because you have not offered a covering route matching your 
> allocation, your IPv6 network is not reachable from ours. IPv6 is not
> IPv4: end users requiring /48s for multihoming should get them 
> directly from the RIR. For complete Internet connectivity, we strongly 
> encourage you to offer a covering route."

like that.
Frank

Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.

[Frank Habicht]

On 11/14/2012 6:02 PM, William Herrin wrote:

> and send a polite email to the POC to the effect of, "Please beware
> that because you have not offered a covering route matching your
> allocation, your IPv6 network is not reachable from ours. IPv6 is not
> IPv4: end users requiring /48s for multihoming should get them
> directly from the RIR. For complete Internet connectivity, we strongly
> encourage you to offer a covering route."

like that.
Frank

Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.

[William Herrin]

On Wed, Nov 14, 2012 at 8:10 AM, Ben S. Butler
 wrote:
> So what is the "best" answer.
>
>
> 1> Don't advertise islands of space under assignment minimum, without 
> providing a covering aggregate route?
>
> 2> Don't use strict filters, they don't work well and de-agragegation 
> with IPv6 is going to be a problem?
>
> 3> Don't use filters, generate it from an IRR?
>
> Given there is no "right" answer what is considered to be the best fit one?

IMHO:

4) Use mild filters (e.g. allow a /32 to be disaggregated to /36's)
and send a polite email to the POC to the effect of, "Please beware
that because you have not offered a covering route matching your
allocation, your IPv6 network is not reachable from ours. IPv6 is not
IPv4: end users requiring /48s for multihoming should get them
directly from the RIR. For complete Internet connectivity, we strongly
encourage you to offer a covering route."

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Eaton 9130 UPS feedback

[Greg Ihnen]

Are these UPS units going inside the racks? Would it not be better to do
something in the power room with an inverter on the circuits that feed the
racks, such as a large Outback unit with sufficient battery capacity?
http://www.amazon.com/OutBack-Inverter-3600-Watts-Volt/dp/B002MWAAYU

With one device acting as your UPS you'd have only one point of failure
(that may be a plus or minus), only one set of batteries to worry about,
and those inverters are very well made.

They have 120v and 240v units. There are other brands you could use but my
experience with various brands is that Outback is the best in their class.


Greg

On Wed, Nov 14, 2012 at 8:38 AM, Erik Amundson wrote:

> I've had issues and experience with many types of UPSes, including HP
> (probably OEM'd from someone else), APC, EATON/Powerware, and
> Liebert/Emerson.  I keep coming back to APC.  Solid units, and are always
> slightly 'ahead' in technology.  Sure, I've seen each model have failures
> and even faults (big boom style), but APC provides a solid product and
> supports their customers the best if you ask me.  That being said, a very
> close second choice would be EATON/Powerware.
>
> - Erik
>
>
> -Original Message-
> From: Seth Mattinen [mailto:se...@rollernet.us]
> Sent: Tuesday, November 13, 2012 1:59 PM
> To: nanog@nanog.org
> Subject: Eaton 9130 UPS feedback
>
> Does anyone use Eaton 9130 series UPS for anything? I'm curious how
> they've worked out for you.
>
> I bought a 700VA model to give it a whirl versus the traditional APC
> since the Eaton is an online type with static bypass and also does some
> high efficiency thing where it normally stays on bypass, but the first
> thing it did on the bench was have the inverter/rectifier or bypass
> section catch on fire and destroy itself.
>
> ~Seth
>
>
>

RE: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.

[Ben S. Butler]

Hi,

Yes, but a multi-homing customer would have PI space from an appropriately 
filtered block allowing /24 PI v4 or /48 PI v6.  An ISP would have their own 
RIR PA allocation /22 to /19 v4 or /29, /32 v6 block that are from blocks that 
follow along the lines of minimum assignment size for that block.  This is not 
a problem created by the registries or by the filters.  The problem comes with 
ASes that don’t have a backbone interconnecting all of their POPs / islands and 
are therefore unable to add a covering route and do not provide a route via any 
transit provide for the whole ip block at the RIR minimum boundary.  In some 
ways whether people should:


1>  Have a network of none interconnected islands that take IP space from 
the same IP block below RIR minimum?

2> Should we filter these networks?

3> Should the /32 be visible in the route table somewhere if the intention 
that component /48s are going to be visible on the Internet.

I don’t like the IRR answer particularly as it requires a level of third party 
trust that I am not entirely comfortable with, nor configuring separate filters 
for each BGP peering session.

Ben

From: Suresh Ramasubramanian [mailto:ops.li...@gmail.com]
Sent: 14 November 2012 13:25
To: Ben S. Butler
Cc: NANOG
Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 
RIR minimums.

On Wed, Nov 14, 2012 at 6:40 PM, Ben S. Butler 
mailto:ben.but...@c2internet.net>> wrote:

3> Don't use filters, generate it from an IRR?

Given there is no "right" answer what is considered to be the best fit one?

This sounds like your best bet.  Assuming you can find an IRR with 
comprehensive enough coverage.

The other option is of course "don't filter based solely on RIR minimum 
assignments" ..

I know at least some ISPs (like swisscom) do this for v4 too, but that simply 
means people who try to multihome with anything less than a /19  in level3 land 
aren't going to succeed.

http://v-authoring.ip-plus.net/documents/BIS_TI_Router_Filter_Policy_EN.pdf

ip prefix-list martians seq 8000 permit 8.0.0.0/7 le 19
[etc]

Not so much of a problem in v4 but as you saw for yourself, you risk not seeing 
prefixes at all if you try this.

--
Suresh Ramasubramanian (ops.li...@gmail.com)

RE: Eaton 9130 UPS feedback

[Erik Amundson]

I've had issues and experience with many types of UPSes, including HP (probably 
OEM'd from someone else), APC, EATON/Powerware, and Liebert/Emerson.  I keep 
coming back to APC.  Solid units, and are always slightly 'ahead' in 
technology.  Sure, I've seen each model have failures and even faults (big boom 
style), but APC provides a solid product and supports their customers the best 
if you ask me.  That being said, a very close second choice would be 
EATON/Powerware.

- Erik


-Original Message-
From: Seth Mattinen [mailto:se...@rollernet.us] 
Sent: Tuesday, November 13, 2012 1:59 PM
To: nanog@nanog.org
Subject: Eaton 9130 UPS feedback

Does anyone use Eaton 9130 series UPS for anything? I'm curious how
they've worked out for you.

I bought a 700VA model to give it a whirl versus the traditional APC
since the Eaton is an online type with static bypass and also does some
high efficiency thing where it normally stays on bypass, but the first
thing it did on the bench was have the inverter/rectifier or bypass
section catch on fire and destroy itself.

~Seth

Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.

[Suresh Ramasubramanian]

On Wed, Nov 14, 2012 at 6:40 PM, Ben S. Butler wrote:

>
> 3> Don't use filters, generate it from an IRR?
>
> Given there is no "right" answer what is considered to be the best fit one?


This sounds like your best bet.  Assuming you can find an IRR with
comprehensive enough coverage.

The other option is of course "don't filter based solely on RIR minimum
assignments" ..

I know at least some ISPs (like swisscom) do this for v4 too, but that
simply means people who try to multihome with anything less than a /19  in
level3 land aren't going to succeed.

http://v-authoring.ip-plus.net/documents/BIS_TI_Router_Filter_Policy_EN.pdf

ip prefix-list martians seq 8000 permit 8.0.0.0/7 le 19
[etc]

Not so much of a problem in v4 but as you saw for yourself, you risk not
seeing prefixes at all if you try this.

-- 
Suresh Ramasubramanian (ops.li...@gmail.com)

What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.

[Ben S. Butler]

Hi,

I am hoping for a bit of advice.  We are rolling out IPv6 en mass now to peers 
and I am finding that our "strict" IPv6 ingress prefix filter is meaning a lot 
of peers are sending me zero prefixes.  Upon investigation I determine they 
have de-agregrated their /32 for routing reasons / non interconnected islands 
of address space and in consequence advertise no covering /32 route.  The RIR 
block that the allocation is from is meant to have a minimum assignment of /32.

From:

http://www.space.net/~gert/RIPE/ipv6-filters.html

We get:

ipv6 prefix-list ipv6-ebgp-strict deny   3ffe::/16 le 128
ipv6 prefix-list ipv6-ebgp-strict permit 2001:500::/30 ge 48 le 48
ipv6 prefix-list ipv6-ebgp-strict deny   2001:db8::/32 le 128
ipv6 prefix-list ipv6-ebgp-strict permit 2001::/32
ipv6 prefix-list ipv6-ebgp-strict permit 2001::/16 ge 35 le 35
ipv6 prefix-list ipv6-ebgp-strict permit 2001::/16 ge 19 le 32
ipv6 prefix-list ipv6-ebgp-strict permit 2001:0678::/29 le 48
ipv6 prefix-list ipv6-ebgp-strict permit 2001:0c00::/23 ge 48 le 48
ipv6 prefix-list ipv6-ebgp-strict permit 2001:13c7:6000::/36 le 48
ipv6 prefix-list ipv6-ebgp-strict permit 2001:13c7:7000::/36 le 48
ipv6 prefix-list ipv6-ebgp-strict permit 2001:43f8::/29 ge 40 le 48
ipv6 prefix-list ipv6-ebgp-strict permit 2002::/16
ipv6 prefix-list ipv6-ebgp-strict permit 2003::/16 ge 19 le 32
ipv6 prefix-list ipv6-ebgp-strict permit 2400::/12 ge 19 le 32
ipv6 prefix-list ipv6-ebgp-strict permit 2600::/12 ge 19 le 32
ipv6 prefix-list ipv6-ebgp-strict permit 2610::/23 ge 24 le 32
ipv6 prefix-list ipv6-ebgp-strict permit 2620::/23 ge 40 le 48
ipv6 prefix-list ipv6-ebgp-strict permit 2800::/12 ge 19 le 32
ipv6 prefix-list ipv6-ebgp-strict permit 2a00::/12 ge 19 le 32
ipv6 prefix-list ipv6-ebgp-strict permit 2801:::/24 le 48
ipv6 prefix-list ipv6-ebgp-strict permit 2c00::/12 ge 19 le 32
ipv6 prefix-list ipv6-ebgp-strict deny 0::/0 le 128

I have peers in 2a00::/12 that are advertising me /48s without the /32 assigned 
to them.

While this has been a problem in IPv4 land in the past with some people 
de-aggregating a /19 to regional /24s with no covering route because of no 
backbone.  What should we be doing in IPv6 land as I suspect this may become a 
bigger problem than it ever was in IPv4.

I can adopt the view, well you should, so I'm going to filter, and they can say 
well that's not practical, we have a /32 and we advertise a /48 at each 
individual internet exchange.  RIRs policy wont allocate us a lot of separate 
/48s from an appropriate block.  Aggregation argues you shouldn't de-aggregate.

We might as well start off as we mean to go along and try not to pollute the v6 
route table with all the rubbish that is in the v4 one.

So what is the "best" answer.


1> Don't advertise islands of space under assignment minimum, without 
providing a covering aggregate route?

2> Don't use strict filters, they don't work well and de-agragegation with 
IPv6 is going to be a problem?

3> Don't use filters, generate it from an IRR?

Given there is no "right" answer what is considered to be the best fit one?

Kind Regards

Ben