Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1]

[Nick Hilliard]

Bjørn Mork wrote on 27/10/2019 19:17:

Automating updates of all this is semi-trivial.


this is completely atypical for what we are talking about, which is 
residential consumer access, where you connect in, get some IP addresses 
and then someone unplugs the CPE because they need to clean the shelf 
where the modem is, and then nothing works properly because client 
devices can't automatically renumber.


Your deployment use case is a stereotype case of needing static addresses.

The two things are not really comparable, at all.

Nick

Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1]

[Nick Hilliard]

Bjørn Mork wrote on 26/10/2019 15:06:

I realize that the "can't do stable addresses" might be enforced by
non-technical entities, but this would most likely not happen if it was
a violation of a standards track RFC.


Surely you're joking?

Nick

Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1]

[Nick Hilliard]

Brian E Carpenter wrote on 26/10/2019 00:02:

Progress will only come as more and more people stop putting IPv6 in
the "too hard" basket.
maybe it is though?  Maybe we underestimate the level of overall 
complexity because when we look at any individual component, we can 
always explain it away because it's only more complicated by a smidgen.


So for example, we mandate /64 for CPE/residential access and tell 
people that assigning lots of /64s is good because it gives people 
flexibility, although we don't suggest how to push them further down 
into the network or provide an easy way to abstract away all the 
complexities of running multiple networks.


We say ULA is fine for local stuff, but no NAT please (this is ipv6 
after all), and then we write a 16 page document to tell people how to 
select a suitable prefix, and then say it's really not that complicated 
because the actual algorithm is only a 6-point sample idea and people 
can do their own thing anyway.


We tell vendors that they must implement SLAAC and they don't need DHCP 
but by the same token tell them that if they want anything more than 
getting a host up and running, SLAAC won't do it, so they look at DHCP 
(e.g. DOCSIS, residential DSL, etc) and force the vendors to use both 
because we block the 2-3 constructs which would allow DHCP to operate as 
a standalone protocol and do the whole lot in a significantly simpler way.


For years we never stepped in when people claimed that ipv6 was better 
than ipv4 because it was designed to be easy to renumber, and now we're 
here wondering why it's 2019 and there's no way to initiate a 
renumbering process for SLAAC, and we frown because tech support desks 
recommend disabling ipv6 because it's easier than fixing the underlying 
problem because there is no underlying fix because SLAAC can't handle 
the situation where the CPE renumbers but the end host doesn't.


This is just some bits of residential / cpe access.  The same story is 
reflected across other ipv6 deployment scenarios.


All of these things are individually reasonable and justifiable, and we 
all buy into the explanations because we're good at convincing ourselves 
about the things we already want to believe.


But we've crippled ourselves with complexity and we don't want to 
acknowledge it.


Nick

Re: ipv6-ops Digest, Vol 159, Issue 1

[Nick Hilliard]

Michael Sturtz wrote on 25/10/2019 16:21:

Nick I agree!  The problem is from an operational support and
protocol level we created this monster by selling the idea of "end to
end connectivity" and "every end site will get a /64" that has been
sold to even end users.


The problem was more a cultural thing in the ietf - people wanted 
devices to have autonomy and be able to select their own addressing 
mechanism, and not be subject to the whims of the network operator. 
Hence the intent behind /64, and SLAAC, and the difficulties that the 
IETF has with DHCP.


The problem was (and is) that this vision didn't align well with 
reality, particularly enterprise but also content hosting and other 
deployment scenarios.



I understand that the ISPs really don’t want
customers to be able to serve content from consumer connections.
This is likely why they are randomly changing the /64 allocated to
the end sites especially on consumer lines.


The reason for this relates to address aggregation at the ISP rather 
than wanting to prevent consumers from serving content.  Honestly most 
ISPs don't care whether people put content services on their house 
connections because usually this doesn't create much extra cost (DOCSIS 
and cell-phone systems excluded).  What does cost a lot, though, is when 
you have massive prefix disaggregation and you need to deal with 
provisioning hell and gigantic IGP tables in order to provide people 
static assignments, even if most people don't really need them.  This is 
why it's mostly a commercial problem rather than a protocol issue.



event occurs.  I have personal experience with multiple devices that
use SLAAC breaking connectivity for some indeterminate period of time
when a network renumber event occurs.  Yes this could be due to
poorly implemented end devices etc. but the end point is people just
disable IPv6 because of the headaches caused by it.

Yep.

Nick

Re: ipv6-ops Digest, Vol 159, Issue 1

[Nick Hilliard]

Michael Sturtz wrote on 25/10/2019 16:03:

This sort of operational nonsense will limit the wider acceptance of
IPv6!  I am responsible research and for the documentation and
implementation of IPv6 for a Fortune 200 company.  We have locations
worldwide.  The allocation of unstable end network addresses
complicates the deployment and support of IPv6.
most service providers view this as a commercial issue rather than a 
protocol issue.  This is just an observation, btw.


Nick

Re: Atlas probes and 6to4 [Re: IPv6 ingress filtering]

[Nick Hilliard]

Brian E Carpenter wrote on 18/05/2019 05:05:

% cat *.txt | jq '.[] | select (.rcvd == 0) | .from' | cut -d\" -f2 | grep 
^2002 | sort | uniq -c
2 2002:2ea7:331c:0:1ad6:c7ff:fe2a:1a7c
1 2002:4e1a:aba9:10:fa1a:67ff:fe4d:7ee9
1 2002:4e79:421e:0:a62b:b0ff:fee0:ae0
1 2002:5253:a51b:0:1:e3ff:febb:121b
2 2002:55d4:648c:0:f6f2:6dff:fe5d:a19c
1 2002:566:3896:0::b3ff:feb0:e87a
3 2002:568:1047:1:220:4aff:fee0:20ac
2 2002:592:4daf:0:1:7dff:feac:317e
2 2002:5aba:3e12:1:eade:27ff:fe69:b644
1 2002:5b64:65f8:0:a62b:b0ff:fee0:1572
2 2002:5b73:5fdd::c66e:1fff:fe3a:d118
2 2002:8603:d75b:0:280:a3ff:fe91:408d
1 2002:b2f8:fe64:0:a2f3:c1ff:fec4:591c
2 2002:d58f:794c:0:eade:27ff:fe69:c8fa
2 2002:d5d1:57ac:1:c24a:ff:fecc:99fa
%


What does the leading digit (1, 2 or 3) mean? Because all
those with "1" are pingable from here, but none of the others.


Of the three testing hosts, that's how many found the destination host 
to be unreachable.



