Re: IPv6 plan for multisite corporate

[Eric Vyncke (evyncke)]

Several US companies (including my employes) simply use the same ARIN prefix 
everywhere and inject local routes at each WW locations. As long as the prefix 
length is short enough, there will be no issue about routing or about RIR.

-éric

On 21/05/18 06:47, "ipv6-ops-bounces+evyncke=cisco@lists.cluenet.de on 
behalf of Luigi Rosa"  wrote:

Hi,
one of my customer is a US corporate with offices literally on 5 continents 
and 
one datacentre. Offices are connected each other and to the datacentrevia 
MPLS, 
each office accesses the Internet via local ISP.

Since they asked me to start planning for IPv6, my idea was originally to 
buy a 
netblock from ARIN (maybe a /40) and use it for the offices (each office 
has 
many different IPv4 networks).

My concern is: if I buy a netblock from ARIN and use it in every office, 
how can 
I handle the access to local ISP?

I thing I should NAT the netblock of each office to handle the routing, or 
is 
there some other way to do so?

Thanks!


-- 


Ciao,
luigi

/
+--[Luigi Rosa]--
\

Air conditioned environment.
Do not open Windows!

Re: ip switching from ipv4 to ipv6

[Eric Vyncke (evyncke)]

See also 
https://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie-01

Kind of a well-known problem when "naive" applications/CMS/middleware
trust an IP address to protect cookies

-éric

On 29/04/16 14:46, "ipv6-ops-bounces+evyncke=cisco@lists.cluenet.de on
behalf of re"  wrote:

>dear ipv6-ops list members,
>
>one of our users is unable to login to webmail, because the ip address is
>changing during session. this problem isnt that unusual, but after a check
>in the logfiles i realized its switching from ipv4 to ipv6 and so on,
>(see below).
>
>is this phenomenon known?
>is it us or the deutsche telekom who is causing the problem?
>
>thanks in advance,
>re - noc.mur.at
>
>#
>
>Apr 29 09:54:34  dovecot: imap-login: Login: user=<>, method=PLAIN,
>rip=217.233.160.66
>
>Apr 29 09:57:54  dovecot: imap-login: Login: user=<>, method=PLAIN,
>rip=2003:88:6c55:4707:b538:efe9:d4fb:bdf7
>
>Apr 29 10:05:17  dovecot: imap-login: Login: user=<>, method=PLAIN,
>rip=217.233.160.66
>
>Apr 29 10:05:19  dovecot: imap-login: Login: user=<>, method=PLAIN,
>rip=2003:88:6c55:4707:b538:efe9:d4fb:bdf7
>
>Apr 29 11:29:03  dovecot: imap-login: Login: user=<>, method=PLAIN,
>rip=217.233.160.66
>
>Apr 29 11:45:09  dovecot: imap-login: Login: user=<>, method=PLAIN,
>rip=2003:88:6c55:4707:b538:efe9:d4fb:bdf7
>
>-- 
>--mur.at leitnergasse 7-12 8010 graz--

Re: MTU/MSS testing IPv6

[Eric Vyncke (evyncke)]

See also RFC 6946 on this topic and the more controversial
draft-ietf-6man-deprecate-atomfrag-generation

-éric

On 29/04/16 08:43, "ipv6-ops-bounces+evyncke=cisco@lists.cluenet.de on
behalf of Seth Mos"  wrote:

>Op 29-4-2016 om 8:30 schreef Mikael Abrahamsson:
>> Hi,
>> 
>> Site B which sends all data packets as fragments. This is most likely
>> because they have some kind of AFTR where the IPv4 side has MTU1500 and
>> the IPv6 side has MTU1320 or something like that.
>
>The site cbs.nl does this as well. It's the statistics agency for the
>Netherlands. They use a Juniper with IPv4 to IPv6 translation, however,
>it sets the frag attribute for all packets including the ACK.
>
>I've had extensive debugging to find out what was going wrong.
>Eventually I found that our firewall was dropping IPv6 fragments, making
>the website unreachable over IPv6.
>
>The RFC for this translation mode was followed literally, so it could be
>argued that this is "to spec".
>
>Neither Juniper nor the website owner was willing to make any changes
>(and make it reachable for anyone that dropped frags, it wasn't just
>us). They could have just used a proxy or load balancer to terminate the
>connections instead of relying on a passive NAT and not have any of
>these problems.
>
>Cheers,
>
>Seth

Re: Slow WiFi with Android Marshmallow & IPv6?

[Eric Vyncke (evyncke)]

AFAIK, they were announcing the same IPv6 RDNSS over RA & DHCPv6... But
Android was the only OS to stick to IPv6 RDNSS (again my guess)

-éric

On 25/04/16 18:01, "Bjørn Mork"  wrote:

>Lorenzo Colitti  writes:
>> On Tue, Apr 26, 2016 at 12:48 AM, Bjørn Mork  wrote:
>>
>>> I assume you meant RFC 6106 :)
>>>
>>> But why would this problem affect only Android?  And why only a very
>>> specific Android version?  That doesn't compute...
>>>
>>
>> Windows doesn't support RDNSS. Apple prefers IPv4 DNS servers.
>>Therefore,
>> if the ISP breaks an RDNSS-announced server, it must be a bug in
>>Android.
>> QED :-)
>
>Ah, OK. So they weren't announcing the same DNS resolvers via DHCPv6?
>Was this deliberate, or just a typo in the RA config?
>
>
>Bjørn

