Re: http://www.6assist.net/ - call for test

Max, > I mentioned Slovenia as we have a request for BGP-enabled tunnel from > Slovenia ;) So for some reasons people still want to use BGP-enabled > tunnels in real life, even in conuntries with well implemented native IPv6. > > The second reason to use 6assist instead of regular TB it is not de

Re: http://www.6assist.net/ - call for test

Max, > Proto-41 or 6to4 is a point-to-point tunnels in any case. So if you want > to communicate directly to the significant part of the world this way, > you need to set up and maintain hundreds of tunnels, as well as hundreds > of BGP sessions. Also you have to go through a long and hard > admin

Re: Point-to-point /64

Arturo, Don't put any global scope addresses on it at all. Ole On 1 Jun 2013, at 22:24, Arturo Servin wrote: > >Got it. > >I though it was something different. > >Suppose now that I am very stubborn and I do not want to configure > /128, /127, /126, /112, /96 or any other longe

Re: Point-to-point /64

On 1 Jun 2013, at 22:56, Jeroen Massar wrote: > One thing to keep in mind though is that quite some gear is optimized > upto the first /64 bits, and might use slower paths for longer prefixes, > thus if one is going to put a lot of /128s in a single /64, thus when > really stuffing all p2p link

Re: Point-to-point /64

On 1 Jun 2013, at 23:55, Jeroen Massar wrote: > On 2013-06-01 14:01, Ole Troan wrote: >> >> >> On 1 Jun 2013, at 22:56, Jeroen Massar wrote: >> >>> One thing to keep in mind though is that quite some gear is >>> optimized upto the first /64 bi

Re: Point-to-point /64

Jared, >> If you are talking about router to router links, then typicall little >> traffic is forwarded to any of the link addresses. This should generally not >> be a concern. > > Except when someone decides to 'attack' them. Then you can see a lot of > traffic. sure, but then it is no dif

Re: Automatic source routing

Emmanuel, >>> The problem is really annoying if you want to use autoconfiguration >>> in a multihoming scenario without the need for an external daemon. >>> But maybe i missed a sysctl flag or something like that. >> >> Maybe, maybe not. What system are you using to manage your networking - for

Re: Automatic source routing

Emmanuel, > The problem is really annoying if you want to use autoconfiguration > in a multihoming scenario without the need for an external daemon. > But maybe i missed a sysctl flag or something like that. Maybe, maybe not. What system are you using to manage your networki

Re: Behaviour and consequences of DAD

Mathew, >> no, it will only reply if it has that exact address. otherwise it will >> drop that packet. > > Aha. So the tentative address is actually included within the message? correct. see http://tools.ietf.org/html/rfc4861#section-4.3. "Target address". cheers, Ole signature.asc Descripti

Re: Behaviour and consequences of DAD

Mathew, > Specifically, it is my undertanding that when an node has a tentative > address it wishes to use it sends a neighbour solicitation to the > solicited-node multicast address which is computed using the last 24 bits > of that tentative address. If another node is already listening on that

Re: ipv6 source address selection

Mikael, > I'm trying to influence my source address selection. First I thought I'd > figure out how it works by default. > > I have a /48. Let's call it 2001:db8:1::/48 > > I created three /64s on the same LAN with A-bit set so clients would do SLAAC > within these: > > 2001:db8:1::/64 >

Re: MTU handling in 6RD deployments

> Does anyone know what tricks, if any, the major 6RD deployments (AT&T, > Free, Swisscom, others?) are using to alleviate any problems stemming > from the reduced IPv6 MTU? Some possibilities that come to mind are: > > * Having the 6RD CPE lower the TCP MSS value of SYN packets as they > enter/ex

Re: Question about IPAM tools for v6

>> 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. FUD. cheers, Ole signature.asc Descriptio

Re: IPv6 packets with HBH

Fernando, >> 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 > > This is the current state of affairs on the public IPv6 Internet: >

Re: IPv6 packets with HBH

Erik, > On 11 August 2014 18:33, Yannis Nikolopoulos wrote: > On 08/07/2014 03:05 PM, Ole Troan wrote: > advice with regards to HBH headers. assuming there isn't any feature enabled > that uses HBH. on a platform that supports forwarding of packets with HBH > without p

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

>> So, any thoughts on this topic, and any qualified guesses on when we no >> longer need to do IPv4 and still be able to call our internet product >> premium? When will IPv6 provide me as an end-user with more "value" than what my current NATed IPv4 connection does? Best regards, Ole signat

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