I.e. 1.5% of the sample probes were using 6to4.  Of these, 8 had
connectivity to the two control hosts, but not to the 6to4 host.  This
is awful!


If they are nodes using the deprecated anycast solution to get their
6to4 connectivity, this is unfortunately the expected result, and exactly
why we deprecated it. But in any case, Atlas probes with 6to4 addresses
seems pathological to me.


I'd blame laziness more than pathology.  But it is inappropriate, no 
doubt about it.



But the ones tagged "1" seem to work. For example,
2002:566:3896:0::b3ff:feb0:e87a works. Its embeded IPv4
address is 5.71.38.96, which allegedly belongs to BSKYB in
the UK. (It's probably probe #13420 whose details are private.)


It turned out that the ones tagged "1" were unable to contact the 6to4 
endpoint, not the native ipv6 destinations.  I.e. there was some loss of 
connectivity, but anything involving 6to4 exacerbated things.



Dear he.net, RFC3056 says that a site MUST NOT advertise a route
to 2002::/16 unless it's willing to act as a relay router, which
means relaying to *any* IPv4 address. Could it be that 6to4.tyo1.he.net
is only willing to relay to a limited set of IPv4 addresses?


Naah, HE operate open relays.  It's hard to diagnose what the exact 
underlying problem is; perhaps overzealous application of urpf? Ingress 
filtering of 2002::/16?  Not sure it matters much at this stage.



(Why do I bother, not being an operator? Maybe some slight guilt
at having propagated 6to4 in the first place...)


No need for guilt - many of us happily used it for years!

Nick

Re: IPv6 ingress filtering

[Nick Hilliard]

Brian E Carpenter wrote on 17/05/2019 21:06:

And surely the question is "What would produce the most help desk calls?".
Filtering something that is presumably working for its remaining users
might not be a good idea from that point of view.


6to4 connectivity is probably already too broken to use.  Here are some 
atlas measurements from a couple of days ago:


https://atlas.ripe.net/measurements/21449877/
https://atlas.ripe.net/measurements/21449878/
https://atlas.ripe.net/measurements/21449879/

This was 3-packet ping from the same 1000 probes to three ipv6 hosts. 
The results were:


server in IE: 14.5% unreachability
www.kame.net: 15.0% unreachability
random 6to4 address: 23.1% unreachability

What's also unfortunate is after downloading the json results:


% cat *.txt | jq '.[] | select (.rcvd == 0) | .from' | cut -d\" -f2 | grep 
^2002 | sort | uniq -c
   2 2002:2ea7:331c:0:1ad6:c7ff:fe2a:1a7c
   1 2002:4e1a:aba9:10:fa1a:67ff:fe4d:7ee9
   1 2002:4e79:421e:0:a62b:b0ff:fee0:ae0
   1 2002:5253:a51b:0:1:e3ff:febb:121b
   2 2002:55d4:648c:0:f6f2:6dff:fe5d:a19c
   1 2002:566:3896:0::b3ff:feb0:e87a
   3 2002:568:1047:1:220:4aff:fee0:20ac
   2 2002:592:4daf:0:1:7dff:feac:317e
   2 2002:5aba:3e12:1:eade:27ff:fe69:b644
   1 2002:5b64:65f8:0:a62b:b0ff:fee0:1572
   2 2002:5b73:5fdd::c66e:1fff:fe3a:d118
   2 2002:8603:d75b:0:280:a3ff:fe91:408d
   1 2002:b2f8:fe64:0:a2f3:c1ff:fec4:591c
   2 2002:d58f:794c:0:eade:27ff:fe69:c8fa
   2 2002:d5d1:57ac:1:c24a:ff:fecc:99fa
%


I.e. 1.5% of the sample probes were using 6to4.  Of these, 8 had 
connectivity to the two control hosts, but not to the 6to4 host.  This 
is awful!


Anyway, none of this exceeds the level of "anecdatum", but it's 
potentially interesting nonetheless, and it does suggest connectivity 
problems between the 6to4 network and chunks of the native ipv6 internet.


Nick

Re: Realistic number of hosts for a /64 subnet?

[Nick Hilliard]

Gert Doering wrote on 10/05/2019 22:16:

Just make sure their phones are in the same network segment.

No shouting.


Then they'll all start complaining on WhatsApp over the wifi network ... 
waait - I see what you're suggesting here.  Brilliantly evil.


Nick

Re: Realistic number of hosts for a /64 subnet?

[Nick Hilliard]

Doug Barton wrote on 10/05/2019 05:27:
It's been a while since I was configuring subnets, and last time I did 
the guidance was always no more than 1,000 hosts per subnet/vlan. A lot 
of that was IPv4 thinking regarding broadcast domains, but generally 
speaking we kept to it for dual stacked networks, equating an IPv4 /22 
with an IPv6 /64. (This was commonly in office environments where we 
used a subnet per floor to accommodate all of the desktops, printers, 
phones, tablets, etc.)


Is this still how people roll nowadays? Have switches and/or other 
network gear advanced to the point where subnets larger than 1k hosts 
are workable? In IPv4 or IPv6? I've done quite a bit of web searching, 
and can't find anything newer than 2014 that has any kind of intelligent 
discussion of this topic.


the question is less "how many can you fit?", but "how few can you get 
away with?" and "when things go wrong, how large can you afford your 
blast radius to be?"


If your goal is to connect lots of access devices on an enterprise 
network, then keep to the physical topology as much as you can, and 
segment at layer 3 where it is practical to do so.  As the NotPetya 
victim organisations found out, it's a good idea to restrict access 
between segments to the greatest extent possible (while still 
maintaining functionality).  RFC8273 has some really great ideas, but 
there's a good deal of overhead associated with configuring it, and I 
suspect that the loss of functionality (host neighbor discovery, etc) 
would made it unattractive to most corporate networks.


I'm sure 1000 hosts on a network will usually work fine, until someone 
does something dumb and takes down the entire segment, at which point 
you'll have 1000 people shouting at you.


Nick

Re: Link-local and ACLs

[Nick Hilliard]

Brian E Carpenter wrote:
> On 25/07/2017 19:07, Gert Doering wrote:
> > So, to stay with Tore's example, if you want to make NDP work on an IXP,
> > you need to permit fe80->fe80, fe80->GUA, etc. in your ACLs - which ends
> > up needing quite a number of lines to cover all cases
> 
> Fair enough. IXPs are a bit of a special case, though.

sorta and sorta not.  An ACL appropriate for an IXP would provide a
template to cover pretty much most use cases, which would then be
directly relevant to other specific cases like having a point-to-point
connection between router A and router B and so forth.

Nick

Re: Link-local and ACLs

[Nick Hilliard]

Gert Doering wrote:
> "on the same link"?

return traffic.  Not much good in having unidirectional data flow.

Nick

Re: Link-local and ACLs

[Nick Hilliard]

David Farmer wrote:
> Also, in theory a link-local address could talk to a GUA or ULA address
> on the same link. However, in practices does this really happen? If it
> does happen in practice what are circumstances?

will that packet not be dropped because a LL ipv6 packet won't be
routed? (MUST NOT in whatever rfc).

Nick

Re: DHCPv6 client in Windows 10 broken after anniversary update

[Nick Hilliard]

Harald F. Karlsen wrote:
> If looks like this was finally resolved in the 2017 March cumulative
> update for Windows. I have verified it on Windows 10 Home and Pro, but I
> also got one report claiming it was not resolved in Windows 10
> Enterprise, can someone confirm this?

if this is the case, is there a difference between the behaviour on W10
Enterprise LTSB and W10 Enterprise standard edition?

Nick

Re: Fwd: [Bp_ixps] IXPs & IPv6

[Nick Hilliard]

Michael Oghia wrote:
> Thanks Nick. Sad to hear, but hopefully we can change that.

you're misunderstanding completely!  It means that ipv6 is considered to
be of the same importance as ipv4 in the ixp world from the point of
view of passing production traffic over the ixp fabric.  As far as the
IXP world is concerned, this is an excellent situation to be in.

Nick

Re: Fwd: [Bp_ixps] IXPs & IPv6

[Nick Hilliard]

> Does anyone knows of recent updates or statements on the IPv6-readines
> of IXPs?

Other than that IPv6 readiness has been a complete non-issue for years
in the IXP community, I can't think of anything new to add to the
euro-ix statement since 2011.

Nick

Re: CPE Residential IPv6 Security Poll

[Nick Hilliard]

Lorenzo Colitti wrote:
> Surely there's got to be a better solution here than
> lowest-common-denominator engineering, a.k.a., "design your product for
> your least knowledgeable customer"?

sensible secure defaults for grandma + "Advanced" tab on CPE
configuration page for 10yo grandchild?

Nick

Re: Netflix hates IPv6

[Nick Hilliard]

Jens Link wrote:
> Why can't I buy DVDs in the US and watch them in my European DVD Player?

if you can't do that, you bought the wrong DVD player.

Nick

Re: Netflix hates IPv6

[Nick Hilliard]

Robert Hosford wrote:
> Unless you use HE like I do. Nice Job Netflix.

you should demand a full refund from HE.

Nick

Re: DHCPv6 relay with PD

[Nick Hilliard]

Templin, Fred L wrote:
> Folks, for real – read AERO. It works. I apologize if that offends anyone.

Not at all.  It's just that I'm confused about why we would need to
resort to a tunneling protocol in order to make basic ipv6 functionality
work.

Would it not be better to try to make ipv6 work without resorting to
tunnels?

Nick

Re: DHCPv6 relay with PD

[Nick Hilliard]

Ole Troan wrote:
> It shouldn't be the IETF's job to tell people how to run their networks.
> The IETF provides the building blocks.

Take a DHCP server, an ISP access router and a CPE.

The CPE connects to the ISP access router and issues a dhcp request.
This is relayed by the access device to the dhcp server which replies to
access device with a PD reply.  The access router relays this reply to
the CPE.

At this point, the state is that both the CPE and the dhcp server know
the delegated prefix, but the access router does not.  The result is
that the customer's prefix is not routed to the CPE.

The question is: how do we make this work so that PD is a viable
mechanism for handling customer ipv6 requirements?

The ISP operator cannot listen to the CPE if it's running a routing
protocol because the access router has no way of determining whether any
announcement it receives from the CPE is a legitimate announcement,
because it has no knowledge of what is or isn't assigned to a particular
customer.

Installing static routes on the access router is non-scalable and
constrains the network architecture in a way which isn't feasible.

It might work if the access router implements dhcpv6 snooping, but the
isp operator has little or no control over this.

I know you're not trying to be unhelpful here, but brushing this off as
someone-else's-problem is not going to make the problem go away.  Nor is
claiming that this is a problem with how the network is run, because
this isn't a problem that operators can feasibly fix because it's a
problem that vendors need to solve, potentially helped with some
guidelines from the ietf.

Nick

Re: v6 naming and shaming - *.europa.eu

[Nick Hilliard]

Andy Davidson wrote:
> My personal website today, whilst of course not a major web asset,
> utilises a reverse proxy to offer service to suffering people on a
> legacy 4-only connection.  The back end is hosted on a v6 only
> network, and a reverse proxy is dual stacked.  It’s a perfectly OK
> model.

https support?

Nick

Re: Cost of IPv6 for IT operations team

[Nick Hilliard]

On 10/04/2015 21:36, Andy Davidson wrote:
> Stage one - [...]
> Stage two - [...]
> Stage three - [...]
> 
> Stage four - utilise your new training and v6 capable edge to roll out
> NEW services dual-stack.  The incremental cost of adding v6 support to a
> NEW rollout when you have to do a bunch of work to roll out a service at
> all is therefore zero.  v6 support for existing services can be added in
> product refreshes in time.

Uh, lemme just drop this in here: http://imgur.com/AYbpRG2

Stage 4 might be a good way of burying deployment costs but I'm going to
assert that stages 1 through 3 are the easier, lower cost bits.  The reason
is that stages 1-3 can be deployed relatively easily by a tiny number of
people even on reasonably large networks.  Although stage 3 - where you
state the costs lie - is the first place which causes a direct and up-front
cost to be incurred in terms of resourcing and config, it can still be
rolled out relatively quickly and easily.

The problem with stage 4 is that it requires that the expertise garnered by
the initial deployment team is spread throughout the rest of the company,
ranging from product development to the FLS desk, right through to
customers.  This is a prolonged and time-consuming process, and
consequently expensive.  I'd love to see a larger scale discussion about
this, because it's one of the main blockages for ipv6 adoption and
discussion of live cases would help other organisations make the jump.

Nick

Re: Some very nice broken IPv6 networks at Google and Akamai

[Nick Hilliard]

On 11/11/2014 15:00, Emanuel Popa wrote:
> Is there anyway to intentionally and immediately get on Google's DNS
> blacklist in order to avoid similar outages in the future affecting
> only IPv6 traffic?
> http://www.google.com/intl/en_ALL/ipv6/statistics/data/no_.txt
> 
> Or maybe the smart thing to do is building another ISP controllable
> blacklist of broken domains and tell BIND on the caches to return only
> A records for blacklisted domains. Or the other way around: only 
> records for IPv4 broken/blacklisted domains...

... or alternatively, depend on Google, Akamai and others not breaking.
This is what we do for ipv4 and it normally works well, but not always.

Bear it in mind that every time a hack is installed to work around a
potential future problem, that hack needs maintenance and if it breaks,
there's a chance that the resulting damage will be at least as bad as what
it was seeking to avoid in the first place.  Unless there are persistent
reliability problems, hacks tend not to be worth it.

Nick

Re: Some very nice broken IPv6 networks at Google and Akamai (Was: Some very nice IPv6 growth as measured by Google)

[Nick Hilliard]

On 09/11/2014 11:00, Tore Anderson wrote:
> Only if Google and Akamai are universally broken, which does not seem
> to have been the case. I tested Google from the RING at 23:20 UTC
> yesterday:

did you do a control run on a known working site?  Not all ring nodes have
working ipv6.

Nick

Re: MTU Problem: Akamai,HE,GTT

[Nick Hilliard]

On 22/09/2014 15:06, Erik Nygren wrote:

Can you pass me along a traceroute6 to 2a02:26f0:6a:18f::eed and I'll pass
it along to the Akamai NOCC?  (Or you can email details to n...@akamai.com
).  From here I'm able to ping it fine with large
packets:


scamper is your friend here:


cheesecake# scamper -I "trace -P udp -M 2a02:26f0:6a:18f::eed"
traceroute from 2a03:8900:0:100::5 to 2a02:26f0:6a:18f::eed
 1  2a03:8900:0:100::1  0.216 ms [mtu: 1500]
 2  2a02:8900:0:200::209  0.216 ms [mtu: 1500]
 3  2a01:258:8:3::1  0.634 ms [mtu: 1500]
 4  2001:1900:5:2:2::2dd9  1.053 ms [mtu: 1500]
 5  2001:1900:5:1::319  12.990 ms [mtu: 1500]
 6  2001:1900:5:1::412  12.926 ms [mtu: 1500]
 7  2001:1900:5:3::21e  11.290 ms [mtu: 1500]
 8  2001:41a8:600::1e  26.975 ms [mtu: 1500]
 9  2001:41a8:600:2::b6  27.529 ms [mtu: 1500]
10  *
11  2a02:26f0:6a::210:d9a3  25.227 ms [mtu: 1500]
cheesecake#


This means no path mtu problems from as1197 to 2a02:26f0:6a:18f::eed.

Nick

Re: SMTP over IPv6 : gmail classifying nearly all IPv6 mail as spam since 20140818

[Nick Hilliard]

On 22 Aug 2014, at 20:26, Lorenzo Colitti  wrote:
> What specifically would you like me to pass on? "Dear gmail team, can you 
> please publicly present data on IPv4 spam vs IPv6 spam in order to justify 
> your documented policy?" ?

How about: "Dear gmail team, v6 mta operators have noticed that there is a 
substantial difference between how spam detection is handled for ipv4 and ipv6 
connections and this appears to be causing problems with high rates of false 
positives on v6 sessions. These problems appear to be specific to gmail and are 
not seen with connections to other major mail operators. Where SPF/dkim are not 
feasible/possible, this causes people to either implement gmail specific hacks 
or else disable ipv6. Both these workarounds act against the interests of both 
Google and the internet at large. Can you please reach out to the ipv6 operator 
community about this?"

?

Nick

Re: SMTP over IPv6 : gmail classifying nearly all IPv6 mail as spam since 20140818

[Nick Hilliard]

On 22 Aug 2014, at 17:56, Lorenzo Colitti  wrote:
>  I'm not on the gmail team and don't have those numbers. Nick asked me for an 
> answer, and I gave him what information I have. My assumption was that since 
> they do receive a lot of email, they have statistics on this, but of course 
> you may not agree with that assumption and assume that they're just doing 
> this for whatever other arbitrary reason.

No doubt they're good at what they do, but if mta operators felt that Google's 
FP detection rate was acceptable for v6 originated mail, we wouldn't be having 
this discussion - particularly as the other major mail operators don't appear 
to have this issue. 

Nick

Re: SMTP over IPv6 : gmail classifying nearly all IPv6 mail as spam since 20140818

[Nick Hilliard]

On 22/08/2014 15:16, Lorenzo Colitti wrote:

Are you following the "Additional guidelines for IPv6" section of
https://support.google.com/mail/answer/81126 ?


Lorenzo,

it looks like Google is trying to enforce SPF / DKIM on ipv6 connections 
where there is no similar requirement for ipv4.  Is there a particular 
reason for this?  It's causing a lot of breakage.


Nick

Re: Poll on SMTP over IPv6 Usage

[Nick Hilliard]

On 17/02/2014 15:16, Ignatios Souvatzis wrote:
> Not necessarily. All I'd imagine to do with UUCP can be done with
> postfix and maybe transport tables; I've run a connection that way
> for a couple of years.

This is rapidly turning into a contest of who's admitting to the greatest
MTA horrors.

Nick

Re: So, time for some real action?

[Nick Hilliard]

On 06/02/2014 16:04, Dick Visser wrote:
> I know there are different opinions on this.
> But between black and white there are many shades of grey.
> That's why I was asking.
> I know that some stuff will break, I'm looking for ways to put this
> 'breakage' to positive use.

people don't care about ipv6.  They care about their email, their web
searches, their helpdesk access, their online bank accounts, their
mortgage, their partner and their dog.  If you cause them to lose access to
their online things, then ipv6 will stick in their mind as the thing which
caused this problem.  This is not going to be productive.

Nick

Re: So, time for some real action?

[Nick Hilliard]

On 06/02/2014 14:51, Dick Visser wrote:
> http://www.internetsociety.org/deploy360/blog/2013/12/campaign-turn-off-ipv4-on-6-june-2014-for-one-day/

This is a terrible idea which will cause IPv6 to be associated with
gratuitous breakage.

Nick

Re: Question about IPAM tools for v6

[Nick Hilliard]

On 03/02/2014 11:11, Sam Wilson wrote:
> Let me de-lurk and make the obvious point that using standard Ethernet
> addressing would limit the number of nodes on a single link to 2^47, and
> that would require every unicast address assigned to every possible
> vendor.  Using just the Locally Administered addresses would limit you
> to 2^46.

it bothers me that I can't find any switch with 2^46 ports.

Damned vendors.

Nick

Re: Question about IPAM tools for v6

[Nick Hilliard]

>> /64 netmask opens up nd cache exhaustion as a DoS vector.
> 
> FUD.

I probably should have qualified this statement a little better before
posting it.

Large locally-connected connected l2 domains can open up nd cache
exhaustion and many other problems as DoS vectors if the operating systems
connected to these domains do not have resource exhaustion limitations
built in, or they are built in but not configured properly.

In particular, the large address space prevents operating systems from
implementing certain types of mitigation mechanisms that might be possible
with ipv4 (e.g. slot based rate limiting).  The ND rate limiters that I've
tested all cause collateral connectivity problems as they place all ND
floods from all hosts in the same RL bucket.

While some aspects of this problem are more generic and not specifically
related to the address domain size (i.e. they're similar to what's already
seen on ipv4), the fact that the addressing domain is so large does not
help either the o/s implementer or the operator and the issues relating to
ND flooding of whatever sort (NS/RA/etc) are something that explicitly need
to be understood by both the o/s implementer and the network operator
because otherwise connectivity problems can occur in production.

Nick

Re: Question about IPAM tools for v6

[Nick Hilliard]

On 29/01/2014 22:19, Cricket Liu wrote:
> Consensus around here is that we support DHCPv6 for non-/64 subnets
> (particularly in the context of Prefix Delegation), but the immediate
> next question is "Why would you need that?"

/64 netmask opens up nd cache exhaustion as a DoS vector.

Nick

Re: show ipv6 destination cache on BSD host

[Nick Hilliard]

ndp -an

?

Sent from my iWotsit.

> On 30 Jan 2014, at 18:12, Matjaz Straus Istenic  wrote:
> 
> Hi list!
> 
> I'm struggling to find a way to display IPv6 destination cache on a FreeBSD 
> or UNIX (not Linux) system. 
> 
> This is the way on Linux:
> ip -6 route get 
> 
> Mac OS X:
> netstat -f inet6 -narlW
> 
> ...and Windows:
> netsh interface ipv6 show destinationcache
> 
> ...but on FreeBSD (I've tried with 9 and 10), netstat -narlW does not show 
> any entries despite the local routes. On OS X option -a does the trick, but 
> on FreeBSD I see no difference in output with or without -a.
> 
> Is there any other option for a BSD machine to figure out the Path MTU value 
> for a certain IPv6 destination? OK, except tcpdump, of course ;-).
> 
> Any hint is appreciated!
> Thanks!
> 
> Kind regards,
>Matjaž

Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?

[Nick Hilliard]

On 23/01/2014 00:03, Francis Dupont wrote:
> => recvfrom() returns the peer address, i.e., the source address of
> the request, when you need the local address, i.e., the destination
> address.

I was thinking of recvmsg(), as someone else pointed out.  It's been way
too long since I've looked at any of this.

> => I'd like to say VRRP needs to be fixed but here the reasonable
> solution is to be notified...

it's implementation specific.  There's nothing in the rfc to say that you
can or can't have the virtual ip address configured on a dummy interface on
all vrrp boxes; only that the VIP should not answer to ARP requests on the
backup units.  Some implementations swap the VIP between the primary and
backup devices; others nail it up and do clever arp tricks.

Also the same issue relates to any FHRP, e.g. CARP which is specifically
aimed at service based failover in order to avoid the patent issues
relating to USPTO #5473599, because VRRP does network failover and CARP
does services failover and obviously they're completely different amirite.

Nick

Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?

[Nick Hilliard]

On 22/01/2014 17:15, Mateusz Błaszczyk wrote:
> put a load-balancer in front of it.

I would do this in an instant if I had an option to do it.

> vrrp is for network failover.

it's for ip address failover.

Nick

Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?

[Nick Hilliard]

On 22/01/2014 16:54, Francis Dupont wrote:
>  - there is no standard/portable way to do this without the one
>   socket per address in IPv4 (if you need an argument, just ask what
>   this discussion is about :-)

i thought recvfrom() fixed this issue?  Forgive me if I'm wrong here - it's
been far too long since I've done any socket related stuff.

> => BIND polls from time to time interfaces to bind() to new addresses
> (again, there is no standard/portable way to be notified. BTW we (ISC)
> know this is a point which can be improved so if you know a generic
> simple solution...)

server.c:load_configuration() has:

interface_interval = cfg_obj_asuint32(obj) * 60;

which means that the granularity for interface rescanning is per-minute.
I'm not suggesting that per-second rescan would be a good idea, but
per-minute is too long for workable failover with vrrp.

Nick

Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?

[Nick Hilliard]

On 20/01/2014 17:21, Philipp Kern wrote:
> Can't you simply set up the VIP on the dummy interface and then direct
> traffic to the box as needed, making sure that you don't answer ARP
> requests for the dummy address in the kernel?

this is getting off topic quite a bit.  I didn't try that, but wouldn't
especially expect it to react well with ucarp or keepalived.

Nick

Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?

[Nick Hilliard]

On 20/01/2014 17:12, Simon Perreault wrote:
> IIRC, recent versions of Bind open a socket per address on IPv4

this feature was one of the main reasons I stopped using BIND.  It has the
side effect that you cannot necessarily set it up on a system which shares
IP addresses using e.g. VRRP, because you cannot be guaranteed that the
system will have the virtual IP address configured at the time that BIND
starts.  Frustrating.

Nick

Re: RA & DHCP problem...

[Nick Hilliard]

On 30/12/2013 11:31, Mikael Abrahamsson wrote:
> Why would one want to build huge L2 domains? It's a lot of pain, and there
> is no address limitation that means you "must" do this.
> 
> What's the use-case that requires large L2 domains as the "best" solution?
> And on top of that, that requires different hosts within this L2 domain to
> have different default gateways?

This is a different issue and slightly unrelated to the issue of RAs and
DHCPv6, but as you asked there are two conflicting problems here: if you
have large l2 domains, you run into problems with implementing RA guard and
dhcpv6 guard at the customer edge but in general routers cope better with
this scenario.  If you have one l2 domain per customer, you run into
problems with routers generating sets of VRRP/whatevs packets per customer,
but you have no issues with rogue RAs/DHCPv6 because the customer will only
hurt themselves.  This isn't a problem which will affect smaller networks,
but if you scale up to thousands of customers, many routers will not handle
the VRRP requirements for that many l2 domains.  You could use larger
numbers of smaller routers, but then you lose economy of scale.

Nick

Re: RA & DHCP problem...

[Nick Hilliard]

On 29/12/2013 20:48, Lorenzo Colitti wrote:
> Is the size an issue here? Is there something about having tens of
> thousands of IPv6 hosts that makes RAs unsuitable?

yes, size is an issue: it means that tweaking ns-interval is not feasible
as a mechanism for dropping failover times.  It also means that whatever
solution is put in place needs to scale well

Separate to this, it would be ideal to have host autoconfiguration both
centrally managed and have a single configuration mechanism because doing
it any other way is a pain.  For me, that is.  If you want to run
medium-scale deployments like this with host autoconfiguration stuff in
multiple places, then I'm ok with that because it's your network and I
don't mind.

> The alternative is to advertise RAs at the rfc-specified minimum interval
> of 3s, giving a failover time of 10s.  This isn't compatible with many
> business cases.
> 
> Why 10s? Have two routers send out RAs every 3 seconds and give them a
> lifetime of 5 seconds. That should give you maximum 5s failover (average
> 2.5s), because after 5s the RA will expire.

and if your hosts miss a packet, you get traffic swinging to your other
default.  You may like to debug this sort of thing, but I operate in
companies with non-telephone number cost constraints and have a strong need
for operational simplicity and consistency.

In other words, I don't want to set my network up with a default gateway
that times out by policy every 5s because that is not a stable configuration.

There's another issue: my intended deployment scenario is medium-scale
third party vm hosting.  If you have routers churning out RA packets, each
host needs to process these packets simultaneously across all vms, network
wide.  This will increase cpu usage and resident memory requirement, maybe
not by much per host, but bear in mind that this is intended to scale
across tens of thousands of hosts.

> The operator can drop a protocol, but the host implementer needs to
> handle

yep, exactly, but please bear in mind that networks are provisioned by
operators for end-users.  Network stacks are not written by host
implementers for their own gratification.

> 4. there is no way for RAs to deploy different gateways to different 
> hosts:
> all hosts on the network must be configured in the same way.
> 
> You can use unicast RA replies for that.

doesn't scale.  Routers are routers, not policy management engines.  DHCP
is for policy management and there is just no scalable way of handling this
on routers.

> 5. there is no way to specify anything other than a default gateway.
> 
> What do you mean? If you mean there's no way to configure more specific
> routes, RFC 4191 has allowed that since 2005.

As Phillipp Kern kindly pointed out, I got this wrong.

> 6. the failover characteristics of RAs are very poor by modern standards.
> 
> 
> DHCP doesn't help there. If you want better than that, you need to use
> something like VRRP anyway.

Yes, I know:  DHCPv6 + a first-hop routing protocol.  This is the scenario
I am interested in deploying.  You know what?  It works really well in
practice.

Nick

Re: RA & DHCP problem...

[Nick Hilliard]

On 29/12/2013 13:12, Philipp Kern wrote:
> that's basically what I said. I added the additional point that the DHCP
> server gives out different gateways for load balancing reasons.

Right, I just misunderstood what you were saying.

>> No, you can't do tightly timed failover with RAs […]
> 
> How would you make that work with DHCPv6? Isn't that also MAC failover
> which you refuse to consider for RAs?

Let me be more specific: you can only do tightly timed failover with RAs if
you announce a virtual IP address which is tied to a first-hop redundancy
protocol like vrrp/hsrp/etc.  This is a vendor specific thing and is not
even supported by many vendors.

You cannot depend on the built-in mechanisms in RA and NUD to perform fast
failover because you end up with a choice of either 10+ second failover or
else compromising your network structure due to excess icmpv6 NS packets.
Neither of these are workable solutions in production networks.

If you want fast failover, you need to use vrrp / hsrp / carp / etc, all of
which provide mac failover at layer 2.  In this situation, you need a
mechanism to deliver the default gateway information to the client.  At the
moment, the only standardised option is manual configuration.  This doesn't
scale.

> You would still have ND. And it's all part of ICMPv6, so you don't avoid
> "an entire protocol" unless you specify a target MAC to send traffic to.

icmpv6 is a large pot of protocols which do many different things.  RA is
one subsection which delivers a specific set of services, and I usually
consider it to be a separate protocol in its own right.

>> 3. there is no way of specifying a global unicast ipv6 address.  You can
>> only specify link-local addresses.
> 
> True. But you are talking about large L2 domains, which have link-local
> addressing. What's wrong with that?

I'm just saying it's not possible to deploy global unicast addresses using
RA.  Maybe this doesn't matter to you.  It's not that important to me
either, but it may be important to some people with different network
structures.  Personally, I don't like the idea of unreasonable restriction
of options when it comes to configuring networks.

>> 5. there is no way to specify anything other than a default gateway.
> 
> RDNSS is there, but not arbitary data, that's true. Yes, the big iron

no, I meant that there is no other way to specify routing information other
than a default route.  E.g. if you have a box with two NICs; management
network on one NIC and production on the other, there is no way to get
dhcpv6 to instruct the client to hand off management traffic to one network
and everything else to the production side.  RDNSS I don't care about.

Nick

Re: RA & DHCP problem...

[Nick Hilliard]

On 29/12/2013 11:55, Gert Doering wrote:
> Uh.  And you seriously claim getting vendors to implement *that* is
> harder than getting universal "no-RA-but-DHCPv6" implementations into
> the client stacks?

Time to delivery is not an argument that we shouldn't do something.  I
would much prefer to depend on something which took longer to deliver but
was fully standards compliant across all vendors rather than depending on
vendor hacks which might or might not be supported, depending on phase of
moon / the specific FHRP used / etc.

Separately, in terms of vendor support for this sort of thing,
dibbler-dhcpd already supports a nonstandard default route mechanism.  The
ISC people appear enthusiastic to support it in their product (one of the
authors of draft-ietf-mif-dhcpv6-route-option works with the ISC). And if
you look at previous authorships for some of the previous IDs, you'll see
other vendor names like Huawei and Cisco.  I haven't talked to the
microsoft people.

Nick

Re: RA & DHCP problem...

[Nick Hilliard]

On 29/12/2013 11:18, Gert Doering wrote:
> which is total crap, as HSRP/VRRP 
> work perfectly fine with RAs sourced from the virtual IP

this is a vendor-specific thing which is not universally supported.

Nick

Re: RA & DHCP problem...

[Nick Hilliard]

On 28/12/2013 15:07, Philipp Kern wrote:
> how do these deployments look like?

large.  Either small numbers of very large l2 domains or else large numbers
of l2 domains with lots of hosts.  In either case, the use case is tens of
thousands of ipv6 hosts.

> Because the granuality is generally
> per broadcast link and I don't think we are talking about multiple
> routers on one broadcast domain with the DHCP server doing the load
> balancing?

I don't know what you mean here.  I'm talking exclusively about networks
with multiple gateways with a requirement for tightly timed failover.

> You still need ND for tightly timed failover or you switch the MAC
> address somewhere else

No, you can't do tightly timed failover with RAs - it's not possible within
the terms of the minimum timers specified in the docs.  The minimum
possible failover time using RA is about 6 seconds by tweaking the NS
interval, and that's assuming you set the NS reachable timer = 1000ms and
the retransmit timer = 100ms.  Both of these are operationally dubious
because they make your network scale according to the number of hosts on
your network rather than the number of l2 domains.  This doesn't matter on
granny's home dsl network; it matters very much at large scale.

The alternative is to advertise RAs at the rfc-specified minimum interval
of 3s, giving a failover time of 10s.  This isn't compatible with many
business cases.

> why is RA a bad thing here? (As you can
> advertise the VRRP IP or VIP in it, for instance).

There are two intertwined issues here: 1. why RA is a poor choice in
certain situations and 2. why DHCPv6 is a better choice in these situations.

1. running RA+DHCPv6 is running two protocols to handle autoconfiguration,
which is not particularly compatible with the KISS principal because two
protocols is by necessity more fragile than operating with just one.  If
alternatively dhcpv6 were able to provide a defgw option, we could drop an
entire protocol.

2. two protocols is inherently more difficult and therefore expensive to
debug than one.

3. there is no way of specifying a global unicast ipv6 address.  You can
only specify link-local addresses.

4. there is no way for RAs to deploy different gateways to different hosts:
all hosts on the network must be configured in the same way.

5. there is no way to specify anything other than a default gateway.

6. the failover characteristics of RAs are very poor by modern standards.

Nick

Re: RA & DHCP problem...

[Nick Hilliard]

On 28/12/2013 14:12, Mikael Abrahamsson wrote:
> Why? What problem are you solving by changing the current behavior?

RAs don't work for some situations, specifically for those people who have
requirement for tightly timed failover, and for people who are planning or
running very large ipv6 deployments.  For these cases, it is more sensible
to have a statically defined gateway address and to use a mechanism like
DHCP to assign the gateway.

At the moment, there is no option to do this, so the two options for
handling default gateway assignment are: 1) via RAs or 2) manually via
autoconfig scripting, if you have access to the CE device.