Re: Slow WiFi with Android Marshmallow & IPv6?

[Eric Vyncke (evyncke)]

Jeroen, Erik and John,

Thanks for the hint. I will advise the ISP to investigate any DNS issue (such 
as not returning an error message when requesting a non-existing ) but I 
wonder why it is linked to that specific Android Marshmallow version.

-éric

From: 
<ipv6-ops-bounces+evyncke=cisco@lists.cluenet.de<mailto:ipv6-ops-bounces+evyncke=cisco@lists.cluenet.de>>
 on behalf of "Brzozowski, John Jason" <j...@jjmb.com<mailto:j...@jjmb.com>>
Date: Sunday 24 April 2016 at 16:01
To: Erik Kline <e...@google.com<mailto:e...@google.com>>
Cc: Jeroen Massar <jer...@massar.ch<mailto:jer...@massar.ch>>, IPv6 Ops list 
<ipv6-ops@lists.cluenet.de<mailto:ipv6-ops@lists.cluenet.de>>
Subject: Re: Slow WiFi with Android Marshmallow & IPv6?

My customers saw this issue at one point.  We had issues with DNS over IPv6.  
Bad DNS and/or network configurations.  Once these were fixed, the problems 
cleared up.

On Sunday, April 24, 2016, Erik Kline <e...@google.com<mailto:e...@google.com>> 
wrote:
On 24 April 2016 at 19:53, Jeroen Massar <jer...@massar.ch<javascript:;>> wrote:
> On 2016-04-24 11:51, Eric Vyncke (evyncke) wrote:
>> One of the first Belgian ISP to deploy IPv6 (VOO) is now recommending to
>> its Android Marshmallow (6.0.1) users to deactivate IPv6 on their
>> residential WiFi CPE... :-(
>>
>> It appears that the issue is about IPv6 web sites/apps being really
>> slower when using IPv6.
>
> Is it a DNS issue maybe?
>
> https://www.sixxs.net/faq/dns/?faq=ipv6slowconnect
>
> As that has been the general cause of "Disable IPv6!" around the
> world for many years already.
>
> Of course, without more details, little one really can say. Bug number
> maybe?
>
> Greets,
>  Jeroen
>

Yeah, a link to something that eventually leads to a bug report would be good.

Also if anybody has adb installed they can just try "adb shell dumpsys
connectivity --diag" and see what the over-simplified diagnostic
output shows.

Re: Curious situation - not urgent, but I'd like to know more

[Eric Vyncke (evyncke)]

Interesting situation indeed :-)

As we all known, Microsoft DirectAccess uses IPsec over IPv6 (and
potentially over Teredo or SSL-VPN if the host does not have native IPv6).
So, if your DirectAccess head-end is dual-stack, it now receives Ipsec
packets over IPv6 rather than HTTLS or Teredo over IPv4, so, firewall
settings must be tuned for that.

Now, I am really puzzled by your sentence "his Comcast-installed router
was handing our IPv6 addresses on his home LAN", is it a typo in 'our'
rather than 'out' ? It would be interesting to see the
addresses/prefixes/routes of the failing DirectAccess client as well as
which IPv6 address.prefix is used by DirectAccess for the
normally-functionning clients.

-éric


On 19/12/15 22:37, "ipv6-ops-bounces+evyncke=cisco@lists.cluenet.de on
behalf of Kurt Buff"  wrote:

>All,
>
>I ran into an interesting situation some months ago which still
>baffles me, and though I was able to work around it, I expect it will
>happen again.
>
>We implemented MSFT DirectAcess at our company quite some time ago
>(using 2008R2 and Forefront 2010), and it works extremely well.
>
>At least it worked well for everyone until one of the employees got
>his Comcast connection upgraded, and then DirectAccess didn't work for
>that employee any more.
>
>We proved that if he tethered to his cell phone, that would work, and
>if he used an SSL VPN client while on his Comcast connect that would
>work, but DirectAccess would not work at home.
>
>Finally, I discovered that his Comcast-installed router was handing
>our IPv6 addresses on his home LAN. Turning that off enabled
>DirectAccess to work again.
>
>We do not have an assigned IPv6 block from our ISP, though of course
>MSFT OSes use it, and auto-assign themselves addresses, but for now
>we're ignoring it.
>
>Has anyone run into this problem and solved it - not by turning off
>iIPv6 address assignment for the home LAN, but really solved it? If
>so, how did you do that?
>
>Would getting and implementing an IPv6 assignment from our ISP cure
>the problem, or make it worse?
>
>I've found little guidance from MSFT about DirectAccess in an IPv6
>environment, though I admit I haven't been terribly diligent in my
>searches.
>
>Kurt

Re: [v6ops] Why operators filter IPv6 packets with extension headers?

[Eric Vyncke (evyncke)]

Fernando et al.,

A couple of quick comments:

- this reminds me of taylor-v6ops-fragdrop (which you cite at the end),
did you approach any of this old I-D authors?

- not sure whether the security implications should be re-stated again in
this document, let's rather split the security & operational issues into
two documents

- in the introduction, 'widespread implementation limitations' is probably
too strong (and I agree that my employer products could do better)

- in the introduction, "intentionally dropped" ? I am afraid that some
drop are not intentional

