Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment

[Randy Bush]

> Then usage of the 100.64/10  shared space may be applicable,  under
> other conditions it may be risky

about as risky as the rest of private address space.

randy

Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment

[Eric Germann]

Mulling over the implications of this.

[root@ip-100-64-0-55 ~]# traceroute s3.amazonaws.com
traceroute to s3.amazonaws.com (54.231.0.64), 30 hops max, 60 byte packets
 1  ec2-79-125-0-202.eu-west-1.compute.amazonaws.com (79.125.0.202)  1.068 ms  
0.824 ms  0.787 ms
 2  178.236.1.18 (178.236.1.18)  1.193 ms  1.164 ms  0.869 ms
 3  * * *
 4  54.239.41.133 (54.239.41.133)  76.046 ms  76.029 ms  75.986 ms
 5  54.239.41.166 (54.239.41.166)  76.314 ms  76.281 ms  76.244 ms
 6  72.21.220.77 (72.21.220.77)  76.143 ms  76.054 ms  76.095 ms
 7  205.251.245.224 (205.251.245.224)  76.346 ms 72.21.222.149 (72.21.222.149)  
76.261 ms 205.251.245.230 (205.251.245.230)  76.360 ms
 8  * * *
...
30  * * *

but, 

[root@ip-100-64-0-55 ~]# wget https://s3.amazonaws.com
--2015-02-24 04:20:18--  https://s3.amazonaws.com/
Resolving s3.amazonaws.com... 54.231.12.48
Connecting to s3.amazonaws.com|54.231.12.48|:443... connected.
HTTP request sent, awaiting response... 307 Temporary Redirect
Location: http://aws.amazon.com/s3/ [following]
--2015-02-24 04:20:18--  http://aws.amazon.com/s3/
Resolving aws.amazon.com... 54.240.250.195
Connecting to aws.amazon.com|54.240.250.195|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: “index.html.1”

[<=>
] 179,606  158K/s   in 1.1s

2015-02-24 04:20:20 (158 KB/s) - “index.html.1” saved [179606]

ICMP would break from the intermediates, but ICMP from the API endpoint should 
still work.  Will have to chew on this a bit overnight.

EKG


> On Feb 23, 2015, at 9:03 PM, Blair Trosper  wrote:
> 
> Might be ill-advised since AWS uses it themselves for their internal 
> networking.  Just traceroute to any API endpoint from an EC2/VPC resource or 
> instance.  :)
> 
> On Mon, Feb 23, 2015 at 2:43 PM, Måns Nilsson  > wrote:
> Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC 
> deployment Date: Mon, Feb 23, 2015 at 10:02:44AM -0500 Quoting Eric Germann 
> (ekgerm...@cctec.com ):
> > Currently engaged on a project where they’re building out a VPC 
> > infrastructure for hosted applications.
> 
> 
> 
> > Thoughts and thanks in advance.
> 
> using the wasted /10 for this is pretty much equal to using RFC1918 space.
> 
> IPv6 was invented to do this right.
> 
> --
> Måns Nilsson primary/secondary/besserwisser/machina
> MN-1334-RIPE +46 705 989668 
> 
> It's NO USE ... I've gone to "CLUB MED"!!
> 

Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment

[Jimmy Hess]

On Mon, Feb 23, 2015 at 9:02 AM, Eric Germann  wrote:

> In spitballing, the boat hasn’t sailed too far to say “Why not use 100.64/10 
> in the VPC?”

Read RFC6598.
If you can assure the conditions are met that are listed in 4.
Use of Shared CGN Space..

Then usage of the 100.64/10  shared space may be applicable,  under
other conditions it may be risky;   the proper usage of IP addresses
is in accordance with the standards or by the registrant under the
right assignment agreements.

If you are just needing space to squat on regardless of the
standardized usage,  then you might do anything you want ---  you may
as well use 25/8  or  11.0.0.0/8  internally,   after taking steps to
ensure you will not be leaking Reverse DNS queries, routes,  or
anything like that,  this space is larger than a /10 and would provide
more expansion flexibility.