No-one is suggesting removing RAs.

Nick

Re: RFC 5952 converter tool

[Nick Hilliard]

On 27/11/2013 22:28, Nick Hilliard wrote:
> inet_ntop(3) is the canonical function for this.  Make sure your byte order
> is correct.

should be more helpful here: see the attached code.  usage:

> pancake:/home/nick> gcc -o convert convert.c
> pancake:/home/nick> ./convert 2001:0DB8::0001
> 2001:db8::1
> pancake:/home/nick> ./convert 2001:0DB8::192.168.1.1
> 2001:db8::c0a8:101
> pancake:/home/nick>

Both inet_pton() and inet_ntop() needs return value checking, but otherwise
you should get the idea.

Nick

#include 
#include 
#include 

int main(int argc, char **argv)
{
  char *addr;
  char buffer[INET6_ADDRSTRLEN+1];
  struct sockaddr_in6 sa;

  if (argc == 2) {
addr = argv[1];
  } else {
addr = "2001:7f8:0:0::1:1";
  }

  inet_pton (AF_INET6, addr, &(sa.sin6_addr));
  inet_ntop (AF_INET6, &(sa.sin6_addr), buffer, INET6_ADDRSTRLEN);

  printf("%s\n", buffer);
}

Re: RFC 5952 converter tool