- I would shorten a lot the section 3 (security implications) and simply
put a lot of references to existing good documents of yours and others

- I like section 4 (operational implications) but it does not match the
title, it is more about why transit operators have to look at layer-4

- section 4 approaches the goal described in the abstract but actually
only provide clues why operators intentionally (or non intentionally)
drops packets with EH. For example, being unable to do ECMP is of course
an operational impact but why would it be the cause of EH drop?

- section 4.1 (iACL), beyond the permit/deny, some operators also rate
limit some traffic such pings

- section 4.1, perhaps worth mentioning that infrastructure ACL are more
in the white list approach, i.e., what is not BGP/ICMP (in your example)
to some prefixes is dropped, so, if someone uses EH to obscure the
traffic, this EH traffic matching the destination prefix is dropped anyway
by the ACL (so iACL works) but traffic destined to other destination is
not impacted. Or did I got something wrong?

- section 4.2 (route processor protection) is a little unclear

- the processing of HbH would kill the Internet of course (at least with
most routers), should HbH be separately called?

- section 4.3 (DDoS mitigation), I am unsure about FlowSPec but can it
also specify 'any traffic with EH' ? This would do the trick probably for
dropping or diverting the DoS packets?

- missing issue is lack of granular EH control by some routers, for
example if an operator wants to block its subscribers RH-0 but can only
drop RH (because RH type cannot be specified), then all RH are dropped
including MIPv6

- section 5 (potential attack vector) appears to be focus on fragment drop
by the public Internet. While it can probably work, the issues are
twofold: 
1) bad host implementations not doing enough tests before accepting a ICMP
packet-too-big 
2) public Internet dropping valid fragments in transit
In both cases, we (the industry, vendors + operators) need to fix those
two issues.


May I STRONGLY suggest to remove all security issues (other docs are
describing this) and focus only on the operational issues (esp in V6OPS) ?
And skip any discussion on the rationale why packets with EH are dropped?


Hope this helps to refine a potentially useful I-D.



-éric


On 1/09/15 03:17, "v6ops on behalf of Fernando Gont"
 wrote:

>Folks,
>
>The topic of operators dropping IPv6 packets containing extension
>headers has been raised quite a few times on this list and elsewhere.
>
>A month ago or so we published a document trying to summarize the
>reasons for which operators filter IPv6 packets containing extension
>headers. The document is available at:
>
>
>We're currently working on a revision of this document, and would like
>to hear feedback from the working group regarding our document. e.g.,
>
>* Did we get anything wrong?
>* Is there anything missing?
>
>Or, if you like the document and agree with its content, that's also
>interesting feedback to have.
>
>Thanks!
>
>Best regards,
>-- 
>Fernando Gont
>e-mail: ferna...@gont.com.ar || fg...@si6networks.com
>PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>___
>v6ops mailing list
>v6...@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops

Re: SV: Samsung phones block WiFi IPv6 when sleeping, delayed notifications

[Eric Vyncke (evyncke)]

Please read some IETF draft related to NDP/multicast/WiFi issues (Lorenzo
is very active there).

Multicast RA are not really needed anyway, some 'high market' (see my
email address) AP have dozens of tricks to reply to RS with a UNIcast RA,
and trying to reduce the amount of NDP mcast.

If you want to measure by yourself: https://github.com/evyncke/mcast6
which will display basic summary of all your mcast IPv6 traffic.

And bear in mind that every WiFi mcast frame wakes up ALL your WiFi device
and is sent at the lowest rate (wasting bandwidth) ;-)

On 10/06/15 02:20, erik.tarald...@telenor.com
erik.tarald...@telenor.com wrote:

  I see that. I don’t think the problem is confined to Samsung or that
it can be completed solved in isolation from fixing wireless AP router
behaviour.
 At the edge of the WiFi network I also see the IPv6 connectivity
dropping while IPv4 stays up. I’ve a ZyXEL home router that sends
periodic RAs every 15 seconds
 and a Huawei home router that sends them every 1800 seconds.

Any opinions on what a sane default value for what the RA interval should
be?  I have not conserned myself with that interval before, but I see
that the residential devices we ship are on a very low interval.


--
Erik Taraldsen

Re: Google no longer returning AAAA records?

[Eric Vyncke (evyncke)]

And you are not alone... While my employer has deployed a lot of IPv6
internally (still not 100% though), some internal DNS servers are
blacklisted by Google. Probably because a lot of our internal labs (which
are also IPv6-enabled of course) are managed by the engineers using the
lab, so, ending up in less than optimal IPv6 configuration in same case
(when the lab has nothing to do with the IP layer = mine is optimized for
IPv6 :-) )

-éric

On 15/04/15 21:16, Brian Rak b...@choopa.com wrote:

On 4/15/2015 11:28 AM, Phil Mayers wrote:
 On 15/04/15 16:05, Brian Rak wrote:
 We noticed that we're no longer getting  results back for
