Re: any interesting/useful resources available to IPv6 only?

[Pshem Kowalczyk]

I've found a VPS provider (https://www.vultr.com/pricing/) that offers
cheaper instances with IPv6 only. I suspect that there might be others, as
ultimately those sort of services can't really escape the issue by using
NAT.

kind regards
Pshem


On Sat, 4 May 2019 at 03:15, Brian J. Murrell  wrote:

> Hi,
>
> I am trying to make a case (to old fuddy-duddies, which is why I even
> need to actually make a case) for IPv6 for my own selfish reasons.  :-)
>
> I wonder if anyone has any references to interesting/useful/otherwise
> resources on are only available to IPv6 users that they can forward to
> me.
>
> Cheers,
> b.
>
>

Re: CGNAT

[Pshem Kowalczyk]

I can confirm that percentage (at least with residential customer base).
All big content providers and a number of CDNs will do IPv6 by default. One
thing that will heavily affect this is the CPE equipment (which might not
have IPv6 enabled or even be capable of it).

kind regards
Pshem


On Sat, 8 Apr 2017 at 06:19 Mikael Abrahamsson  wrote:

> On Fri, 7 Apr 2017, Max Tulyev wrote:
>
> > BTW, does somebody check how implementing a native IPv6 decrease actual
> > load of CGNAT?
>
> Reports are that 30-50% of traffic will be IPv6 when you enable dual
> stack. This would be traffic that will not traverse your CGNAT.
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
>

Re: Use of unique local IPv6 addressing rfc4193

[Pshem Kowalczyk]

Hi,

That's why I asked the question - if anyone actually puts its as an
additional IP on their interfaces to keep it simple (and in-line with IPv4
policies, address allocation schemes, etc) or not. I can see the argument
both ways - if we decide to use it we'll have to either overlay it with
public IPv6 space (and provide the NAT/proxy for where we don't have any
public IPv6 assigned)  or simply not use the fc00::/7 and skip the
NAT/proxy aspects of it.
So one way it's aligned with what we do already (at the cost of the
overhead) the other it's not aligned (but with potentially less overhead).

kind regards
Pshem


On Fri, 9 Sep 2016 at 11:27 Mark Andrews <ma...@isc.org> wrote:

>
> In message <
> caeazirxu7dh9o9ewdjfiemgdu7dt4v62w5+9+ctj2-rqznp...@mail.gmail.com>,
> Pshem Kowalczyk writes:
> > With NAT I have a single entry/exit point to those infrastructure subnets
> > which can be easily policed.
> > If I give them public IPs then they're routable and potentially can reach
> > the internet via devices that don't police the traffic.
>
> If you wish to believe that, believe that, but it is only wishful
> thinking.
>
> > My real question is does anyone bother with the fc00::/7 addressing
> or do > you use your public space (and police that)?
>
> ULA is normally used in parallel with public addressing if it is
> used.  IPv6 was designed to be deployed with multiple address and
> prefixes per interface.  When ULA is deployed you have ULA <-> ULA,
> non-ULA <-> non-ULA.  Non-privacy addresses for server functionality,
> privacy addresses for client functionality.
>
> Mark
>
> > kind regards
> > Pshem
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>

Re: Use of unique local IPv6 addressing rfc4193

[Pshem Kowalczyk]

With NAT I have a single entry/exit point to those infrastructure subnets
which can be easily policed.
If I give them public IPs then they're routable and potentially can reach
the internet via devices that don't police the traffic.

My real question is does anyone bother with the fc00::/7 addressing or do
you use your public space (and police that)?

kind regards
Pshem


On Fri, 9 Sep 2016 at 10:27 Mark Andrews <ma...@isc.org> wrote:

>
> In message <CAEaZiRU+wgQ0GDzxcmtqKO=_
> sasavsnx31q_70q+udm1oeo...@mail.gmail.com>, Pshem Kowalczyk writes:
> > Hi,
> >
> > We're looking at rolling out IPv6 to our internal DC infrastructure.
> Those
> > systems support only our internal network and in the IPv4 world they all
> > live in 'private' space of 10.0.0.0/8. I was wondering if anyone uses
> the
> > fc00::/7 space for these sort of things or do ppl use a bit of their
> public
> > IPv6 allocation and manage the security for those ranges?
> > I realise I'd have to use a proxy or NAT66 for the regular outbound
> > connectivity (but we do it already for IPv4 anyway). The truth is that
> even
> > if we do use something out of our public allocation we're likely to do
> the
> > same thing (just to be sure that nothing spills out accidentally).
> >
> > So what do you do in this space?
> >
> > kind regards
> > Pshem
>
> If you have a NAT you can't prevent things spilling out.  The ONLY
> way to prevent things spilling out is to not connect the network
> in any shape or form.
>
> All NAT does is make it harder to run your network and increases
> the cost of software development.
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>

Use of unique local IPv6 addressing rfc4193

[Pshem Kowalczyk]

Hi,

We're looking at rolling out IPv6 to our internal DC infrastructure. Those
systems support only our internal network and in the IPv4 world they all
live in 'private' space of 10.0.0.0/8. I was wondering if anyone uses the
fc00::/7 space for these sort of things or do ppl use a bit of their public
IPv6 allocation and manage the security for those ranges?
I realise I'd have to use a proxy or NAT66 for the regular outbound
connectivity (but we do it already for IPv4 anyway). The truth is that even
if we do use something out of our public allocation we're likely to do the
same thing (just to be sure that nothing spills out accidentally).

So what do you do in this space?

kind regards
Pshem

Re: Peering + Transit Circuits