[Nick Hilliard]

On 27/11/2013 20:43, Leo Vegoda wrote:
> Can anyone recommend a library or other tool, preferably open source,
> that can take non-RFC 5952 formatted IPv6 addresses and convert them to
> a compliant format?

inet_ntop(3) is the canonical function for this.  Make sure your byte order
is correct.

Nick

Re: Over-utilisation of v6 neighbour slots

[Nick Hilliard]

On 22/10/2013 17:18, Sam Wilson wrote:
> It's stuff like this that makes me think it's *still* not time to offer
> a general v6 service.

generally, the sup720 is not a good edge device for third party L3 services
due to rate limiter issues.

Nick

Re: PTR records for IPv6

[Nick Hilliard]

On 03/09/2013 13:46, Marco Sommani wrote:
> On 03/set/2013, at 14:38, m...@linux.it (Marco d'Itri) wrote:
>> On Sep 03, Mikael Abrahamsson  wrote:
>>
>>> Mostly because it's on by default. Even if you configure a static
>>> address and default gw, as soon as the system sees RAs it might
>>> start to use SLAAC based privacy addresses for outgoing connections.
>> This is clearly a misconfiguration.
> 
> You are free to say that this is a misconfiguration, but on Windows, OSX
> and iOS it is the default.

OTOH, windows, OS/X and iOS usually don't provide mail relay service.

It's arguably the correct configuration for desktop boxes.  It's
categorically a stupid configuration for servers, which is made worse by
the fact that it's troublesome to disable on linux (client side) and
several varieties of cisco IOS).