google.com
 when we do queries from a few of our recursive servers (other ones are
 fine).

 A bit of searching revealed that a few of our servers are listed here
 http://www.google.com/intl/en_ALL/ipv6/statistics/data/no_.txt
 (there are 4 listed for AS20473, which are the ones I'm referring to)

 However, I can't seem to find any information about why we'd be listed
 there, nor can I find anything telling me how to get delisted.

 Yes. They don't provide that info, nor do they provide a way to
 request a de-listing AFAIK.

 You'll be removed automatically when the problem goes away.

 There's a lot of discussion in the archives about this, but I believe
 that, as far as is known publicly:

  1. There's a web-bug in the google search page
  2. They correlate IPv6 failures of this against the DNS lookup
  3. When the DNS source IP hits a certain threshold of correlatd
 failures, they stop serving  records for a time (one week?).

 Subjectively it's irritating that Google don't provide info to
 operators as to the specifics of the cause, but look at it from their
 PoV - there's a lot of info, some of it potentially personal /
 data-protected, that they'd have to communicate securely to operators
 when they ask.

 It would be a lot of work for them and I'm somewhat sympathetic on
 that basis (although I wasn't when it was happening to us ;o)

 My guess: you've got some form of broken IPv6 connectivity talking to
 your resolvers; maybe rogue RAs, a tunnel, VPN, etc.

 The customers with this problem aren't reporting it because Happy
 Eyeballs, but the Google web-bug is detecting it.

 We saw a reduction (and eventual end to) our experiences of this when
 we finished our native dual-stack deployment *and* when we blacklisted
 serving of  to some of our more troublesome netblocks - mainly
 remote access VPN users.

 We monitor whether google are blacklisting us in our Nagios setup, so
 we can see if problems come back.

 An alternative might be to steer different classes of users to
 different resolver query source IPs (either actual different
 resolvers, or using views  multiple IPs). Then, you can see which
 source IP and thus class of users is triggering it.

 Good luck tracking it; it can be frustrating :o(

 Cheers,
 Phil

Well, we're a hosting provider and we have a very large number of users
doing all sorts of crazy things.  These particular resolvers are used by
our low cost virtual server platform, so we see many users running a
wide variety of proxy software.  It's pretty difficult to prevent people
from breaking their IPv6 connectivity when they have full control over
the machines.

There may be some things that we can do to reduce the number of broken
IPv6 setups.. I just wasn't sure if we'd ever drop off that list
automatically.

Re: SV: Why do we still need IPv4 when we are migrating to IPv6...

[Eric Vyncke (evyncke)]

Is it related to the paranoid option of blocking all inbound traffic? To
mimick NAT44 ?

-éric

On 12/02/15 14:00, Thomas Schäfer tho...@cis.uni-muenchen.de wrote:

Am 12.02.2015 um 13:40 schrieb erik.tarald...@telenor.com:
 This might be so in Norway. In German customer portals the gamers
mostly
 demand ipv4 (public ipv4 address to their home) instead of DS-Lite.
They
 have already native IPv6 but avm was forced to allow teredo over DS
 and DS-lite - because xbox has problems with native IPv6.

 xbox is no good example for *wanting* IPv6.

 Could you elaborate on the IPv6 issues for xbox?  I was under the
impresion
 that xbox works well with IPv6.

It was last spring/summer. You can find it also in the archive of this
list.

In short:

xbox did not work at several (IPv6) providers. Some of them have patched
their routers and found a solution with Microsoft (comcast).
In other parts of the world, *the solution* was to allow teredo at an
IPv6-Access.
Because I don't own a xbox I haven't sniffed the network behaviour, but
I observe some costumer portals (e.g. Kabel Deutschland/Vodafone) and
there are still problems, often related to IPv6. (can have other reasons
too, like instability at all, Firewalls or something else)


Thomas

Some very nice IPv6 growth as measured by Google

[Eric Vyncke (evyncke)]

[As a side note, it seems that the European 'google' statistics are now more in 
line with the expectation]

Several countries have recently made good progress dixit Google  Apnic (URL 
are simply a different way of presenting Google data):

  *   US has reached 10%, welcome to the 10%-club
  *   Estonia has a VERY impressive growth approaching 5%: 
https://www.vyncke.org/ipv6status/plotpenetration.php?country=ee
  *   Other European countries with a recent growth:
 *   Austria: 
https://www.vyncke.org/ipv6status/plotpenetration.php?country=at
 *   Czech republic: 
https://www.vyncke.org/ipv6status/plotpenetration.php?country=cz
 *   Norway: 
https://www.vyncke.org/ipv6status/plotpenetration.php?country=no
 *   Greece: 
https://www.vyncke.org/ipv6status/plotpenetration.php?country=gr
 *   Portugal: 
https://www.vyncke.org/ipv6status/plotpenetration.php?country=pt

If you are behind those growths, I would love to hear more details: technology  
used, issues, …

Congratulations anyway

-éric

Google IPv6 measurements in Europe appear heading down...

[Eric Vyncke (evyncke)]

For a couple of weeks, it seems that Google IPv6 measurements are heading down 
mainly for Europe. For example, here is a link to a presentation of the Google 
measurements for several European countries and USA. There is a clear drop in 
the last days/weeks for European countries but not for USA.

This includes a big drop for my country (BE) :-O and I have checked with all 
Belgian ISP and they have no explanation as for them 'business as usual'. Apnic 
also does not show such a big drop.

So, I am guessing either a 'bug' in Google measurements infrastructure in 
Europe or could it be that the IPv6 latency to Google has increased a lot so 
that Happy Eyeball prefers IPv4? Recent measurement of dual-stack latency to 
www.google.com from several Belgian ISP gave 10% slower over IPv6.

Any clue will be welcome

-éric

Re: Something with filters

[Eric Vyncke (evyncke)]

Hi Enno,

Regarding a 3GPP phone, AFAIK, it receives a /64 so it is scalable and
easy to enforce uRPF at the very first layer-3 routers. Same for a home
CPE (with a very minor impact, uRPF has same performance as plain
forwarding == same lookup technique) and anyway the BNG/BRAS does DHCP-PD
snooping and should do uRPF as well. Pretty much like in IPv4.

But, we may indeed suspect that uRPF on a longer prefix such as /96 (??)
could be as efficient as forwarding to a /96 which is rumored to be less
efficient than forwarding to a prefix shorter than 64. Just a wild guess
(and please do not assume some magical knowledge of mine based on my email
address)

-éric


On 28/08/14 16:31, Enno Rey e...@ernw.de wrote:

Eric, guys,

On Thu, Aug 28, 2014 at 02:28:53PM +, Eric Vyncke (evyncke) wrote:
 The mapped IPv4 address is probably coming out of a 6PE (or 6VPE) MPLS
router where the HopLimit field is copied into the MPLS header and when
the poor P router in charge of sending the ICMPv6 has no IPv6 address at
all? This is per RFC and perhaps an explanation why uRPF is not
activated?
 
 No explanation about the :: address though?
 
 As a security person, I would love to have uRPF enabled where possible
but I am afraid that even in IPv4 it is not deployed everywhere :-(

to be honest, as another security person, I'm not really sure about the
benefit of uRPF in the IPv6 world, in some scenarios.
imagine a single infected smartphone on LTE, generating connections with
potentially 2^64 different source addresses from its assigned /64. How
would you counter that with uRPF?
not to speak about a home device sitting behind a CPE (and mimicing
connections from different /64s being part of the /56 the CPE got)...
thoughts?

best

Enno





 
 -?ric
 
 PS: indeed, ask your vendors for features, customers have much more
power than you guess :-)
 
 From: Lorenzo Colitti lore...@google.commailto:lore...@google.com
 Date: jeudi 28 ao?t 2014 07:46
 To: Jeroen Massar jer...@massar.chmailto:jer...@massar.ch
 Cc: IPv6 Ops list
ipv6-ops@lists.cluenet.demailto:ipv6-ops@lists.cluenet.de
 Subject: Re: Something with filters
 
 On Wed, Aug 27, 2014 at 9:01 AM, Jeroen Massar
jer...@massar.chmailto:jer...@massar.ch wrote:
  9  2001:5a0:a00::2e (2001:5a0:a00::2e)  79.018 ms  79.910 ms  79.960 ms
 10  :: (::)  101.893 ms  102.004 ms  103.574 ms
 11  rar3.chicago-il.us.xo.nethttp://rar3.chicago-il.us.xo.net
(:::65.106.1.155)  104.732 ms
 
 Yeah baby, we can use the unspecified address in ICMP replies!
 
 The mapped IPv4 address in there is pretty cool, too...

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

===
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
===

Re: IPv6 packets with HBH

[Eric Vyncke (evyncke)]

Yannis

While I cannot speak for all vendors or even for all of my employer's
products, you will indeed find that control-plane policing (=
rate-limiting) is either on by default or can be configured on most
routers.

Alternatively, you may want to use plain ACL to drop all those
potentially-harmful packets with HbH.

You probably know that HbH is also used on the local link for MLD and on
the WAN for RSVP (and possibly for other purposes). So, be sure to
understand your own use before configuring drop/rate limiting ;-)

Rate-limiting is really the way to go IMHO. A platform which processes HbH
without rate-limiting (and there are such platforms) should NOT be
deployed on the wild Internet.

Hope that this belated reply helps

-éric


On 5/07/14 15:27, Yannis Nikolopoulos d...@otenet.gr wrote:

On 07/04/2014 11:43 PM, Brian E Carpenter wrote:
 On 05/07/2014 04:05, Yannis Nikolopoulos wrote:
 hello,

 how do people handle packets with HBH present? Since their use is a
 potential attack vector, do people rate-limit them? I can't seem to
find
 some sort of best practice on the issue
 I have the impression that they are simply ignored in many cases.
 That is simpler than rate-limiting. It is legal, because we reduced
 the requirement to processing them to a SHOULD in RFC 7045:

 The IPv6 Hop-by-Hop Options header SHOULD be processed by
 intermediate forwarding nodes as described in [RFC2460].  However,
it
 is to be expected that high-performance routers will either ignore
it
 or assign packets containing it to a slow processing path.
Designers
 planning to use a hop-by-hop option need to be aware of this likely
 behaviour.
That sounds fine and it would make our lives easier but...

I'm note sure about other vendors, but it seems that Cisco boxes are
processing those at each node, at least it seems that ASR9k and 7600 do
(although there's the option to rate-limit them). CRS probably rate
limit them by default but the info is quite scarce

cheers


   - Brian

 cheers,
 Yannis

Re: IPv6 Assignment for Server

[Eric Vyncke (evyncke)]

Not sure whether I fully understand the question in all details, but:

  1.  on a LAN/WLAN (basically where NS/NA is required to work, = broadcast 
domain with MAC addresses), the use of a /64 prefix is recommended
  2.  Each host (being server or client) must have at least one global address 
within this prefix

If you have one server per LAN, then it is perfectly OK to use one /64 per 
server. If you think about that, currently you use a /32 for IPv4 address :-) 
You are currently wasting more space (4 billion times more)

-éric

From: Teerapatr Kittiratanachai 
maillist...@gmail.commailto:maillist...@gmail.com
Date: mercredi 18 juin 2014 05:28
To: ipv6-ops@lists.cluenet.demailto:ipv6-ops@lists.cluenet.de 
ipv6-ops@lists.cluenet.demailto:ipv6-ops@lists.cluenet.de
Subject: IPv6 Assignment for Server

Dear IPv6-Ops,

I want the suggestion about the best practice for assign IPv6 Global Unicast 
address for server.
According to the IPv6 Subnet ID also be built in with IPv6 address, so if I 
assign the /64 mask to the server is it will be some of wasteful usage?
AFAIK, the /64 mask address can be brought to use for many other subnets. Is it 
more suitable to assign the /128 to the server, or end server that doesn't act 
as any other gateway.

Thank you in advance.

Regards,
Teerapatr Kittiratanachai (Te)

Re: IPv6 Assignment for Server

[Eric Vyncke (evyncke)]

I wonder why you would like to do that rather than asking for a /60 at your ISP 
though :-)

You 2nd design MAY work but deviates from the IPv6 spec on LAN AFAIK. It will 
break SLAAC (so static configuration is required) and some routers and host 
implementations may (rightfully) complain. But you have decent chance that it 
works

-éric

From: Teerapatr Kittiratanachai 
maillist...@gmail.commailto:maillist...@gmail.com
Date: mercredi 18 juin 2014 08:30
To: Eric Vyncke evyn...@cisco.commailto:evyn...@cisco.com
Cc: ipv6-ops@lists.cluenet.demailto:ipv6-ops@lists.cluenet.de 
ipv6-ops@lists.cluenet.demailto:ipv6-ops@lists.cluenet.de
Subject: Re: IPv6 Assignment for Server

Thank you, I forgot to think about NS and NA.

One more question, If I got the /64 mask from ISP and implement as below. 
Theoretically, is it work?

Normal Situation: work fine
IPv6 Internet - ISP (2001:db8:a:1::1/64) - (2001:db8:a:1::2/64) MyPC

My Implementation: is it possible?
IPv6 Internet - ISP (2001:db8:a:1::1/64) - (2001:db8:a:1:0::2/80) 
MyRouter (2001:db8:a:1:a::1/80) - (L2 SWITCH) - (2001:db8:a:1:a::2/80) 
MyPCs

So from my router will also be IPv6 network with Global Unicast address.

--Te


On Wed, Jun 18, 2014 at 1:14 PM, Eric Vyncke (evyncke) 
evyn...@cisco.commailto:evyn...@cisco.com wrote:
Not sure whether I fully understand the question in all details, but:

  1.  on a LAN/WLAN (basically where NS/NA is required to work, = broadcast 
domain with MAC addresses), the use of a /64 prefix is recommended
  2.  Each host (being server or client) must have at least one global address 
within this prefix

If you have one server per LAN, then it is perfectly OK to use one /64 per 
server. If you think about that, currently you use a /32 for IPv4 address :-) 
You are currently wasting more space (4 billion times more)