> Then, the customer would be allocated a /28 or larger (depending on needs) to 
> NAT on their side and NAT it once.  After that, no more NAT for the VPC and 
> it boils down to firewall rules.  Their device needs to NAT outbound before 
> it fires it down the tunnel which pfSense and ASA’s appear to be able to do.
>

--
-JH

Re: AOL Postmaster

[Fred]

Having exactly the same issue. Also never received any response from 
AOL. Quite annoying.


John Zettlemoyer:

No, started using an IP address that hasn’t been used since we got the range 
from Arin, and got this - 554- (RTR:BL)
Tried to contact AOL through normal channels, and no response in over a week.  
Feedback loop has been in place for years, and we check it every day (its 
clean).

John Zettlemoyer


From: Bill Patterson [mailto:billpatterso...@gmail.com]
Sent: Monday, February 23, 2015 3:46 PM
To: John Zettlemoyer
Cc: nanog@nanog.org
Subject: Re: AOL Postmaster

Did you suddenly start getting "AOL will not accept delivery of this message" 
bounce backs?
On Feb 23, 2015 3:30 PM, "John Zettlemoyer"  wrote:
Could someone from AOL who deals with the email systems please contact me 
off-list.
Thank you.

John Zettlemoyer
WCiT LLC
856.310.1375 x221
j...@wcit.net

Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment

[Blair Trosper]

Might be ill-advised since AWS uses it themselves for their internal
networking.  Just traceroute to any API endpoint from an EC2/VPC resource
or instance.  :)

On Mon, Feb 23, 2015 at 2:43 PM, Måns Nilsson 
wrote:

> Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC
> deployment Date: Mon, Feb 23, 2015 at 10:02:44AM -0500 Quoting Eric Germann
> (ekgerm...@cctec.com):
> > Currently engaged on a project where they’re building out a VPC
> infrastructure for hosted applications.
>
> 
>
> > Thoughts and thanks in advance.
>
> using the wasted /10 for this is pretty much equal to using RFC1918 space.
>
> IPv6 was invented to do this right.
>
> --
> Måns Nilsson primary/secondary/besserwisser/machina
> MN-1334-RIPE +46 705 989668
> It's NO USE ... I've gone to "CLUB MED"!!
>

Re: v6 deagg

[William Herrin]

On Mon, Feb 23, 2015 at 1:33 PM, Randy Bush  wrote:
> you might find http://www.route-aggregation.net/ interesting

Hi Randy,

I found it very interesting. Wish I'd noticed when it was fresh.

I don't fully understand the math yet but the algorithm doesn't smell
right. As near as I can figure it may only be correct in a static
system. If after convergence the disaggregate ceases to be reachable
from the aggregate, there doesn't appear to be either enough
information in the system or enough triggers traveling between routers
for it to reconverge to a correct state.

Deriving only from the information available to each router at each
step, look at page 58 in the presentation and see if you can figure
out what happens to the network in that start state when the link
between u7 and u9 drops. Remember that all the slashed half-moons mean
that the router in that position does not relay the disaggregate and,
in most cases, does not know that the disaggregate exists.

I've emailed the authors and asked them to clarify. I hope I'm wrong.
I'm tried of being a killjoy on this sort of thing and it would be
truly cool if it turns out they've cracked the problem.

Regardless, if we could presume (with support from the registries)
that disaggregates are always reachable from the aggregate (always TE,
never downstream customers or discrete sites) and everybody with an
address block was courteous enough to advertise an aggregate then it
might be usable to control IPv6 deagg. Actually, as long as we could
assume the first part we could probably have routers synthesize
aggregates to cover the second. But without the first assumption it
looks dysfunctional.

I discussed the cutouts problem in my 2010 presentation to ARIN XXVI in Atlanta:
https://bill.herrin.us/network/201010-cutouts.pdf

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

RE: AOL Postmaster

[Bill Patterson]