Nick

Re: Sunsetting Teredo Experiment [IETF slides]

[Nick Hilliard]

On 04/08/2013 13:28, Sander Steffann wrote:
> Well, I am on that list, so the barrier is not *that* high ;-)

maybe not.  I'm just puzzled as to why a fully closed list is necessary -
moderated subscription is one thing, but non-searchable archives is surprising.

Nick

Re: Sunsetting Teredo Experiment [IETF slides]

[Nick Hilliard]

On 02/08/2013 17:34, Guillaume Leclanche wrote:
> If you mean v6ops at ietf.org , it is not a closed list,
> subscription is open. But it is ruled by IETF rules for contributions. I
> even thought you were a member actually.

I think he meant:

http://lists.test-ipv6.com/mailman/listinfo/v6providers

This seems to be a closed access list for v6 providers, but only
significant ones.  If you're anything other than significant, apparently
you don't qualify.

Nick

Re: Avoiding EUI64 addresses on Ubuntu 12.04

[Nick Hilliard]

On 22/05/2013 14:41, Dick Visser wrote:
> This is a server, and I don't want privacy/security extensions, just
> the manually configured address.

yeah, this is annoying.  I use the following:

--
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.accept_ra_defrtr = 0
net.ipv6.conf.default.accept_ra_rtr_pref = 0
net.ipv6.conf.default.accept_ra_pinfo = 0
net.ipv6.conf.default.accept_source_route = 0
net.ipv6.conf.default.accept_redirects = 0
net.ipv6.conf.default.forwarding = 0
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.accept_ra_defrtr = 0
net.ipv6.conf.all.accept_ra_rtr_pref = 0
net.ipv6.conf.all.accept_ra_pinfo = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.all.forwarding = 0
--

