This is more in the way of a leading question for those who are
attending NANOG 40.
I'll ask it the same way I did at NZNOG back in February --
what problem is it that IPv6 is actually supposed to solve?
I used to know the answer to this, but I don't now. In 1997
(or even years before, readin
> what problem is it that IPv6 is actually supposed to solve?
that's an easy one. in 1993-5, the press was screaming that we were
about to run out of ip space. a half-assed design was released. the
press stopped screaming. victory was declared, everyone went home.
and, as usual, ops and engi
THe intention was that ipng would address the issues you quote Scott
as raising. What could be addressed cleanly, and was addressed, was
the number of bits in the address.
In part, I think this was due to unrealistic expectations. Security,
as you well know, is not a network layer questio
At 5:27 PM -0700 5/30/07, Fred Heutte wrote:
>This is more in the way of a leading question for those who are
>attending NANOG 40.
>
>I'll ask it the same way I did at NZNOG back in February --
>what problem is it that IPv6 is actually supposed to solve?
>
>I used to know the answer to this, but I
> Most of those features were completely gone by 1995
TLAs et alia lasted until 2000+. and i think anycast is still broken,
though we can at least ignore it and use v4-style anycast, which turns
out to be what we need.
> leaving larger address space as the sole practical benefit and no
> actual
> i think anycast is still broken, though we can at least ignore it and
> use v4-style anycast, which turns out to be what we need.
i am told by a good friend who lurks that this was actually fixed a year
or two ago. a team of ops-oriented folk were sufficiently persistent
and strident to get i
At 6:28 PM -0700 5/30/07, Randy Bush wrote:
>well, you get two points for copping to it. i lay on the train tracks
>and was squashed.
Well, I became a contentious objector... (RFC1669). One can
confirm a real sense of humor to the cosmos, because I now
get to be lead advocate for the very scena
On Wed, 30 May 2007 18:52:12 PDT, Randy Bush said:
> > i think anycast is still broken, though we can at least ignore it and
> > use v4-style anycast, which turns out to be what we need.
>
> i am told by a good friend who lurks that this was actually fixed a year
> or two ago. a team of ops-orie
Hi,
Sheng Jiang (Huawei) and Brian Carpenter (University of Auckland, research
consultant to Huawei) are currently running a questionnaire on IPv6 deployment,
addressed to every ISP. The purpose is to provide facts for a document about
deployment scenarios that we are drafting for discussion in
Can anyone share resources on deploying IPv6 in a provider network?
Most all documentation I find is from the customer perspective; which is great
and all, but what about setting up dhcpv6-pd, what about the relay agent, or
what about an equivalent of dhcp option 82?
Nich
tworks off of this list
so probably have broader experience than the NANOG archives.
Can we have a thread summarising the most common excuses you've heard,
and if they are actual problems blocking IPv6 deployment or just down
to ignorance? Perhaps this could be the basis for an FAQ type page
On Monday, July 4, 2016, Baldur Norddahl > wrote:
> On 4 July 2016 at 11:41, Masataka Ohta
> wrote:
>
> > With end to end NAT, you can still configure your UPnP capable NAT
> > boxes to restrict port forwarding.
> >
>
> Only if you by NAT mean "home network NAT". No large ISP has or will deploy
>
Hello everyone. My name is Elliott Karpilovsky, a student at Princeton
University. In collaboration with Alex Gerber (AT&T Research), Dan Pei (AT&T
Research), Jennifer Rexford (Princeton University), and Aman Shaikh (AT&T
Research), we studied the extent of IPv6 deployment at bot
On Fri, 1 Jul 2016, Mike Jones wrote:
> Hi,
>
> I am in contact with a couple of network operators trying to prod them
> to deploy IPv6, I figured that 10 minutes to send a couple of emails
> was worth the effort to make them "see a customer demand" (now none of
> them can use the excuse that nob
From: Mike Jones -- Sent: 2016-07-01 - 12:52
> Hi,
>
> I am in contact with a couple of network operators trying to prod them
> to deploy IPv6, I figured that 10 minutes to send a couple of emails
> was worth the effort to make them "see a customer demand" (now none of
> them can use
https://youtu.be/v26BAlfWBm8
Is always good for a reminder and laughs on a holiday weekend.
Jared Mauch
> On Jul 1, 2016, at 5:00 PM, Hugo Slabbert wrote:
>
> http://ipv6excuses.com/
> https://twitter.com/ipv6excuses
>
> http://ipv6excuses.com/
That website only supports IPv4.
Gary
On Fri Jul 1 17:43:21 2016, Gary Wardell wrote:
> >
> > http://ipv6excuses.com/
>
> That website only supports IPv4.
It’s on your side.
alarig@pikachu ~ % telnet ipv6excuses.com http
Trying 2403:7000:8000:500::26...
Connected to ipv6excuses.com.
Escape character is '^]'.
^]
telnet> quit
Connec
From: Alarig Le Lay -- Sent: 2016-07-01 - 14:53
> On Fri Jul 1 17:43:21 2016, Gary Wardell wrote:
>> >
>> > http://ipv6excuses.com/
>>
>> That website only supports IPv4.
>
> It’s on your side.
>
> alarig@pikachu ~ % telnet ipv6excuses.com http
> Trying 2403:7000:8000:500::26...
> Conn
@nanog.org
> Subject: Re: IPv6 deployment excuses
>
> On Fri Jul 1 17:43:21 2016, Gary Wardell wrote:
> > >
> > > <http://ipv6excuses.com/> http://ipv6excuses.com/
> >
> > That website only supports IPv4.
>
> It’s on your side.
>
&g
Jared Mauch wrote:
https://youtu.be/v26BAlfWBm8
Is always good for a reminder and laughs on a holiday weekend.
But, end to end NATs are actually good:
https://tools.ietf.org/html/draft-ohta-e2e-nat-00
fully transparent to all the transport and application layer
protocols.
And, to a
Actually they are not that great. Look at the DDoS mess that UPnP has created
and problems for IoT (I call it Internet of trash, as most devices are poorly
implemented without safety in mind) folks on all sides.
The fact that I go to a hotel and that AT&T mobility have limited internet
reach i
Thanks guys, this is what I have come up with so far. Next week i'll
put together a web page or something with slightly better write-ups,
but these are my initial ideas for responses to each point. Better
answers would be welcome.
"We have NAT, therefore we don't need IPv6."
"We still have plenty
Issues I've faced in the past with v6 deployments, from the point of view
of stub networks. Feel free to pick/choose as you wish:
- Badly understood (By the team) methods to assign addressing to servers.
- Poor tooling in regards to log processing/external providers.
- Unknown cost in dev time to
> There is no difference between IPv4 and IPv6 when it comes to
> firewalls and reachability. It is worth noting that hosts which
> support IPv6 are typically a lot more secure than older IPv4-only
> hosts. As an example every version of Windows that ships with IPv6
> support also ships with the f
Windows 8 and 10 with the most recent service packs default the firewall to
on with very few inbound exemptions.
On Jul 2, 2016 11:38 AM, "Keith Medcalf" wrote:
>
> > There is no difference between IPv4 and IPv6 when it comes to
> > firewalls and reachability. It is worth noting that hosts which
now because I
never ran it.
> -Original Message-
> From: Spencer Ryan [mailto:sr...@arbor.net]
> Sent: Saturday, 2 July, 2016 10:08
> To: Keith Medcalf
> Cc: North American Network Operators' Group
> Subject: RE: IPv6 deployment excuses
>
> Windows 8 and 10 with t
There's one other major issue faced by stub networks which I have
encountered at $DAYJOB:
- My upstream(s) refuse(s) to support IPv6
This *is* a deal breaker. The pat response of "get new upstreams" is not
helpful and shows the distinct bias among this community to the large
players who actua
On Sat, Jul 02, 2016 at 10:49:40AM -0600, William Astle wrote:
> it usually boils down to "we don't want to put any effort or resources into
> updating anything".
>
And they must be right as their clients won't go away... :p
- Original Message -
From: "Keith Medcalf"
To: "nanog list"
Sent: Saturday, July 2, 2016 11:41:48 AM
Subject: RE: IPv6 deployment excuses
Yes, the default is "on". An exception is added for EVERY SINGLE PIECE of
Microsoft Crapware, whether it is needed or not (an
Living in an area where we have a dense pocket without broadband available is a
key problem. The two incumbents fail to service the area despite one having
fiber 1200' away at the entry to our street.
One area incumbent can do native v6, the other does 6rd but they don't serve
the area so it's
way you had set them, I am
quite sure that you take an entirely different position!
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mike Hammett
> Sent: Saturday, 2 July, 2016 12:43
> Cc: nanog list
> Subject: Re: IPv6 deployment excuse
On 2/Jul/16 17:35, Ruairi Carroll wrote:
> - ECMP issues (Mostly around flow labels and vendor support for that, also
> feeds back into PMTUD issues)
Do you rely on the ToS field in IPv4 for ECMP?
> - Maintaining 2x IP stacks is inherently expensive Vs 1
How so?
Mark.
On 2/Jul/16 18:49, William Astle wrote:
> Their specific excuse du jour changes every few months but it usually
> boils down to "we don't want to put any effort or resources into
> updating anything".
If you keep asking your girlfriend out on a date each week, and she
refuses to go out with yo
On 3 July 2016 at 11:42, Mark Tinka wrote:
>
>
> On 2/Jul/16 17:35, Ruairi Carroll wrote:
>
> - ECMP issues (Mostly around flow labels and vendor support for that, also
> feeds back into PMTUD issues)
>
>
> Do you rely on the ToS field in IPv4 for ECMP?
>
>
Nope. I use l4 tuple for flow hashing t
On 3/Jul/16 12:01, Ruairi Carroll wrote:
>
> Core of the issue is that we _need_ to get an ICMP message back to the
> original "real server" who sent it. It's a non-issue in the SP space,
> but imagine if your ECMP groups were stateful in both directions...
Okay.
>
>
> Think about it in lay
On 3 July 2016 at 12:15, Mark Tinka wrote:
>
>
> On 3/Jul/16 12:01, Ruairi Carroll wrote:
>
>
> Core of the issue is that we _need_ to get an ICMP message back to the
> original "real server" who sent it. It's a non-issue in the SP space, but
> imagine if your ECMP groups were stateful in both di
* Mark Tinka
> I understand your points - to your comment, my question is around
> whether it is cheaper (for you) to just run IPv6 in lieu of IPv6 and
> IPv4.
We've found that it is. IPv6-only greatly reduces complexity compared to
dual stack. This means higher reliability, lower OpEx, shorter r
On 3/Jul/16 15:34, Tore Anderson wrote:
> We've found that it is. IPv6-only greatly reduces complexity compared to
> dual stack. This means higher reliability, lower OpEx, shorter recovery
> time when something does go wrong anyway, fewer SLA violations, happier
> customers, and so on - the list
* Mark Tinka
> What I was trying to get to is that, yes, running a single-stack is
> cheaper (depending on what "cheaper" means to you) than running
> dual-stack.
Wholeheartedly agreed.
> That said, running IPv4-only means you put yourself at a disadvantage
> as IPv6 is now where the world is g
On 4/Jul/16 11:04, Tore Anderson wrote:
> My point is that as a content provider, I only need dual-stacked
> façade. That can easily be achieved using, e.g., protocol translation
> at the outer border of my network.
>
> The inside of my network, where 99.99% of all the complexity, devices,
> app
Jared Mauch wrote:
Actually they are not that great. Look at the DDoS mess that UPnP has
created and problems for IoT (I call it Internet of trash, as most
devices are poorly implemented without safety in mind) folks on all
sides.
Are you saying, without NAT or something like that to restrict
Without firewalls, internet is not very secure, regardless of protocol used.
On 07/04/2016 11:41 AM, Masataka Ohta wrote:
> Jared Mauch wrote:
>
>> Actually they are not that great. Look at the DDoS mess that UPnP has
>> created and problems for IoT (I call it Internet of trash, as most
>> device
I disagree. Any data center or hosting provider is going to continue to offer
IPv4 lest they island themselves from subscribers who have IPv4 only - which no
data center is going to do.
One can not run IPv6 only because there are sites that are only IPv4.
Thus, as an ISP you can safely contin
In message , Matt
Hoppes writes:
> I disagree. Any data center or hosting provider is going to continue to
> offer IPv4 lest they island themselves from subscribers who have IPv4
> only - which no data center is going to do.
>
> One can not run IPv6 only because there are sites that are only IPv4
My point is there are more than enough IPv4 addresses. The issue is not
resources. It is hoarding and inappropriate use.
The large ISPs have enough IPs to service every household in the US several
times over. And yet, we have an IP shortage.
There are universities holding onto /8s and not usi
r we've seen it spike to
25%-30%. So in the US, we may very well reach that tipping point within the
next couple of years. If we do, the utility of IPv4 will probably start to
degrade pretty rapidly as more attention and focus is placed on IPv6
connectivity. If that happens and you're sti
There are 7 billion people world wide that want Internet and only
approximately 3 billion usable IPv4 addresses. It wont do.
Den 4. jul. 2016 16.03 skrev "Matt Hoppes" <
mattli...@rivervalleyinternet.net>:
> My point is there are more than enough IPv4 addresses. The issue is not
> resources. It is
Except that IPv4 is not exhausted. That's the doomsday message that was
preached over and over.
The simple fact that there is/are IP broker exchanges now simply proves there
are surplus IPs to go around.
We have an efficiency utilization issue - not an exhaustion issue.
On 4 July 2016 at 17:33, Matt Hoppes wrote:
> The simple fact that there is/are IP broker exchanges now simply proves there
> are surplus IPs to go around.
I'm unsure of the message. Is the statement that if commodity is
tradable, there is surplus to go around? Is converse true? If I can't
buy
On Mon, 4 Jul 2016, Matt Hoppes wrote:
My point is there are more than enough IPv4 addresses. The issue is not
resources. It is hoarding and inappropriate use.
I tend to make the analogy of land use and/or houses/apartments. Yes,
there is that old lady down the street who lives in 300 square
Except the lady will eventually downsize. The college student will want more
and lease the space.
Also, the 49,000 Sq ft office space that has been leased for 10 years and never
occupied will be taken back and released to someone who will actually develop
it.
> On Jul 4, 2016, at 11:58, Mika
On Mon, Jul 4, 2016 at 12:28 PM, Matt Hoppes <
mattli...@rivervalleyinternet.net> wrote:
> Except the lady will eventually downsize. The college student will want
> more and lease the space.
>
> Also, the 49,000 Sq ft office space that has been leased for 10 years and
> never occupied will be take
On Mon 2016-Jul-04 12:42:33 -0400, Christopher Morrow
wrote:
On Mon, Jul 4, 2016 at 12:28 PM, Matt Hoppes <
mattli...@rivervalleyinternet.net> wrote:
Except the lady will eventually downsize. The college student will want
more and lease the space.
Also, the 49,000 Sq ft office space that h
On Mon, Jul 4, 2016 at 11:28 AM, Matt Hoppes <
mattli...@rivervalleyinternet.net> wrote:
> Except the lady will eventually downsize. The college student will want
> more and lease the space.
>
> Also, the 49,000 Sq ft office space that has been leased for 10 years and
> never occupied will be take
Filip Hruska wrote:
Without firewalls, internet is not very secure, regardless of protocol used.
Irrelevant.
The point of the Internet with end to end transparency is that
if end users want to have the end to end transparency, they
can have it.
If they don't, they don't have to.
On 4 July 2016 at 11:41, Masataka Ohta
wrote:
> With end to end NAT, you can still configure your UPnP capable NAT
> boxes to restrict port forwarding.
>
Only if you by NAT mean "home network NAT". No large ISP has or will deploy
a carrier NAT router that will respect UPnP. That does not scale a
On 4/Jul/16 14:44, Matt Hoppes wrote:
> I disagree. Any data center or hosting provider is going to continue to offer
> IPv4 lest they island themselves from subscribers who have IPv4 only - which
> no data center is going to do.
But that's what I said...
Mark.
On 4/Jul/16 16:33, Matt Hoppes wrote:
> Except that IPv4 is not exhausted. That's the doomsday message that was
> preached over and over.
>
> The simple fact that there is/are IP broker exchanges now simply proves there
> are surplus IPs to go around.
>
> We have an efficiency utilization is
On 4/Jul/16 18:28, Matt Hoppes wrote:
> Except the lady will eventually downsize. The college student will want more
> and lease the space.
>
> Also, the 49,000 Sq ft office space that has been leased for 10 years and
> never occupied will be taken back and released to someone who will actual
On 2016-07-04 20:50, Ca By wrote:
Always so funny how people love talking how great MAP scales, yet it has
never been deployed at scale. 464XLAT and ds-lite have been deployed at
real scale, so has 6RD.
MAP is like beta max. Technically great, but reality is poor.
The two MAP RFCs are dated Ju
On Monday, July 4, 2016, Baldur Norddahl wrote:
> On 2016-07-04 20:50, Ca By wrote:
>
>
> Always so funny how people love talking how great MAP scales, yet it has
> never been deployed at scale. 464XLAT and ds-lite have been deployed at
> real scale, so has 6RD.
>
> MAP is like beta max. Technica
On Mon, Jul 04, 2016 at 06:41:00PM +0900, Masataka Ohta wrote:
> Jared Mauch wrote:
>
> > Actually they are not that great. Look at the DDoS mess that UPnP has
> > created and problems for IoT (I call it Internet of trash, as most
> > devices are poorly implemented without safety in mind) folks on
Baldur Norddahl wrote:
With end to end NAT, you can still configure your UPnP capable NAT
boxes to restrict port forwarding.
Only if you by NAT mean "home network NAT". No large ISP has or will deploy
a carrier NAT router that will respect UPnP.
A large ISP should just set up usual NAT. In
Or how about we just avoid anything that uses the terms like "Mappings" and
"NAT" and speed the adoption of IPv6 everywhere which already solves all of
these problems.
*Spencer Ryan* | Senior Systems Administrator | sr...@arbor.net
*Arbor Networks*
+1.734.794.5033 (d) | +1.734.846.2053 (m)
www.ar
Jared,
The issue I have with the whole DNS IPv6 thing is IPs are static (on
infrastructure), DNS can get munged up and is another database we have to
maintain.
So now rather than just maintaining an IP database we have to maintain a
database for DNS to IP and the IP.
And Ina subscriber netwo
Jared Mauch wrote:
Are you saying, without NAT or something like that to restrict
reachable ports, the Internet, regardless of whether it is with
IPv4 or IPv6, is not very secure?
I'm saying two things:
1) UPnP is a security nightmare and nobody (at scale)
will let you registe
> On Jul 4, 2016, at 10:32 PM, Matt Hoppes
> wrote:
>
> Jared,
> The issue I have with the whole DNS IPv6 thing is IPs are static (on
> infrastructure), DNS can get munged up and is another database we have to
> maintain.
I’m not sure I understand your point. DNS is DNS. It’s not the 1990
On Tue, 05 Jul 2016 11:16:31 +0900, Masataka Ohta said:
> A large ISP should just set up usual NAT. In addition, the ISP
> tells its subscriber a global IP address, a private IP address
> and a small range of port numbers the subscriber can use and
> set up *static* bi-directional port forwarding.
valdis.kletni...@vt.edu wrote:
A large ISP should just set up usual NAT. In addition,
Thus almost guaranteeing a call to the support desk for each and every single
game console, because the PS3 and PS4 doesn't have a configuration interface
for that, and the XBox probably doesn't either (and
On Mon, 4 Jul 2016, Baldur Norddahl wrote:
The two other technologies mentioned do the same as MAP more or less,
but both requires carrier NAT, which is expensive for the ISP and has a
lack of control as seen from the end user point of view (no port
forwarding etc).
What it does however, is
On 5 July 2016 at 07:27, Mikael Abrahamsson wrote:
> On Mon, 4 Jul 2016, Baldur Norddahl wrote:
>
> The two other technologies mentioned do the same as MAP more or less, but
>> both requires carrier NAT, which is expensive for the ISP and has a lack of
>> control as seen from the end user point o
On Tue, 5 Jul 2016, Baldur Norddahl wrote:
We will tell you to use IPv6 for that or make you pay extra for a
dedicated IPv4 address.
That is a good solution to that problem. I hope all ISPs implementing A+P
protocols does that. It also puts a monthly cost that teleworkers have to
pay (or the
Cc: nanog@nanog.org
Sent: Monday, July 4, 2016 11:22:59 PM
Subject: Re: IPv6 deployment excuses
valdis.kletni...@vt.edu wrote:
>> A large ISP should just set up usual NAT. In addition,
> Thus almost guaranteeing a call to the support desk for each and every single
> game console, b
s also a lot of selection-bias in the NANOG membership
> base but you deal with a lot of enterprise networks off of this list
> so probably have broader experience than the NANOG archives.
>
> Can we have a thread summarising the most common excuses you've heard,
> and if they a
t; > so probably have broader experience than the NANOG archives.
> >
> > Can we have a thread summarising the most common excuses you've heard,
> > and if they are actual problems blocking IPv6 deployment or just down
> > to ignorance? Perhaps this could be the basis f
On 11/07/2016 09:24, Mark Andrews wrote:
>> Our provider sale representative, who is the most tech savvy sale-rep I
>> ever encountered by far, which is not a very high bar, but still, said
>> something like:
>> "You shouldn't worry about that, we have plenty of IPv4 addresses
>> left... and beside
hey,
Some time ago, many people noticed rapid IPv6 deployment growth in
Estonia (from 0% to 5% in 4 weeks). We at 3249/Elion/Estonian Telecom
were behind this, other operators don't have any serious IPv6
deployments at the moment. We rolled out v6 to everyone (both business
and reside
, ect.
I’m trying not to light a religious war but what is the current best practice
for IPv6 deployment in a service provider network?
PS. I’ll be at NANOG69 in DC next month, 1st NANOG for me after 22 years. ☺
-Matt
--
Matthew Crocker
Crocker Communications, Inc.
President
Looking for general feedback on IPv6 deployment to the edge.
As it turns out delivering IPv6 to the edge in an academic setting has
been a challenge. Common wisdom says to rely on SLAAC for IPv6
addressing, and in a perfect world it would make sense.
Given that historically we have relied on
we studied the extent of IPv6 deployment at both global and local
> levels. Our conclusions can be summarized by the following three points:
>
> 1.) IPv6 deployment is not seen as a pressing issue.
> 2.) We saw a lack of meaningful IPv6 traffic (mostly DNS/Domain and ICMP
> messages),
nceton University), and Aman Shaikh (AT&T
> Research), we studied the extent of IPv6 deployment at both global and local
> levels. Our conclusions can be summarized by the following three points:
> >
> > 1.) IPv6 deployment is not seen as a pressing issue.
> > 2.) We saw a
d (Princeton University), and Aman Shaikh (AT&T
> Research), we studied the extent of IPv6 deployment at both global and local
> levels. Our conclusions can be summarized by the following three points:
>
> 1.) IPv6 deployment is not seen as a pressing issue.
Agreed. SPs are driven by
ent
of IPv6 deployment at both global and local levels. Our conclusions can be summarized by
the following three points:
1.) IPv6 deployment is not seen as a pressing issue.
2.) We saw a lack of meaningful IPv6 traffic (mostly DNS/Domain and ICMP
messages), possibly indicating that IPv6 networ
On 29/04/2009, at 5:30 AM, Harald Firing Karlsen wrote:
Please check out the following link with some information/statistics
from a LAN-party taking place in Norway (yeah, Norway is in Europe,
not North America, but it stills give an overview):
http://technet.gathering.org/?p=121
There wer
Is there anyone here working in an ISP where IPv6 is deployed?
We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I
am interesting in knowing the mask you use for the assignment; whether it
is /64 or /128.
In RFC 3177, it says:
3. Address Delegation Recommendations
The IE
Hello, folks!
Tere from your customer FastVPS Eesti OU/AS198068! :)
On Mon, Dec 22, 2014 at 6:27 PM, Tarko Tikan wrote:
> hey,
>
> Some time ago, many people noticed rapid IPv6 deployment growth in Estonia
> (from 0% to 5% in 4 weeks). We at 3249/Elion/Estonian Telecom were behind
&
On 2014-12-22 16:27, Tarko Tikan wrote:
> Our access network is mix of DSL/GPON/wimax/p2p-ETH and broadband service is
> deployed in shared service vlans. IPv6 traffic shares vlan with IPv4.
How do you protect customers from each other?
There are many nasty IPv6 attacks you can do when on a shar
hey,
How do you protect customers from each other?
There are many nasty IPv6 attacks you can do when on a shared VLAN.
Split-horizon (switchport protected in Cisco world). Customers can't
send packets directly to each other, all communication has to go via BNG
router. Obviously we protect L
Hi,
On Sat, Dec 27, 2014 at 05:15:13PM +0100, Anders L??winger wrote:
> On 2014-12-22 16:27, Tarko Tikan wrote:
>
> > Our access network is mix of DSL/GPON/wimax/p2p-ETH and broadband service is
> > deployed in shared service vlans. IPv6 traffic shares vlan with IPv4.
>
> How do you protect cust
Phil
-Original Message-
From: "Anders Löwinger"
Sent: 12/27/2014 11:17 AM
To: "nanog@nanog.org"
Subject: Re: Estonian IPv6 deployment report
On 2014-12-22 16:27, Tarko Tikan wrote:
> Our access network is mix of DSL/GPON/wimax/p2p-ETH and broadband service is
> d
On 2014-12-27 17:27, Tarko Tikan wrote:
> Split-horizon (switchport protected in Cisco world). Customers can't send
> packets directly to each other, all communication has to go via BNG router.
> Obviously we protect L2 as well like limiting number of MACs per customers,
> make sure BNG MAC cannot
On 2014-12-27 17:37, Enno Rey wrote:
> true, but some (most) of them only apply in networks where multicasting/ND is
> fully supported which is not necessarily the case in the above type of
> networks.
Yes. I'm aware of the various types of solutions for security in IPv6 with
shared VLANs. I was
hey,
I assume you have a star-network below the BNG? Ie no rings or similar in the
access network?
Most of our network below BNG is MPLS, so no, it's not a star per say.
But as PWs are point-to-point, you are technically correct. Below MPLS
there is some ethernet too and this is all strictly
, ect.
I’m trying not to light a religious war but what is the current best
practice for IPv6 deployment in a service provider network?
PS. I’ll be at NANOG69 in DC next month, 1st NANOG for me after 22
years. ☺
At the start, the advice was to configure individual /64 for
loopbacks, however
e a /64 for PtP interfaces and I’ve read use a /128
> instead.Assign all loopbacks from the same /64, use a different /64 for
> each loopback. Ect, ect.
>
>
>
> I’m trying not to light a religious war but what is the current best
> practice for IPv6 deployment in a service
On Mon, Jan 16, 2017 at 10:11 AM, Matthew Crocker
wrote:
> I’m looking for some direction/reading list of how to properly configure
> IPv6. I’ve read to use a /64 for PtP interfaces and I’ve read use a /128
> instead.Assign all loopbacks from the same /64, use a different /64 for
> each lo
Hi,
> Suggest /128's for loopbacks and /124's for point to points, all from
> the same /64. This way you don't burn space needlessly, don't open
> yourself to neighbor discovery issues on point to points
I usually reserve one /64 for loopbacks, reserve a /64 per point-to-point
connection and con
o properly configure
> IPv6. I’ve read to use a /64 for PtP interfaces and I’ve read use a /128
> instead.Assign all loopbacks from the same /64, use a different /64 for
> each loopback. Ect, ect.
>
> I’m trying not to light a religious war but what is the current best
>
erfaces and I’ve read use a /128
>> instead.Assign all loopbacks from the same /64, use a different /64 for
>> each loopback. Ect, ect.
>>
>> I’m trying not to light a religious war but what is the current best
>> practice for IPv6 deployment in a service provider networ
1 - 100 of 356 matches
Mail list logo