Gert, So, any thoughts on this topic, and any qualified guesses on when we no longer need to do IPv4 and still be able to call our internet product premium? >> >> When will IPv6 provide me as an end-user with more "value" than what my >> current NATed IPv4 connection does? > >

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

Mikael, >> But that's "better value" by making IPv4 work less good. and I'll postulate >> that we can make A+P / shared IPv4 work good enough that end-users who are >> trained to live behind a NATs will not notice. > > Problem with that is that this doesn't work with anything that doesn't have

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

>> I wonder if it would make a difference if big eyeballs ISPs ("among the >> 3 largest in a country") would start talking to content providers, telling >> them "hey, you know, your content is quite popular with our users, but >> since it's v4-only, we need to seriously throttle it to avoid overloa

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

> A few things, 1) interest payments presupposes that one loans money to buy > addresses, 2) as long as 40% of all traffic is still IPv4 for DS enabled > customer, we need a fairly sizable CGN/AFTR setup. > > From our perspective, doing investments on CGN/AFTR technology now can almost > be com

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

> On 12 Jun 2015, at 5:31 , Lorenzo Colitti wrote: > > On Thu, Jun 11, 2015 at 6:56 PM, Benedikt Stockebrand > wrote: > they should at least send an RS when they wake up and ensure their > configuration is still up to date. > > That sounds like a bad idea. If devices send an RS every time the

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

IETF RFC bug. cheers, Ole > On 12 Jun 2015, at 10:11 , Lorenzo Colitti wrote: > > On Fri, Jun 12, 2015 at 4:54 PM, Ole Troan wrote: > > That sounds like a bad idea. If devices send an RS every time the user > > turns the screen on, and the router responds with a multicas

Re: DHCPv6 relay with PD

> I've talked to several people who claim there are lots of equipment out there > which will happily do DHCPv6 relaying of PD messages, but then not install a > route for the corresponding delegation. That's perfectly fine behaviour by the way. DHCPv6 PD snooping is just one way of doing route i

Re: DHCPv6 relay with PD

Mikael, >>> I've talked to several people who claim there are lots of equipment out >>> there which will happily do DHCPv6 relaying of PD messages, but then not >>> install a route for the corresponding delegation. >> >> That's perfectly fine behaviour by the way. >> DHCPv6 PD snooping is just

Re: DHCPv6 relay with PD

Mikael, >> We also tried (and failed) to come up with a secure mechanism for the >> requesting router to advertise it's delegated prefix to first-hop routers. >> >> Less astonished? ;-) > > Well, I guess I shouldn't be astonished. I've even seen vendors implement the > DHCPv6-PD server on the

Re: DHCPv6 relay with PD

>>> So basically, regarding how to actually implement PD in a network (from an >>> IETF point of view), everybody just gave up, declared the problem >>> unsolvable, and went back to sleep? >> >> It shouldn't be the IETF's job to tell people how to run their networks. >> The IETF provides the bui

Re: DHCPv6 relay with PD

Nick, >> 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 t

Re: UPnP/IPv6 support in home routers?

>> one would want to be able to whitelist all ports >> for a given IP address > > What? No! > > "Dear Gateway, I am definitely not a compromised host, please open all > ports toward me." > > I don't disregard the idea that one would want to manually configure > this behaviour, but not automatica

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

> On 10 May 2019, at 06:27, Doug Barton wrote: > > 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

Re: IPv6 ingress filtering

> Anycast 6to4 needed to be assassinated, and that has more or less happened. > If classical unicast 6to4 is still working for a few people, I don't really > see any harm in it. Of course I agree that native is better. As far as I can tell there is really no flavour of 6to4 that can be deployed

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

>> I have found more problems with the DHCPv6-PD. The issue is on many home >> networks where people are using server type hardware such as Windows(TM) >> networks where DNS is used to locate and secure the network the renumbering >> event creates major problems as the on premises DHCPv6 server

Re: Prefix delegation to sub nets

> On 27 Jun 2021, at 23:07, Brian E Carpenter > wrote: > > That doesn't work. B needs to get its own /64 prefix(es) from A via DHCPv6-PD > (https://www.rfc-editor.org/info/rfc8415). That's what DHCPv6-PD is for. So A > will indeed need to be a DHCPv6 server on its downstream interfaces. To

Re: Prefix delegation to sub nets

>>> wrote: >>> >>> Is HNCP available for the various Linux distros? >>> If not, it has to be PD, I think. >>> >>> Regards, >>> Brian Carpenter >>> (via tiny screen & keyboard) >>> >>> On Mon, 28 J