No doubt a pile of this is redundant, but it does what I want and it is as
easy to push 15 lines of config to all servers as it is to push 2.

Nick

Re: DHCPv6 accounting

[Nick Hilliard]

On 21/05/2013 13:00, Liviu Pislaru wrote:
> With DHCPv6 i didn't find a way to do that (identify what IPv6 is allocated
> to which customer) without asking any additional information from the
> customer (like DUID).

apparently this is a feature, not a bug.

Nick

Re: outlook.office365.com broken via IPv6

[Nick Hilliard]

On 30/04/2013 20:43, Daniel Roesen wrote:
> given that Christopher Palmer is on this list, I doubt NANOG ml would
> be more helpful. CC'ing him for attention. :-)

Looks like there might be a broken load balancer in there somewhere.
Several of the addresses are returning periodic failures which fluctuate
quickly between up and down:

> nmap -6 -sT -p 443 `host -t  outlook.office365.com | grep address | awk 
> '{print $5}'`

Nick

Re: RA Guard support...

[Nick Hilliard]

On 02/05/2013 15:37, Steve Simlo (ssimlo) wrote:
> IPv6 FHS feature matrix located here: 
> 
> http://iwe.cisco.com/web/nostg/cisco-software-roadmaps-and-features

this seems to be a cisco internal web site.