Ok, it took 21 days from the time I opened a ticket with them last month
for them to respond to me. I ended up having to have our ISP update our
rDNS. Not sure if it's something similar for you but I felt the same way
after a week of waiting for a response from them.
On Feb 23, 2015 3:56 PM, "John Zettlemoyer"  wrote:

> No, started using an IP address that hasn’t been used since we got the
> range from Arin, and got this - 554- (RTR:BL)
>
> Tried to contact AOL through normal channels, and no response in over a
> week.  Feedback loop has been in place for years, and we check it every day
> (its clean).
>
>
>
> John Zettlemoyer
>
>
>
> *From:* Bill Patterson [mailto:billpatterso...@gmail.com]
> *Sent:* Monday, February 23, 2015 3:46 PM
> *To:* John Zettlemoyer
> *Cc:* nanog@nanog.org
> *Subject:* Re: AOL Postmaster
>
>
>
> Did you suddenly start getting "AOL will not accept delivery of this
> message" bounce backs?
>
> On Feb 23, 2015 3:30 PM, "John Zettlemoyer"  wrote:
>
> Could someone from AOL who deals with the email systems please contact me
> off-list.
> Thank you.
>
> John Zettlemoyer
> WCiT LLC
> 856.310.1375 x221
> j...@wcit.net
>

RE: AOL Postmaster

[John Zettlemoyer]

No, started using an IP address that hasn’t been used since we got the range 
from Arin, and got this - 554- (RTR:BL)
Tried to contact AOL through normal channels, and no response in over a week.  
Feedback loop has been in place for years, and we check it every day (its 
clean).
 
John Zettlemoyer 

 
From: Bill Patterson [mailto:billpatterso...@gmail.com] 
Sent: Monday, February 23, 2015 3:46 PM
To: John Zettlemoyer
Cc: nanog@nanog.org
Subject: Re: AOL Postmaster
 
Did you suddenly start getting "AOL will not accept delivery of this message" 
bounce backs?
On Feb 23, 2015 3:30 PM, "John Zettlemoyer"  wrote:
Could someone from AOL who deals with the email systems please contact me 
off-list.
Thank you.

John Zettlemoyer
WCiT LLC
856.310.1375 x221
j...@wcit.net

Re: AOL Postmaster

[Bill Patterson]

Did you suddenly start getting "AOL will not accept delivery of this
message" bounce backs?
On Feb 23, 2015 3:30 PM, "John Zettlemoyer"  wrote:

> Could someone from AOL who deals with the email systems please contact me
> off-list.
> Thank you.
>
> John Zettlemoyer
> WCiT LLC
> 856.310.1375 x221
> j...@wcit.net
>

Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment

[Måns Nilsson]

Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment 
Date: Mon, Feb 23, 2015 at 10:02:44AM -0500 Quoting Eric Germann 
(ekgerm...@cctec.com):
> Currently engaged on a project where they’re building out a VPC 
> infrastructure for hosted applications.



> Thoughts and thanks in advance.

using the wasted /10 for this is pretty much equal to using RFC1918 space. 

IPv6 was invented to do this right. 

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
It's NO USE ... I've gone to "CLUB MED"!!


signature.asc
Description: Digital signature

AOL Postmaster

[John Zettlemoyer]

Could someone from AOL who deals with the email systems please contact me 
off-list.
Thank you.
 
John Zettlemoyer 
WCiT LLC
856.310.1375 x221
j...@wcit.net

Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment

[Benson Schliesser]

Hi, Eric -

Bill already described the salient points. The "transition" space is 
meant to be used for cases where there are multiple stacked NATs, such 
as CGN with CPE-based NAT. In theory, if the NAT implementations support 
it, one could use it repeatedly by stacking NAT on top of NAT ad 
nauseum, but the wisdom of doing so is questionable. If one uses it like 
additional RFC1918 space then routing could become more difficult, 
specifically in the case where hosts (e.g. VPC servers) are numbered 
with it. This is true because, in theory, you don't need the transition 
space to be routed on the "internal" network which avoids having NAT 
devices hold conflicting routes etc. Even if the edge NAT devices don't 
currently see conflicting routes to 100.64/10, if that changes in the 
future then client hosts may find themselves unable to reach the VPC 
hosts at that time.