-éric

From: Teerapatr Kittiratanachai 
maillist...@gmail.commailto:maillist...@gmail.com
Date: mercredi 18 juin 2014 05:28
To: ipv6-ops@lists.cluenet.demailto:ipv6-ops@lists.cluenet.de 
ipv6-ops@lists.cluenet.demailto:ipv6-ops@lists.cluenet.de
Subject: IPv6 Assignment for Server

Dear IPv6-Ops,

I want the suggestion about the best practice for assign IPv6 Global Unicast 
address for server.
According to the IPv6 Subnet ID also be built in with IPv6 address, so if I 
assign the /64 mask to the server is it will be some of wasteful usage?
AFAIK, the /64 mask address can be brought to use for many other subnets. Is it 
more suitable to assign the /128 to the server, or end server that doesn't act 
as any other gateway.

Thank you in advance.

Regards,
Teerapatr Kittiratanachai (Te)

Yet another Merit (ASN 237) IPv6 Darknet in the last months?

[Eric Vyncke (evyncke)]

I know that Merit run an IPv6 darknet in 2012, but, but looking at 
http://www.vyncke.org/ipv6status/plotbgp.php?country= (showing the amount of 
not aggregated announced prefixes based on route views.org data) it appears 
that ASN 237 had announced 2600::/12, 2800::/12, … From 2013-10-28 to 
2014-01-28.