> Also please see:
> 
> http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/15-2mt/ip6-ra-guard.html
> 
> Please let me know if that does not answer your query ?

At the moment, it's supported on

12.2(33)SXI4:   C6500 / C7600 with PFC3
12.2(50)SY: SUP2T (much better implementation than on pfc3)
12.2(54)SG: C4500E + sup6E/6L-E, C4900M, C4948E
15.0(2)SE:  3750X/3750E/3560X/3560E
15.2(4)S/M: C7600
IOS-XE Release 3.2SE

more on: http://docwiki.cisco.com/wiki/Cisco_IOS_IPv6_Feature_Mapping

Nick

Re: outlook.office365.com broken via IPv6

[Nick Hilliard]

On 30/04/2013 20:43, Daniel Roesen wrote:
> given that Christopher Palmer is on this list, I doubt NANOG ml would
> be more helpful. CC'ing him for attention. :-)

he's escalated the case internally already (thanks Christopher!)

Nick

Re: A simple test for email via IPv6

[Nick Hilliard]

On 30/04/2013 12:47, Ted Mittelstaedt wrote:
> In short, your a hypocrite.

Ted,

Can I humbly suggest that if you're going to rant from your ivory tower on
a public mailing list, that at least you get your grammar correct?

Alternatively, you could keep your insults to yourself.