That being said, if you understand the risks that I described above, 
then it may work well for a "community of interest" type of 
inter-network that hosts non-global resources. From your description it 
sounds like that might be the situation you find yourself in. To be 
clear, it's not unwise to do so, but it does carry risk that needs to be 
evaluated (and documented).


Cheers,
-Benson



William Herrin 
February 23, 2015 at 12:58 PM

Hi Eric,

The main risk is more or less as you summarized it. Customer has no
firewall or originates the VPN directly from their firewall. Customer
buys a non-hosting commodity Internet product that uses carrier NAT to
conserve IP addresses. The customer's assigned address AND NETMASK
combined overlap some of the hosts you're trying to publish to them.



Mitigations for that risk:

Can you insist that the customer originate connections from inside
their firewall (on RFC1918 space)?

Most service providers using 100.64/10 either permit customers to opt
out (getting dynamic globally routable addresses) or offer customers
the opportunity to purchase static global addresses for a nominal fee.
Are you comfortable telling impacted customers that they have to do
so?


A secondary risk comes in to play where a customer may wish to
interact with another service provider doing the same thing as you.
That essentially lands you back in the same problem you're having now
with RFC1918.


One more question you should consider: what is the nature of your
customer's networks? Big corps that tend to stretch through 10/8 won't
let their users originate VPN connections in the first place. They
also don't touch 100.64/10 except where someone is publishing a
service like yours. Meanwhile, home and SOHO users who are at liberty
to originate VPNs might currently hold a 100.64/10 address. But they
just about never use the off-bit /16s in 10/8. By off-bit I mean the
ones with 4 or 5 random 1-bits in the second octet.


My opinion: The likelihood of collisions in 100.64/10 increases
significantly if you use them on servers. I would confine my use to
client machines and try to put servers providing service to multiple
organizations on globally unique IPs. Confining 100.64/10 to client
machines, you're unlikely to encounter a problem you can't readily
solve.

Regards,
Bill Herrin


Eric Germann 
February 23, 2015 at 10:02 AM
Currently engaged on a project where they’re building out a VPC 
infrastructure for hosted applications.


Users access apps in the VPC, not the other direction.

The issue I'm trying to get around is the customers who need to 
connect have multiple overlapping RFC1918 space (including overlapping 
what was proposed for the VPC networks). Finding a hole that is big 
enough and not in use by someone else is nearly impossible AND the 
customers could go through mergers which make them renumber even more 
in to overlapping 1918 space.


Initially, I was looking at doing something like (example IP’s):


Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to DC 
<——> NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24)


Classic overlapping subnets on both ends with allocations out of 
100.64.0.0/10 to NAT in both directions. Each sees the other end in 
100.64 space, but the mappings can get tricky and hard to keep track 
of (especially if you’re not a network engineer).



In spitballing, the boat hasn’t sailed too far to say “Why not use 
100.64/10 in the VPC?”


Then, the customer would be allocated a /28 or larger (depending on 
needs) to NAT on their side and NAT it once. After that, no more NAT 
for the VPC and it boils down to firewall rules. Their device needs to 
NAT outbound before it fires it down the tunnel which pfSense and 
ASA’s appear to be able to do.


I prototyped this up over the weekend with multiple VPC’s in multiple 
regions and it “appears” to work fine.


From the operator community, what are the downsides?