Was there any announcement of this? I googled without success :-(

Thanks in advance for any pointer

-éric

Re: interesting multicast packet

[Eric Vyncke (evyncke)]

I used Little Snitch for a while on my device but too intrusive, let's
rather use pfctl ;-)


On 21/03/14 15:21, Jeroen Massar jer...@massar.ch wrote:

On 2014-03-21 08:54, Eric Vyncke (evyncke) wrote:
 And Stig, if you are using our 'employer-paid' laptop sold by Cupertino,
 then, you are also sending those packets... I discovered this 'feat'
last
 week when sniffing traffic from my own laptop...
 
 The use of organization-scope multicast is nice but the ::2 is indeed
 awkward

This can be the day that you learn to install Little Snitch on the
iFruit device and disable even the standard-local-network-rules ;)

Greets,
 Jeroen

Re: Microsoft: Give Xbox One users IPv6 connectivity

[Eric Vyncke (evyncke)]

On 14/03/14 00:21, Marco Sommani marcosomm...@gmail.com wrote:
AVM is not alone in its choices: they just do what is suggested in RFC
6092 - Recommended Simple Security Capabilities in Customer Premises
Equipment (CPE) for Providing Residential IPv6 Internet Service. I don't
like what they do, but maybe we should blame IETF.

Marco