Nick

Re: enterprise IPv6 only client computers and IPv4 connectivity

[Nick Hilliard]

On 30/04/2013 11:24, Bernhard Schmidt wrote:
> - Someone advertises  records that fail to connect. See for example
> https://outlook.office365.com that has had broken IPv6 for weeks now.

Would megaphone diplomacy work here?  I.e. posting to nanog.

Nick

Re: IPV6 in the network core and MPLS

[Nick Hilliard]

On 12/04/2013 20:01, Ivan Pepelnjak wrote:
> Loads of self-promotional nonsense. What he's saying is "Gee, we need LDPv6
> and we'll try to make an RFC out of it". Wow.

uh, it's a blog.  what do you expect? :-)

-n

> =
> Mistyped and autocorrected on a clunky virtual keyboard
> 
> On 12. apr. 2013, at 20:54, Jim Small  > wrote:
> 
>> This is the only thing I recall seeing from Cisco (Blog Entry) – also
>> took a quick look through Cisco Live 365 site and didn’t see anything…
>>
>> http://blogs.cisco.com/getyourbuildon/moving-networks-to-ipv6-mpls-bye-bye-ipv4-mpls/
>>
>>  
>>
>> --Jim
>>
>>  
>>
>> *From:*ipv6-ops-bounces+jim.small=cdw@lists.cluenet.de
>> 
>> [mailto:ipv6-ops-bounces+jim.small=cdw@lists.cluenet.de
>> ] *On Behalf Of *Ivan Pepelnjak
>> *Sent:* Friday, April 12, 2013 6:37 AM
>> *To:* 'Jim Trotz'; ipv6-ops@lists.cluenet.de
>> 
>> *Subject:* RE: IPV6 in the network core and MPLS
>>
>>  
>>
>> If you want to use MPLS, you still need IPv4 core. None of the major
>> vendors (that I’m aware of) support LDPv6 or VPNv4 with IPv6 next hops
>> ... Of course I hope someone will jump in and correct me ;)
>>
>>  
>>
>> Best,
>>
>> Ivan
>>
>>  
>>
>> *From:*ipv6-ops-bounces+ipepelnjak=gmail@lists.cluenet.de
>> 
>> [mailto:ipv6-ops-bounces+ipepelnjak=gmail@lists.cluenet.de] *On
>> Behalf Of *Jim Trotz
>> *Sent:* Friday, April 12, 2013 12:20 PM
>> *To:* ipv6-ops@lists.cluenet.de 
>> *Subject:* IPV6 in the network core and MPLS
>>
>>  
>>
>> I have been trying to find out if we can use MPLS & LDP to setup MPLS
>> VPNS within our all IPV6 network. Everything I read says no, LDP & MPLS
>> don't support native IPV6, you have to use 6VPE and IPV4 in the core.
>>
>> Is this true?  PS: We are an all Cisco IOS/NXOS based network.
>>

Re: Microsoft over IPv6?

[Nick Hilliard]

On 28/03/2013 15:01, Chris Conn wrote:
> most likely the reason that Skype still has no IPv6 support :P Figures
> Microsoft would try to use something broken like 6to4. Maybe they are
> trying to prove a point?

looks like a fossil that someone forgot about.  Never put anything down to
malice...

Nick

Re: BCP38 is not just for IPv4

[Nick Hilliard]

On 28/03/2013 11:01, Mike Jones wrote:
> To throw a small data point out there, I have had several server/VPS
> providers who all (but one) performed filtering on v4, but nearly all
> forgot it with v6 (some have since done it).

As always, beware hardware limitations (i.e. looking at sup720 / rsp720 in
particular).  ACLs only for ipv6 urpf on this platform.

Nick