Customers are businesses on dedicated business services vs. consumer 
cable modems (although there are a few on busines

Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment

[Luan Nguyen]

I put lots of these to good use
http://en.wikipedia.org/wiki/Reserved_IP_addresses
Regarding public cloud with ipv6 support, contact me off-list i might even
get you a special discount



On Mon, Feb 23, 2015 at 10:52 AM, Ca By  wrote:

> On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann  wrote:
>
> > Currently engaged on a project where they’re building out a VPC
> > infrastructure for hosted applications.
> >
> > Users access apps in the VPC, not the other direction.
> >
> > The issue I'm trying to get around is the customers who need to connect
> > have multiple overlapping RFC1918 space (including overlapping what was
> > proposed for the VPC networks).  Finding a hole that is big enough and
> not
> > in use by someone else is nearly impossible AND the customers could go
> > through mergers which make them renumber even more in to overlapping 1918
> > space.
> >
> > Initially, I was looking at doing something like (example IP’s):
> >
> >
> > Customer A (172.28.0.0/24)  <—> NAT to 100.127.0.0/28 <——> VPN to DC
> <——>
> > NAT from 100.64.0.0/18 <——>  VPC Space (was 172.28.0.0/24)
> >
> > Classic overlapping subnets on both ends with allocations out of
> > 100.64.0.0/10 to NAT in both directions.  Each sees the other end in
> > 100.64 space, but the mappings can get tricky and hard to keep track of
> > (especially if you’re not a network engineer).
> >
> >
> > In spitballing, the boat hasn’t sailed too far to say “Why not use
> > 100.64/10 in the VPC?”
> >
> > Then, the customer would be allocated a /28 or larger (depending on
> needs)
> > to NAT on their side and NAT it once.  After that, no more NAT for the
> VPC
> > and it boils down to firewall rules.  Their device needs to NAT outbound
> > before it fires it down the tunnel which pfSense and ASA’s appear to be
> > able to do.
> >
> > I prototyped this up over the weekend with multiple VPC’s in multiple
> > regions and it “appears” to work fine.
> >
> > From the operator community, what are the downsides?
> >
> > Customers are businesses on dedicated business services vs. consumer
> cable
> > modems (although there are a few on business class cable).  Others are on
> > MPLS and I’m hashing that out.
> >
> > The only one I can see is if the customer has a service provider with
> > their external interface in 100.64 space.  However, this approach would
> > have a more specific in that space so it should fire it down the tunnel
> for
> > their allocated customer block (/28) vs. their external side.
> >
> > Thoughts and thanks in advance.
> >
> > Eric
> >
>
> Wouldn't it be nice if Amazon supported IPv6 in VPC?
>
> I have disqualified several projects from using the "public cloud" and put
> them in the on-premise "private cloud"  because Amazon is missing this key
> scaling feature -- ipv6.   It is odd that Amazon, a company with scale
> deeply in its DNA, fails so hard on IPv6.  I guess they have a lot of
> brittle technical debt they can't upgrade.
>
> I suggest you go with private cloud if possible.
>
> Or, you can double NAT non-unique IPv4 space.
>
> Regarding 100.64.0.0/10, despite what the RFCs may say, this space is just
> an augment of RFC1918 and i have already deployed it as such.
>
> CB
>

Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment

[William Herrin]

On Mon, Feb 23, 2015 at 10:02 AM, Eric Germann  wrote:
> In spitballing, the boat hasn't sailed too far to say "Why not
> use 100.64/10 in the VPC?"
>
> The only one I can see is if the customer has a service provider
> with their external interface in 100.64 space.  However, this
> approach would have a more specific in that space so it
> should fire it down the tunnel for their allocated customer
> block (/28) vs. their external side.

Hi Eric,

The main risk is more or less as you summarized it.  Customer has no
firewall or originates the VPN directly from their firewall. Customer
buys a non-hosting commodity Internet product that uses carrier NAT to
conserve IP addresses. The customer's assigned address AND NETMASK
combined overlap some of the hosts you're trying to publish to them.



Mitigations for that risk:

Can you insist that the customer originate connections from inside
their firewall (on RFC1918 space)?

Most service providers using 100.64/10 either permit customers to opt
out (getting dynamic globally routable addresses) or offer customers
the opportunity to purchase static global addresses for a nominal fee.
Are you comfortable telling impacted customers that they have to do
so?


A secondary risk comes in to play where a customer may wish to
interact with another service provider doing the same thing as you.
That essentially lands you back in the same problem you're having now
with RFC1918.


One more question you should consider: what is the nature of your
customer's networks? Big corps that tend to stretch through 10/8 won't
let their users originate VPN connections in the first place. They
also don't touch 100.64/10 except where someone is publishing a
service like yours.  Meanwhile, home and SOHO users who are at liberty
to originate VPNs might currently hold a 100.64/10 address. But they
just about never use the off-bit /16s in 10/8. By off-bit I mean the
ones with 4 or 5 random 1-bits in the second octet.


My opinion: The likelihood of collisions in 100.64/10 increases
significantly if you use them on servers. I would confine my use to
client machines and try to put servers providing service to multiple
organizations on globally unique IPs. Confining 100.64/10 to client
machines, you're unlikely to encounter a problem you can't readily
solve.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: What would you do about questionable domain pointing A record to your IP address?

[Anne P. Mitchell, Esq.]

Thank you, everyone, for all of the responses, both on and offlist!

Anne

Anne P. Mitchell, Esq.
CEO/President
ISIPP SuretyMail Email Reputation, Accreditation & Certification
Your mail system + SuretyMail accreditation = delivered to their inbox!
http://www.SuretyMail.com/
http://www.SuretyMail.eu/

Author: Section 6 of the Federal CAN-SPAM Act of 2003
Member, California Bar Cyberspace Law Committee
Ret. Professor of Law, Lincoln Law School of San Jose
303-731-2121 | amitch...@isipp.com | @AnnePMitchell | Facebook/AnnePMitchell 

Re: Comcast Support (from NANOG Digest, Vol 84, Issue 23)

[Livingood, Jason]

FWIW, if you phone support you generally end up with a tier-1 person. In cases 
where people have more technical background, you may want to try things that 
land in more senior levels of Care (or even get checked by engineering 
directly) such as:

- Customer support forums: http://forums.comcast.com/comcastsupport/
- Twitter: @ComcastCares https://twitter.com/comcastcares
- Broadband Reports forum: http://www.dslreports.com/forum/comcast
- Reddit: http://www.reddit.com/r/comcast

- Jason

On 2/23/15, 1:25 AM, "Peter Loron" 
mailto:pet...@standingwave.org>> wrote:

Apologies for a bit off topic, but I’m trying to get an issue resolved and am 
having trouble reaching anybody who seems clue positive

Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment

[Ca By]

On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann  wrote:

> Currently engaged on a project where they’re building out a VPC
> infrastructure for hosted applications.
>
> Users access apps in the VPC, not the other direction.
>
> The issue I'm trying to get around is the customers who need to connect
> have multiple overlapping RFC1918 space (including overlapping what was
> proposed for the VPC networks).  Finding a hole that is big enough and not
> in use by someone else is nearly impossible AND the customers could go
> through mergers which make them renumber even more in to overlapping 1918
> space.
>
> Initially, I was looking at doing something like (example IP’s):
>
>
> Customer A (172.28.0.0/24)  <—> NAT to 100.127.0.0/28 <——> VPN to DC <——>
> NAT from 100.64.0.0/18 <——>  VPC Space (was 172.28.0.0/24)
>
> Classic overlapping subnets on both ends with allocations out of
> 100.64.0.0/10 to NAT in both directions.  Each sees the other end in
> 100.64 space, but the mappings can get tricky and hard to keep track of
> (especially if you’re not a network engineer).
>
>
> In spitballing, the boat hasn’t sailed too far to say “Why not use
> 100.64/10 in the VPC?”
>
> Then, the customer would be allocated a /28 or larger (depending on needs)
> to NAT on their side and NAT it once.  After that, no more NAT for the VPC
> and it boils down to firewall rules.  Their device needs to NAT outbound
> before it fires it down the tunnel which pfSense and ASA’s appear to be
> able to do.
>
> I prototyped this up over the weekend with multiple VPC’s in multiple
> regions and it “appears” to work fine.
>
> From the operator community, what are the downsides?
>
> Customers are businesses on dedicated business services vs. consumer cable
> modems (although there are a few on business class cable).  Others are on
> MPLS and I’m hashing that out.
>
> The only one I can see is if the customer has a service provider with
> their external interface in 100.64 space.  However, this approach would
> have a more specific in that space so it should fire it down the tunnel for
> their allocated customer block (/28) vs. their external side.
>
> Thoughts and thanks in advance.
>
> Eric
>

Wouldn't it be nice if Amazon supported IPv6 in VPC?

I have disqualified several projects from using the "public cloud" and put
them in the on-premise "private cloud"  because Amazon is missing this key
scaling feature -- ipv6.   It is odd that Amazon, a company with scale
deeply in its DNA, fails so hard on IPv6.  I guess they have a lot of
brittle technical debt they can't upgrade.

I suggest you go with private cloud if possible.

Or, you can double NAT non-unique IPv4 space.

Regarding 100.64.0.0/10, despite what the RFCs may say, this space is just
an augment of RFC1918 and i have already deployed it as such.

CB

Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment

[Eric Germann]

Currently engaged on a project where they’re building out a VPC infrastructure 
for hosted applications.

Users access apps in the VPC, not the other direction.

The issue I'm trying to get around is the customers who need to connect have 
multiple overlapping RFC1918 space (including overlapping what was proposed for 
the VPC networks).  Finding a hole that is big enough and not in use by someone 
else is nearly impossible AND the customers could go through mergers which make 
them renumber even more in to overlapping 1918 space.

Initially, I was looking at doing something like (example IP’s):


Customer A (172.28.0.0/24)  <—> NAT to 100.127.0.0/28 <——> VPN to DC <——> NAT 
from 100.64.0.0/18 <——>  VPC Space (was 172.28.0.0/24)

Classic overlapping subnets on both ends with allocations out of 100.64.0.0/10 
to NAT in both directions.  Each sees the other end in 100.64 space, but the 
mappings can get tricky and hard to keep track of (especially if you’re not a 
network engineer).


In spitballing, the boat hasn’t sailed too far to say “Why not use 100.64/10 in 
the VPC?”

Then, the customer would be allocated a /28 or larger (depending on needs) to 
NAT on their side and NAT it once.  After that, no more NAT for the VPC and it 
boils down to firewall rules.  Their device needs to NAT outbound before it 
fires it down the tunnel which pfSense and ASA’s appear to be able to do.

I prototyped this up over the weekend with multiple VPC’s in multiple regions 
and it “appears” to work fine.

From the operator community, what are the downsides?

Customers are businesses on dedicated business services vs. consumer cable 
modems (although there are a few on business class cable).  Others are on MPLS 
and I’m hashing that out.

The only one I can see is if the customer has a service provider with their 
external interface in 100.64 space.  However, this approach would have a more 
specific in that space so it should fire it down the tunnel for their allocated 
customer block (/28) vs. their external side.  

Thoughts and thanks in advance.

Eric

Re: Comcast Support (from NANOG Digest, Vol 84, Issue 23)

[McElearney, Kevin]

You forgot to use the word “Shibboleet” when you called care.  Contacted
Peter off-list


- Kevin

On 2/23/15, 1:25 AM, "Peter Loron"  wrote:

>Apologies for a bit off topic, but I’m trying to get an issue resolved
>and am having trouble reaching anybody who seems clue positive.
>
>From home via Comcast cable, I’m having trouble reaching some
>destinations. According to mtr, there is a particular node
>(be-11-pe02.11greatoaks.ca.ibone.comcast.net) which is suffering > 30%
>loss. Contacting the Comcast consumer support folks is useless (what are
>the lights on your modem doing? Did you power cycle it?). When this is
>happening, I usually am told they need to send a tech to my house.
>.
>
>Is there a way to drop a note to the NOC or other folks who would
>understand the info and be able to act on it?
>
>Thanks!
>
>-Pete
>> On Jan 23, 2015, at 09:14, Brzozowski, John
>> wrote:
>> 
>> Folks,
>> 
>> The thread below was sent to me a few times, apologies for not catching
>>it sooner.
>> 
>> Janet,
>> 
>> I sent you mail unicast with a request for some information.  I am
>>happy to help you out.
>> 
>> For the larger NANOG audience, Comcast has recently launched IPv6
>>support for our BCI products, these are our DOCSIS based commercial
>>offerings.  This means that if you gateway device is in fact in RG mode
>>you will be delegated a dynamic IPv6 prefix, by default customers are
>>delegated a /56 prefix along with a single IPv6 address that is assigned
>>to the WAN of the gateway device.  IPv6 support applies to the following
>>makes and models:
>> 
>> SMC D3G CCR (http://mydeviceinfo.comcast.net/device.php?devid=216)
>> Cisco BWG (http://mydeviceinfo.comcast.net/device.php?devid=347)
>> Netgear CG3000D (http://mydeviceinfo.comcast.net/device.php?devid=347)
>> 
>> For customers where you bring your own cable modem or have one of the
>>above in bridge mode we have enabled IPv6 support for you as well.
>>However, your router behind the modem must be running software and
>>configured with IPv6 support.  Specifically, your router needs to be
>>support stateful DHCPv6 for IPv6 address and prefix acquisition.  We
>>have received a number of reports from customers that the Juniper SRX
>>does not appear to properly support IPv6.  We are working with Juniper
>>and also recommend that you reach out to Juniper as well.
>> 
>> Please keep checking http://www.comcast6.net for updates, we will post
>>some additional information here in the next week or so.  In the mean
>>time if you have questions feel free to send me mail or post them here
>>on the NANOG list.
>> 
>> HTH,
>> 
>> John
>> =
>> John Jason Brzozowski
>> Comcast Cable
>> p) 484-962-0060
>> w) www.comcast6.net
>> e) john_brzozow...@cable.comcast.com
>> =
>> 
>> 
>> 
>> -Original Message-
>> From: "nanog-requ...@nanog.org"
>>mailto:nanog-requ...@nanog.org>>
>> Reply-To: NANOG mailto:nanog@nanog.org>>
>> Date: Friday, January 23, 2015 at 07:00
>> To: NANOG mailto:nanog@nanog.org>>
>> Subject: NANOG Digest, Vol 84, Issue 23
>> 
>> Date: Thu, 22 Jan 2015 22:42:17 +
>> From: Janet Sullivan mailto:jan...@nairial.net>>
>> To: "'nanog@nanog.org'"
>>mailto:nanog@nanog.org>>
>> Subject: Comcast Support
>> Message-ID:
>> 
>>>utlook.com>4.namprd07.prod.outlook.com>>
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> I hate to use NANOG for this, but support has now ended a chat with me
>>twice without fixing anything, they just kicked me off.
>> 
>> I'm not getting an IPv6 address on the Comcast provided cable
>>modem/router.  I'm not getting a PD.  My machines thus have no IPv6.
>>I've hard reset my router 4 times while working with Comcast, and I've
>>been told to do things like switch to a static IPv4 address, which shows
>>a level of clue that is scary.  And before that they were convinced it
>>was a wireless problem even though I have a wired connection, and told
>>them that multiple times.  I've wasted two hours with Comcast today, and
>>even when I asked for escalation I got nothing.  Just hung up on.  It's
>>honestly the worst customer support I've ever received.  I don't think I
>>ever got them to understand the difference between IPv4 and IPv6.
>
>

Re: v6 deagg

[Marco d'Itri]

On Feb 20, Saku Ytti  wrote:

> Is deaggregation inherently undesirable? In some RIR LIR will not get new
No. Excessive deaggregation is undesirable, but we lack a method to teach
routers to enforce this subtlety and maybe also a wide agreement on what 
is excessive.

> allocation, just because LIR lacks INET connectivity between their datacenter
> or pop.
> This wasn't issue in IPv4, because you actually could reasonably fill your
> IPv4 allocation and were eligible for another allocation for your
> discontinuous locations.
But at least in the RIPE region this can be easily solved by 
deaggregating /32s out of your /29.

-- 
ciao,
Marco


pgpMElo4U_R7A.pgp
Description: PGP signature