I agree and disagree :-)

Agreement on the fact that AVM is not the only CPE vendor doing this (and
also blaming ISP -- notably in my country 15% of broken IPv6 connectivity
= Belgium)...

Disagreement: RFC 6092 has TWO settings: one close and one open and the
choice should be given to the end-user. As you may know, there have been
heated discussion at the IETF on this topic

-éric

Re: Microsoft: Give Xbox One users IPv6 connectivity

[Eric Vyncke (evyncke)]

Jakob

What annoys me more if the fact that AVM (and they are not the only one --
see Technicolor  others) naively believes that NAT44 offered some
security by preventing inbound connections... This means that there is NO
open connectivity between two X/Box behind a closed AVM CPE... Hence X/Box
has no choice and is smart enough to fall back in the legacy NAT44 mode
with a TURN (or in this case Teredo) to bypass NAT. A very nice
opportunity to run man-in-the-middle attack on a foreign ground.

I still wonder why people REALLY believe in the security of NAT (in the
sense of blocking inbound connections) in 2014 while most of the botnet
members are behind a NAT...

Christopher and others = you are RIGHT! Do not change your mind

-éric (see also 
http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security-01 for
my point of view :-))


On 13/03/14 18:43, Jakob Hirsch j...@plonk.de wrote:

Hi!

Christopher Palmer, 2013-10-10 03:22:
 
http://download.microsoft.com/download/A/C/4/AC4484B8-AA16-446F-86F8-BDFC
498F8732/Xbox%20One%20Technical%20Details.docx

Nice, but why do you absolutely require Teredo even for boxes with
native IPv6? Of course there's the advantage of direct client2client
communication (less latency for clients and less traffic on Teredo
relays), but the box should at least fall back to native IPv6 if Teredo
is not available (quite odd to talk about native IPv6 being a fallback
to Teredo, but anyway).

There's at least one CPE manufacturer (quite prevalent in Europe or at
least in Germany) that filters out Teredo if native IPv6 is available by
default. They added an option to disable this filter, but that's not a
good thing. See
http://service.avm.de/support/en/skb/FRITZ-Box-7390-int/1439:Cannot-play-o
nline-games-with-Xbox-One

In the current state, the XBox One is doing more harm to IPv6 than good.
People encounter problems after having IPv6 activated (there are forum
posts which told people to disable IPv6 to fix this issue) and Network
operators will see less increase in IPv6 traffic (which lowers the
incentive to improve IPv6 support).


Regards
Jakob

Re: Microsoft: Give Xbox One users IPv6 connectivity

[Eric Vyncke (evyncke)]

Or is it because AVM blocks all inbound IPv6 connection and X/Box has no
choice but falling back on Teredo?

I am really unclear on the exact situation

-éric

On 13/03/14 21:46, Gert Doering g...@space.net wrote:

Hi

On Thu, Mar 13, 2014 at 07:12:54PM +, Eric Vyncke (evyncke) wrote:
 What annoys me more if the fact that AVM (and they are not the only one
--
 see Technicolor  others) naively believes that NAT44 offered some
 security by preventing inbound connections... This means that there is
NO
 open connectivity between two X/Box behind a closed AVM CPE... Hence
X/Box
 has no choice and is smart enough to fall back in the legacy NAT44 mode
 with a TURN (or in this case Teredo) to bypass NAT. A very nice
 opportunity to run man-in-the-middle attack on a foreign ground.

I'm not sure what NAT44 has to do with it.

The point is that there is *native* IPv6 and the XBox insists on
preferring 
Teredo - and the AVM box blocks Teredo if it has native IPv6, because
there
is no real use in permitting an tunnel IPv6 around the IPv4-only router!
protocol when there *is* a perfectly good IPv6-capable router around...

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A.
Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

Re: Question on DHCPv6 address assignment

[Eric Vyncke (evyncke)]

Fernando

Wrt to the Cisco DHCPv6 server (CNR):
1) sequential or random per configuration (can send multiple IA_NA/IA_TA
if there are multiple prefixes configured for this link)
2) while client can send a 'hint' to re-use previous addresses, the server
can do the same thing, we called this 'affinity', as well if using IA_NA
(or course not applicable to IA_TA :-))

PD is the same

Hope this helps

-éric

On 31/01/14 22:00, Fernando Gont ferna...@gont.com.ar wrote:

Folks,

I'm wondering about the following two aspects of different DHCPv6
implementations out there:

1) What's the pattern with which addresses are generated/assigned? Are
they sequential (fc00::1, fc00::2, etc.)?  Random? Something else?

2) What about their stability? Is there any intent/mechanism for them to
be as stable as possible? Or is it usual for hosts to get a new
address for each lease?

P.S.: I understand this is likely to vary from one implementation to
another... so please describe which implementation/version you're
referring to.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