[Pshem Kowalczyk]

It's actually quite easy.
Provider1 is present at Exchange1 and Exchange2, so is Provider2. Provider2
doesn't want to pay for the traffic between Exchange1 and Exchange2, so it
points a static route for all prefixes it has in Exchange2 via Provider1's
IP address in Exchange1 and does the same in Exchange2. Provider1's router
receives traffic, checks where it should go (Exchange2) and it forwards the
traffic. So the traffic flows like this:

Provider2 (Exchange1) - Provider1 - (Exchange2) Provider2, all due to
static routes.

kind regards
Pshem


On Wed, 19 Aug 2015 at 10:38 Faisal Imtiaz fai...@snappytelecom.net wrote:

 Let me start backwards...

 To me 'peering' is sharing internal routes and downstream customer
 routes,and not external ones.
 IP transit is all of the external routes including internal routes 
 downstream customer routes


 Having said that. if one is control of what IP Prefixes get advertised
 to whom... how exactly someone (peers) 'steal' transit ?
 (If one is not managing the filters well then yes it is possible, but that
 would be a configuration error ?)


 Maybe I am naive, to my Peering routes (relationships) are a subset of IP
 Transit Routes (relationships)

 Based on above belief...

 Then Item # 3, becomes the choice of the OP where one can make one of
 two starting assumptions... We will trust everything coming in and change
 what we don't like... or We will not trust anything coming in, and change
 (accept) what we like.

 Items # 1  2, would be a function of network design, technical
 requirements (maintenance window) etc etc.. easier to deal with a
 distributed edge vs all in one when one has to bring anything down for any
 reason..

 I am open to learning and being corrected if any of the above is wrong !


 Faisal Imtiaz
 Snappy Internet  Telecom

 - Original Message -
  From: Tim Durack tdur...@gmail.com
  To: cisco-...@puck.nether.net, nanog list nanog@nanog.org
  Sent: Tuesday, August 18, 2015 8:29:31 AM
  Subject: Peering + Transit Circuits

  Question: What is the preferred practice for separating peering and
 transit
  circuits?
 
  1. Terminate peering and transit on separate routers.
  2. Terminate peering and transit circuits in separate VRFs.
  3. QoS/QPPB (
 
 https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf
  )
  4. Don't worry about peers stealing transit.
  5. What is peering?
 
  Your comments are appreciated.
 
  --
  Tim:

Re: Dedicated Route Reflectors

[Pshem Kowalczyk]

Hi,

There are multiple ways you can solve that problem. We do the following:

1. Each region has its own ibgp cluster with 2 route reflectors
(usually the P nodes, since they seem to have abundance of CPU power
and not much to do with it).
2. All route reflectors (across regions) are fully meshed. We thought
a bit about creating two 'super' route servers, but then then number
of adjecencies is not that big ( we only have a few regions ).

Regarding internet traffic - we keep the Internet in a VPN, all PEs
that host that VPN are fully meshed and advertise only a default to
the common route reflectors (in their corresponding regions). Each
internet PE uses different RD, so there are multiple default routes
present in the regions.

kind regards
Pshem


2009/9/12 Serge Vautour sergevaut...@yahoo.ca:
 Hello,

 We're in the process of planning for an MPLS network that will use BGP for 
 signaling between PEs. This will be a BGP free Core (i.e. no BGP on the P 
 routers). What are folks doing for iBGP in this case? Full Mesh? Full Mesh 
 the Main POP PEs and Route Reflect to some outlining PEs? Are folks using 
 dedicated/centralized Route Reflectors (redundant of course)? What about 
 using some of the P routers as the Centralized Route Reflectors? The boxes 
 aren't doing much from a Control Plane perspective, why not use them as Route 
 Reflectors.

 Any comments would be appreciated.

 Thanks,
 Serge



      __
 Looking for the perfect gift? Give the gift of Flickr!

 http://www.flickr.com/gift/

Re: Huawei cx300

[Pshem Kowalczyk]

HI,

As far as I understand CX300 does not support vpls (only
point-to-point PWE3).  I don't think that's even on the road map.

kind regards
Pshem


2009/5/29 Jack Kohn kohn.j...@gmail.com:
 Guys,

 Anybody any experience with VPLS on Huawei cx300?

 Jack

Colo on the West Coast

[Pshem Kowalczyk]

Hi,

I'm looking for a colo provider somewhere on the west coast,
preferably somewhere close to one of the peering exchanges. A virtual
machine will do.
I want to use it to run a small performance monitoring box
(traceroutes, pings, etc). I also would like to get a full bgp feed
into it so I can monitor bgp as well.
Who do you think would be the best one to do it with?

(answers can be off-list)

kind regards
Pshem

Re: Concerning MPLS paths

[Pshem Kowalczyk]

Hi,

2009/4/28 Saqib Ilyas msa...@gmail.com:
 Hello everyone
 In the context of a single service provider network running MPLS, if a
 number of bandwidth constrained LSPs are passing through a particular node
 and the sum of the bandwidth constraints for the LSPs is X Mb/s, then is X
 the upper bound on the traffic through that node, or is it sometimes
 exceeded as well?

From my experience with RSVP-TE and LSP tunnels the bandwidth you pin
down for a tunnel is only reserved, not guaranteed. There is nothing
stopping you from creating a 10Mb/s LSP and sending 20Mb/s down
through it. By default only the ingress LSR can do the
policing/shaping. If you don't to that at the head than the rest of
the network will just happily pass the traffic defaulting to its
normal queue handling.
So to answer to your question is - yes you might see more traffic then
you've reserved.

kind regards
Pshem