RE: 'Upgrading' NAT64 to 464XLAT?

[Eric Vyncke (evyncke)]

Dick

464XLAT is contained within a host, so, you will need an implementation for all 
your end host (laptop, tablets, ...) 

But, I am sure that you already know that ;-)

 -Original Message-
 From: ipv6-ops-bounces+evyncke=cisco@lists.cluenet.de
 [mailto:ipv6-ops-bounces+evyncke=cisco@lists.cluenet.de] On
 Behalf Of Dick Visser
 Sent: lundi 25 novembre 2013 14:20
 To: ipv6-ops@lists.cluenet.de
 Subject: 'Upgrading' NAT64 to 464XLAT?
 
 hi guys
 
 We've been running a NAT64/DNS64 set-up for a while now on some parts
 of
 our office network.
 This seems to work well, but it doens't work for everything (e.g.
 Skype
 etc).
 If those apps were working, it would be possible to actually use if
 for
 production.
 I was reading about 464XLAT, and from what I understand, this is more
 or
 less NAT64, but with some sort of local (RFC1918) IPv4 in the mix.
 
 For phones this is done using a special daemon that provides a local
 IPv4 address.
 I'd like to 'upgrade' out existing NAT64/DNS64 setup to do 464XLAT,
 but
 there aren't many docs about how to set 464XLAT to begin with.
 I've seen https://sites.google.com/site/tmoipv6/464xlat, and I asked
 around here and there.
 A schema with actual addresses would be nice, but I can't find that.
 
 Since we have an office set-up with, I assume I should configure the
 IPv6-only VLAN so that RFC1918 addresses are handed out on it as
 well?
 
 What I don't understand, if a device gets an RFC1918 IPv4 address,
 and a
 global IPv6 address, how would it be possible that apps that support
 IPv6-only use the IPv6 path? I can imagine that some applications
 still
 prefer to take the IPv4 path?
 
 
 Thanks!!
 
 
 
 
 
 --
 Dick Visser
 System  Networking Engineer
 TERENA Secretariat
 Singel 468 D, 1017 AW Amsterdam
 The Netherlands

RE: teredo.ipv6.microsoft.com off?

[Eric Vyncke (evyncke)]

Jeroen

AFAIK, only Teredo is disabled when the Windows host detects AD

-éric

 -Original Message-
 From: ipv6-ops-bounces+evyncke=cisco@lists.cluenet.de [mailto:ipv6-ops-
 bounces+evyncke=cisco@lists.cluenet.de] On Behalf Of Jeroen Massar
 Sent: mercredi 17 juillet 2013 15:20
 To: Ron Broersma
 Cc: Christopher Palmer; ipv6-ops@lists.cluenet.de; Mikael Abrahamsson
 Subject: Re: teredo.ipv6.microsoft.com off?
 
 On 2013-07-17 15:09 , Ron Broersma wrote:
 
  On Jul 16, 2013, at 10:40 PM, Mikael Abrahamsson wrote:
 
  On Tue, 16 Jul 2013, Christopher Palmer wrote:
 
  If there is feedback on the ongoing experiment or our consideration
  of sunsetting Teredo, do let me know.
 
  So far people have been quite enthusiastic.
 
  I am too. I would really like to see 6to4 and teredo be default off
  everywhere, and people who want it can manually turn it on. If teredo
  went away completely, that would also be a good thing.
 
  Strongly concur here as well.  One less thing I have to disable on all
  my systems in enterprise nets.
 
 Windows boxes that are in an Active Domain (which should match your
 'enterprise net') have Teredo and 6to4 disabled per default.
 
 Next to that one can enforce that of course through AD policies.
 
 Greets,
  Jeroen

RE: New IPv6 king of the hill: Switzerland?

[Eric Vyncke (evyncke)]

There is indeed a noticeable change in the Google IPv6 statistics (my web site 
is only an graphical layer on their data) with a generalized drop in all 
countries except US, Switzerland (but SwissCom has made a recent major move!) 
and Peru (Telefonica -- dixit WV6L web site -- appears to deploy a lot of IPv6 
:-)). The drop affects too many countries (including my own Belgium!) so it 
must be a change in the way statistics are collected/processed.

Let's wait until Erik  Lorenzo chime in for more explanations

-éric

 -Original Message-
 From: ipv6-ops-bounces+evyncke=cisco@lists.cluenet.de [mailto:ipv6-ops-
 bounces+evyncke=cisco@lists.cluenet.de] On Behalf Of Jan Schaumann
 Sent: mardi 21 mai 2013 17:17
 To: ipv6-ops@lists.cluenet.de
 Subject: Re: New IPv6 king of the hill: Switzerland?
 
 Tore Anderson t...@fud.no wrote:
  Just noticed that Switzerland's IPv6 deployment level (according to
  Google) has been skyrocketing lately, anyone know if this is just an
  outlier or something real and big going on?
 
  http://www.vyncke.org/ipv6status/compare.php?metric=pcountries=ch
 
 Interesting.  I also noted a significant jump in the US starting
 approximately the same date, while France, Romania, and Germany appear to
 have dropped off around the same time:
 http://www.vyncke.org/ipv6status/compare.php?metric=pcountries=ch,us,de,fr,
 ro
 
 Did something get turned on/off during RIPE66?  Too much guinness?
 
 -Jan