Re: v4 and v6 BOGON list
Hi Gabriel, for v6 you may find the following helpful: https://theinternetprotocolblog.wordpress.com/2020/01/15/some-notes-on-ipv6-bogon-filtering/ cheers Enno On Thu, Mar 21, 2024 at 07:20:53PM +, Gabriel Terry wrote: > All, > > I was researching BOGON prefixes and found a reference from IANA listing > special-purpose addresses, URLs listed below. Based on my understanding of > the list I think I should be able to block all of the entries from my > upstream peerings without affecting normal internet traffic. I assume that > there would only be special scenarios that the addresses listed in the > special-purpose entry would be used. I am interested to hear what others are > doing when it comes to blocking BOGON NLRI from their upstream BGP peerings. > If anyone has any insight into this please let me know your thoughts, I would > love to discuss more on the topic. > > URLs: > https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml > https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml > > Thanks, > > Gabriel L. Terry > -- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator IPv6 Blog: https://theinternetprotocolblog.wordpress.com
Re: 202401100645.AYC Re: IPv4 address block
On Wed, Jan 10, 2024 at 07:35:01AM -0500, Abraham Y. Chen wrote: > Hi, Karim: > > 1)?? If you have control of your own equipment (I presume that your > business includes IAP - Internet Access Provider, since you are asking > to buy IPv4 blocks.), you can get a large block of reserved IPv4 address > _/*for free*/_ by _/*disabling*/_ the program codes in your current > facility that has been */_disabling_/* the use of 240/4 netblock. As you state yourself this could be considered "unorthodox, if not controversial". Alas in network operations 'unorthodox' usually means 'breaks something'. Which is exactly why you may avoid this, see also: https://theinternetprotocolblog.wordpress.com/2019/10/06/some-notes-on-ipv4-address-space/ cheers Enno Please > have a look at the below whitepaper. Utilized according to the outlined > disciplines, this is a practically unlimited resources. It has been > known that multi-national conglomerates have been using it without > announcement. So, you can do so stealthily according to the proposed > mechanism which establishes uniform practices, just as well. > > https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf > > 2)?? Being an unorthodox solution, if not controversial, please follow > up with me offline. Unless, other NANOGers express their interests. > > > Regards, > > > Abe (2024-01-10 07:34 EST) > > > > On 2024-01-07 22:46, KARIM MEKKAOUI wrote: > > > > Hi Nanog Community > > > > Any idea please on the best way to buy IPv4 blocs and what is the price? > > > > Thank you > > > > KARIM > > > > > -- > This email has been checked for viruses by Avast antivirus software. > www.avast.com -- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator IPv6 Blog: https://theinternetprotocolblog.wordpress.com
Re: IPv6 "bloat"
Hi, On Sat, Mar 19, 2022 at 07:11:47PM -0400, Matt Hoppes wrote: > I misspoke... it's not UUID... It's DUID. > > This isn't a backend management issue. This is a protocol issue. The > MAC of the interface needs to be sent with a DHCP request so that it can > be properly authenticated to the physical device. > > As long as the client and DHCPv6 server are on the same network > interface -- it all works fine. However, when you relay that > information, you now lose the MAC address information. RFC 6939 solves that, since a long time. See also: https://insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/ > > Further, because the MAC is disconnected in IPv6 it becomes more > difficult to make the connection between IPs on a dual-stack client. Not sure if I agree with that either. That connection can be made by various other means, see https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/ cheers Enno > > Everyone prints the MAC (a unique ID on devices and devices packaging). > Almost nobody prints the DUID on a device, so how do you pre-populate > your DHCP server? I can see that it encourages "one interface per > network" and so encourages bonding, bridging or whatever, but is being > able to differentiate the interfaces of a host really so bad? I can't > help but feel that it would have been nice for DHCPv6 to send DUID and MAC. > > > > On 3/19/22 7:03 PM, Michael Thomas wrote: > > > > On 3/19/22 3:56 PM, Matt Hoppes wrote: > >> > >> > >> On 3/19/22 6:50 PM, Michael Thomas wrote: > >>> > >>> On 3/19/22 3:47 PM, Matt Hoppes wrote: > >>>> It has "features" which are at a minimum problematic and at a > >>>> maximum show stoppers for network operators. > >>>> > >>>> IPv6 seems like it was designed to be a private network > >>>> communication stack, and how an ISP would use and distribute it was > >>>> a second though. > >>> > >>> What might those be? And it doesn't seem to be a show stopper for a > >>> lot of very large carriers. > >> > >> Primarily the ability to end-to-end authenticate end devices. The > >> primary and largest glaring issue is that DHCPv6 from the client does > >> not include the MAC address, it includes the (I believe) UUID. > >> > >> We have to sniff the packets to figure out the MAC so that we can > >> authenticate the client and/or assign an IP address to the client > >> properly. > >> > >> It depends how you're managing the network.?? If you're running PPPoE > >> you can encapsulate in that. But PPPoE is very 1990 and has its own > >> set of problems.?? For those running encapsulated traffic, > >> authentication to the modem MAC via DHCP that becomes broken.?? And > >> thus far, I have not seen a solution offered to it. > > > > I was honestly more interested in the bloat angle, but this sounds like > > a backend problem of your own making most likely. But I'm not motivated > > to see if it's actually the case or just a misunderstanding. -- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator
Re: Class D addresses? was: Redploying most of 127/8 as unicast public
Hi, On Sat, Nov 20, 2021 at 11:01:35AM -0800, Michael Thomas wrote: > > On 11/20/21 10:44 AM, Chris Adams wrote: > > [] > > won out using unicast. Even if it has some niche uses, I seriously doubt > that it needs 400M addresses. If you wanted to reclaim ipv4 addresses it > seems that class D and class E would be a much better target than loopback. I agree from an efficiency (= ratio of resources used vs. result achieved), but this wouldn't work in practice outside isolated environments for the same reasons why the 127/8 is not going to work: https://theinternetprotocolblog.wordpress.com/2019/10/06/some-notes-on-ipv4-address-space/ For the sake of the thread it should be noted that both the reception of and the response to the initial e-mail primarily happened over IPv6. I wish everybody a great weekend Enno -- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator
Re: AWS Using Class E IPv4 Address on internal Routing
Hi, On Tue, Mar 09, 2021 at 06:53:33AM -0800, Fred Baker wrote: > The "RFC" you're looking for is probably > https://tools.ietf.org/html/draft-wilson-class-e-02 there was/is also 'IPv4 unicast extensions project' (https://github.com/schoen/unicast-extensions) with a similar idea & approach. I for one think that from an operations perspective those addresses would be pretty much unusable in pretty much all complex networks (except for corner cases like, maybe, AWS' one), see https://theinternetprotocolblog.wordpress.com/2019/10/06/some-notes-on-ipv4-address-space/. cheers Enno , which was not agreed to and so has no RFC number. The fundamental issue that was raised during that discussion was that while repurposing class e would provide a few more IPv4 addresses and so delay the need to replace the IPv4 protocol for some period of time, APNIC's experience with a new /8 in 2011 (it was given the /8 in January 2011, and by April had largely distributed it to its members) suggests that the address space would be used up almost immediately if distributed publicly, and if used privately doesn't benefit the many networks that really honestly wish that we could squeeze more than 2^32 addresses into a 32 bit container. > > I'd really suggest using IPv6. Networks like Reliance JIO in India, which has > turned off or never turned on IPv4 for most of its services, find that they > don't need IPv4 apart from customer preference. > > > On Mar 9, 2021, at 6:36 AM, Douglas Fischer > > wrote: > > > > So, if an organization wants to use that, they will require from the > > vendors the compliance with that RFC. > > > > > > > > Em ter., 9 de mar. de 2021 ??s 11:00, Forrest Christian (List Account) > > escreveu: > > Back a little bit ago when the thread about running out of RFC-1918 space > > was going on, I was going to make a suggestion about repurposing the Class > > E space in the case where one ran out of space, assuming one could get the > > vendors on your network to support this address range. > > > > I sort of discarded the suggestion just because of the whole issue of that > > range being hardcoded as invalid in so many implementations that this > > didn't seem all that useful. > > > > On the other hand, if you're large enough that you're running out of > > RFC-1918 space you might be able to exert enough power over select vendors > > to get them to make this work for selected purposes. Router-to-Router > > links, especially between higher-end routers seems to be one of those cases > > that it might be useful. It might be the case that Amazon is already > > doing this > > > > > > On Mon, Mar 8, 2021 at 12:07 PM Douglas Fischer > > wrote: > > Has anybody seen that also? > > > > P.S.: I'm completely in favor of a complementary RFC assing FUTURE USE > > exclusively to "Between Routers" Link Networks... > > > > -- > > Douglas Fernando Fischer > > Eng?? de Controle e Automao > > > > > > -- > > - Forrest > > > > > > > -- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator
Re: Request comment: list of IPs to block outbound
Hi, On Sun, Oct 13, 2019 at 08:58:17AM -0700, Stephen Satchell wrote: > The following list is what I'm thinking of using for blocking traffic > between an edge router acting as a firewall and an ISP/upstream. This > fe80::/10 LinkLink-local address. most people allow that range as blocking it will drop NA/NS packets with the upstream router which in turn can delay the establishment of the BGP session (provided there is one over IPv6). best Enno -- Enno Rey https://theinternetprotocol.blog Twitter: @Enno_Insinuator
Re: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)
Hi, On Thu, Mar 01, 2018 at 09:30:32PM -0500, Harald Koch wrote: > On 1 March 2018 at 18:48, Mark Andrews <ma...@isc.org> wrote: > > > ULA provide stable internal addresses which survive changing ISP > > for the average home user. > > > Yeah this is pretty much what I'm doing. ULA for stable, internal addresses > that I can put into the (internal) DNS: ISP prefixes for global routing. > Renumbering is hard. as is proper (source|destination) address selection in a sufficiently complex environment. for interest: for a system which must be both globally and internally reachable, which address do you put into which DNS? > > All of the objections I've seen to ULA are actually objections to (IPv6) > NAT, which is why I was confused. the main objection against ULAs is avoidance of complexity in environments where at least some systems need global reach(ability), which applies to pretty much all environments nowadays. best Enno > > (As it turns out my ISP prefix has been static for years, but I'm too lazy > to undo all of the work...) > > -- > Harald -- 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: Matthias Luft, Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ===
Re: IPv6 Loopback/Point-to-Point address allocation
Hi, On Sun, Sep 10, 2017 at 12:08:59PM +0200, Job Snijders wrote: > Hi, > > On Sun, Sep 10, 2017 at 11:53:20AM +0200, Enno Rey wrote: > > On Sun, Sep 10, 2017 at 10:47:05AM +0100, Nick Hilliard wrote: > > > Baldur Norddahl wrote: > > > > Loopback interfaces should be configured as /128. How you allocate > > > > these do > > > > not matter. > > > > > > ..so long as there are interface ACLs on your network edge which block > > > direct IP access to these IP addresses. > > > > or, maybe even more efficient, assign all loopbacks from a dedicated > > netblock which you null-route on the edge/your border devices. > > Null-routing may not be sufficient, if the edge/border router has a > route to that /128; the (forwardable) /128 entry will win from the > blackholed /64 FIB entry since it is more-specific. just thought about it a bit. As mentioned (in other post) I was thinking of a specific use case/setting, but wouldn't a static null-route (of a blackholed /64) win over a /128 learned from a RP anyway (given the better AD)? Am I missing sth here? thanks Enno Applying an ingress > interface ACL to each and every external facing interface will probably > work best in the most common deployment scenarios. > > For router-to-router linknets I recommend to configure a linknet that is > as small as possible and is supported by all sides: /127, /126, /120, > etc. Some vendors have put in effort to mitigate the problems related to > Neighbor Discovery Protocol cache exhaustion attacks, but the fact of > the matter is that on small subnets like a /127, /126 or /120 such > attacks simply are non-existent. > > Kind regards, > > Job -- 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: Matthias Luft, Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ===
Re: IPv6 Loopback/Point-to-Point address allocation
Hi, On Sun, Sep 10, 2017 at 12:08:59PM +0200, Job Snijders wrote: > Hi, > > On Sun, Sep 10, 2017 at 11:53:20AM +0200, Enno Rey wrote: > > On Sun, Sep 10, 2017 at 10:47:05AM +0100, Nick Hilliard wrote: > > > Baldur Norddahl wrote: > > > > Loopback interfaces should be configured as /128. How you allocate > > > > these do > > > > not matter. > > > > > > ..so long as there are interface ACLs on your network edge which block > > > direct IP access to these IP addresses. > > > > or, maybe even more efficient, assign all loopbacks from a dedicated > > netblock which you null-route on the edge/your border devices. > > Null-routing may not be sufficient, if the edge/border router has a > route to that /128 good point. I was coming from an Enterprise network perspective where - the border devices do not necessarily hold the/those 128(s) given there's a layer of stateful firewalls in between which creates an isolation boundary for routing protocols. - people do not necessarily fully trust the (outsourced) entities responsible for implementing the filters/ACLs. - this is hence a not-uncommon strategy to feel/be safer as for the (unwanted) global reachability of loopbacks, after the introduction of IPv6. best Enno ; the (forwardable) /128 entry will win from the > blackholed /64 FIB entry since it is more-specific. Applying an ingress > interface ACL to each and every external facing interface will probably > work best in the most common deployment scenarios. > > For router-to-router linknets I recommend to configure a linknet that is > as small as possible and is supported by all sides: /127, /126, /120, > etc. Some vendors have put in effort to mitigate the problems related to > Neighbor Discovery Protocol cache exhaustion attacks, but the fact of > the matter is that on small subnets like a /127, /126 or /120 such > attacks simply are non-existent. > > Kind regards, > > Job -- 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: Matthias Luft, Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ===
Re: IPv6 Loopback/Point-to-Point address allocation
Hi, On Sun, Sep 10, 2017 at 02:25:04PM +0300, Saku Ytti wrote: > On 10 September 2017 at 13:56, Thomas Bellman <bell...@nsc.liu.se> wrote: > > > An alternative is to just have link-local addresses on your point-to- > > point links. At least on your internal links where you run your IGP. > > On external links, where you run eBGP or static routes, it's probably > > more trouble than it is worth, though, since link-local addresses can > > change if you replace the hardware, requiring a config change on the > > other end. (Also, I'm not sure all BGP implementations support using > > link-local addresses.) all BGP implementations I'm aware of do that (support LLAs), BUT at least Cisco's doesn't support using the same LLAs in multiple BGP sessions (e.g. on PE-CE links) which in turn ruins the potential benefits in many environments, see https://ripe72.ripe.net/presentations/122-ERNW_RIPE72_IPv6wg_RFC7404.pdf https://blog.apnic.net/2016/05/31/beauty-ipv6-link-local-addressing-not/ > > This is solvable problem. Vendors support 'bgp listen' or 'bgp allow' > to accept BGP session from specific CIDR range. Similarly you could > allow IPv6 on interface, with SADDR anywhere in link-local. Your own > end link-local stability you could guarantee by manually configuring > MAC address, instead of using BIA. I.e. customers would experience > stable DADDR, but we wouldn't care about customer's SADDR. > > However I don't think market would generally appreciate the > implications linklocal brings to traceroute, where least bad option > would be just to originate hop-limit exceeded from loop0, with no > visibility on actual interface. some might be willing to accept that, as a trade-off for other benefits operations-wise. best Enno -- 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: Matthias Luft, Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ===
Re: IPv6 Loopback/Point-to-Point address allocation
Hi, On Sun, Sep 10, 2017 at 10:47:05AM +0100, Nick Hilliard wrote: > Baldur Norddahl wrote: > > Loopback interfaces should be configured as /128. How you allocate these do > > not matter. > > ..so long as there are interface ACLs on your network edge which block > direct IP access to these IP addresses. or, maybe even more efficient, assign all loopbacks from a dedicated netblock which you null-route on the edge/your border devices. best Enno -- 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: Matthias Luft, Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ===
Re: BCP for securing IPv6 Linux end node in AWS
Hi Eric, in addition to RFC 4980 mentioned in another post you might consider the following sources as a starting point: https://insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-3-traffic-filtering-in-ipv6-networks-i/ https://insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-4-traffic-filtering-in-ipv6-networks-ii/ https://www.troopers.de/media/filer_public/85/be/85bef719-59a4-4567-aebb-ce01f9484f4d/ernw_tr16_ipv6secsummit_enterprise_security_strategy_final.pdf https://www.ernw.de/download/ERNW_Guide_to_Securely_Configure_Linux_Servers_For_IPv6_v1_0.pdf cheers Enno On Sun, May 14, 2017 at 09:29:45AM -0400, Eric Germann wrote: > Good morning all, > > I???m looking for some guidance on best practices to secure IPv6 on Linux end > nodes parked in AWS. > > Boxes will be running various services (DNS for starters) and I???m looking > to secure mainly ICMP at this point. Service filtering is fairly cut and > dried. > > I???ve reviewed some of the stuff out there, but apparently I???m catching > too many of the ICMP types in the rejection as routing eventually breaks. My > guess is router discovery gets broken by too tight of filters. > > Thanks for any guidance. > > EKG > -- 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: ARIN legacy block transfer process
Hi, On Fri, Sep 30, 2016 at 10:26:36AM -0700, Seth Mattinen wrote: > On 9/30/16 09:49, Bryan Fields wrote: > > I'm trying to find a place on ARIN's website where this is addressed, but > > coming up short. I'm not the seller or buyer in this, but basically someone > > has a legacy block allocated by Postel and wants to sell the block as it's > > an > > owned asset. > > > > What's the process to get ARIN to move the admin/ownership of this? Do they > > only need to see a valid asset purchase agreement? There is no legacy RSA > > for > > this. > > > It'll have to go under RSA to stay with ARIN. > > Or you can do a transfer to RIPE. carefully note the "or". If you first move it under ARIN's jurisdiction (by signing an RSA) and *then* transfer it to RIPE, it won't be "legacy" any more in the course of the 2nd step and RIPE's 2-yr holding period comes into play (=> it can't be transferred during that time). Note also there's voices recommending not to sign an RSA for legacy space (in certain situations, at least), see http://ipv4marketgroup.com/dont-sign-an-rsa-during-your-82-ipv4-transfer/. best Enno > > ~Seth -- 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 planning
Hi, On Tue, Mar 08, 2016 at 07:35:55PM +0100, Bj??rn Mork wrote: > > How does Windows manage to *use* three addresses? I can understand how > the rfc7217 address and the privacy address can be use for different > purposes, but what do they use the EUI-64 address for? Windows doesn't use/create a third EUI-64 address. By default it only creates that "kind-of random, kind-of stable" address (unrelated to RFC 2117) and a temporary address. No EUI-64 address (by default). It *can* create, by a specific setting, an EUI-64 address but that would replace the above mentioned 1st (non-temporary) one. best Enno > > > Bj??rn -- 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: Android and DHCPv6 again
Hi,
On Tue, Oct 06, 2015 at 08:59:14PM -0430, Alejandro Acosta wrote:
> Hello,
> This is a question a should test myself but anyhow I would like to
> hear your comments.
> What happen (on the client side/Android maybe) if I advertise the DNS
> information in the RA and I also enable the O bit?
depends on the OS the client is running, see
https://www.ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_DHCPv6_Conflicting_Parameters.pdf
&
https://www.ernw.de/download/ERNW_RIPE70_IPv6_Behavior_Conflicting_Environments_v0_92_short.pdf
best
Enno
>
> Thanks,
>
> Alejandro,
>
> El 10/6/2015 a las 8:39 PM, Bruce Horth escribi??:
> > Your device may be getting an address, but without a recursive DNS server
> > it may be useless.
> >
> > If you're going to do SLAAC you'll also need to supply your client with a
> > recursive DNS server. Android prefers RFC 6106. As you mentioned, Google
> > has decided not to support DHCPv6 in Android. Unfortunately some router
> > manufacturers are only now getting around to implementing RFC 6106.
> >
> >
> >
> >
> > BH
> >
> > On Sat, Oct 3, 2015 at 9:52 PM, Baldur Norddahl <baldur.nordd...@gmail.com>
> > wrote:
> >
> >> Hi
> >>
> >> I noticed that my Nexus 9 tablet did not have any IPv6 although everything
> >> else in my house is IPv6 enabled. Then I noticed that my Samsung S6 was
> >> also without IPv6. Hmm.
> >>
> >> A little work with tcpdump and I got this:
> >>
> >> 03:27:15.978826 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 120)
> >> fe80::222:7ff:fe49:ffad > ip6-allnodes: [icmp6 sum ok] ICMP6, router
> >> advertisement, length 120
> >> hop limit 0, Flags [*managed*, other stateful], pref medium, router
> >> lifetime 1800s, reachable time 0s, retrans time 0s
> >> source link-address option (1), length 8 (1): 00:22:07:49:ff:ad
> >> mtu option (5), length 8 (1): 1500
> >> prefix info option (3), length 32 (4): 2a00:7660:5c6::/64, Flags [onlink,
> >> *auto*], valid time 7040s, pref. time 1800s
> >> unknown option (24), length 16 (2):
> >> 0x: 3000 1b80 2a00 7660 05c6
> >>
> >> So my CPE is actually doing DHCPv6 and some nice people at Google decided
> >> that it will be better for me to be without IPv6 in that case :-(.
> >>
> >> But it also has the auto flag, so Android should be able to do SLAAC yes?
> >>
> >> My Macbook Pro currently has the following set of addresses:
> >>
> >> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> >> ether 3c:15:c2:ba:76:d4
> >> inet6 fe80::3e15:c2ff:feba:76d4%en0 prefixlen 64 scopeid 0x4
> >> inet 192.168.1.214 netmask 0xff00 broadcast 192.168.1.255
> >> inet6 2a00:7660:5c6::3e15:c2ff:feba:76d4 prefixlen 64 autoconf
> >> inet6 2a00:7660:5c6::b5a5:5839:ca0f:267e prefixlen 64 autoconf temporary
> >> inet6 2a00:7660:5c6::899 prefixlen 64 dynamic
> >> nd6 options=1
> >> media: autoselect
> >> status: active
> >>
> >> To me it seems that the Macbook has one SLAAC address, one privacy
> >> extension address and one DHCPv6 managed address.
> >>
> >> In fact the CPE manufacturer is a little clever here. They gave me an easy
> >> address that I can use to access my computer ("899") while still allowing
> >> SLAAC and privacy extensions. If I want to open ports in my firewall I
> >> could do that to the "899" address.
> >>
> >> But why is my Android devices without IPv6 in this setup?
> >>
> >> Regards,
> >>
> >> Baldur
> >>
>
--
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: Estonian IPv6 deployment report
Hi, On Sat, Dec 27, 2014 at 05:15:13PM +0100, Anders L??winger wrote: On 2014-12-22 16:27, Tarko Tikan wrote: Our access network is mix of DSL/GPON/wimax/p2p-ETH and broadband service is deployed in shared service vlans. IPv6 traffic shares vlan with IPv4. How do you protect customers from each other? There are many nasty IPv6 attacks you can do when on a shared VLAN. true, but some (most) of them only apply in networks where multicasting/ND is fully supported which is not necessarily the case in the above type of networks. and, from what I understand, in their scenario RAs are not sent to link-local scope all nodes (ff02::1), so that would eliminate another attack vector (depending on the actual processing of RAs on the CPEs). best Enno /Anders -- 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: Seeking IPv6 Security Resources
Hi, On Wed, Nov 26, 2014 at 08:54:07AM -0500, Joe Klein wrote: Chris, Are you aware IPv6 has 3 or arguably 4 major generations of standards? Each generation requires nuanced defense strategies, based on which clauses (must and should) were implemented. Some of the derived security works, do not reflect, and in some cases contradict current security recommendations. both very good points, Joe, which I fully second. This is - to some degree - discussed in this talk: https://www.ernw.de/download/TROOPERS_IPv6SecSummit_ERNW_IPv6_Structural_Deficits.pdf which I suggest to add to the resource list in compilation. [disclaimer: I'm the author] best Enno The perceived newness of the technology, and ambiguities of recommendations have resulted in 'pushback' by the security community to implement IPv6. This has forced us to continue with the implement of IPv6 and 'trust' the vender recommendations, based on the limitations of that venders products. In the cracks, between the standards and implementation of these standards, are where security vulnerabilities exist, compromises lay, and defenses crumble. Joe Klein Inveniam viam aut faciam On Tue, Nov 25, 2014 at 3:32 PM, Chris Grundemann cgrundem...@gmail.com wrote: Hail NANOG! I am looking for IPv6 security resources to add to: http://www.internetsociety.org/deploy360/ipv6/security/ These could be best current practice documents, case-studies, lessons-learned/issues-found, research/evaluations, RFCs, or anything else focused on IPv6 security really. I'm not requesting that anyone do any new work, just that you point me to solid public documents that already exist. Feel free to share on-list or privately, both documents you may have authored and those you have found helpful. Thanks! ~Chris Note: Not every document shared will get posted to the Deploy360 site. -- @ChrisGrundemann http://chrisgrundemann.com -- 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 Default Allocation - What size allocation for Loopback Address
Hi, On Sun, Oct 12, 2014 at 02:53:36PM +0200, Sander Steffann wrote: Hi, Op 11 okt. 2014, om 23:00 heeft Roland Dobbins rdobb...@arbor.net het volgende geschreven: On Oct 11, 2014, at 2:09 PM, Tim Raphael raphael.timo...@gmail.com wrote: From my research, various authorities have recommended that a single /64 be allocated to router loopbacks with /128s assigned on interfaces. Yes, this is what I advocate for loopbacks. I often use the first /64 for loopbacks. I'm not a big fan of using all-zero third or fourth quarters of $PREFIX at all (at least not if one follows RFC 5952 uses static, short IIDs, which will be case for loopbacks). On a crowded visio diagram it might not be easy to spot that 2001:db8::1, 2001:db8:0:1::1, 2001:db8:1::1 and 2001:db8:1:1::1 are all different addresses, potentially on the same hierarchy level. Hence we prefer to use or just FF at some point within the prefix for loopbacks, e.g. 2001:db8:FF::1 etc. best Enno Loopbacks are often used for management, iBGP etc and having short and easy to read addresses can be helpful. Something like 2001:db8::1 is easier to remember and type correctly than e.g. 2001:db8:18ba:ff42::1 :) Cheers, Sander -- 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: Requirements for IPv6 Firewalls
Hi, On Thu, Apr 17, 2014 at 06:55:24PM +0200, Sander Steffann wrote: Hi Bill, Also, I note your draft is entitled Requirements for IPv6 Enterprise Firewalls. Frankly, no enterprise firewall will be taken seriously without address-overloaded NAT. I realize that's a controversial statement in the IPv6 world but until you get past it you're basically wasting your time on a document which won't be useful to industry. I disagree. While there certainly will be organisations that want such a 'feature' it is certainly not a requirement for every (I hope most, but I might be optimistic) enterprises. I fully second Sander's input. I've been involved in IPv6 planning in a number of very large enterprises now and _none_ of them required/asked for (66/overloading) NAT for their firewall environments. A few think about very specific deployments of NPTv6 like stuff for connections to supplier/partner networks (to map those to their own address space) but these are corner cases not even relevant for their firewalls. best Enno Cheers, Sander -- 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: Requirements for IPv6 Firewalls
Hi, On Fri, Apr 18, 2014 at 04:57:57PM +1000, Matt Palmer wrote: On Thu, Apr 17, 2014 at 09:05:17PM -0500, Timothy Morizot wrote: On Apr 17, 2014 7:52 PM, Matthew Kaufman matt...@matthew.at wrote: While you're at it, the document can explain to admins who have been burned, often more than once, by the pain of re-numbering internal services at static addresses how IPv6 without NAT will magically solve this problem. If you're worried about that issue, either get your own end user assignment(s) from ARIN or use ULA internally and employ NAT-PT (prefix translation) at the perimeter. That's not even a hard question. Why use NAT-PT in that instance? Since IPv6 interfaces are happy running with multiple addresses, the machines can have their publically-accessable address and also their ULA address, with internal services binding to (and referring to, via DNS, et al) the ULA address there's two problems with that approach: a) what is an internal service? In a world of complex data center environments running/offering all types of services to various parties ($ORG's employees, business partners, customers and closed groups from customers, public/Internet) you can't make that distinction any longer. And even if you could, latest trying to reflect that distinction in your DNS setup will screw you. At the end of the day you'll still end up in address selection hell. b) from my operational experience address selection is still a hugely unresolved problem, despite RFC 3484 and RFC 6724. As long as this (problem) persists, from our perspective there's a simple recommendation/solution: when there's a [continued] decision problem, just don't offer a choice. Read, in IPv6 context: go with GUAs only and only one per interface. best Enno -- 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: Requirements for IPv6 Firewalls
Hi, On Fri, Apr 18, 2014 at 11:59:04AM -0700, Doug Barton wrote: On 04/18/2014 12:57 AM, Enno Rey wrote: I fully second Sander's input. I've been involved in IPv6 planning in a number of very large enterprises now and_none_ of them required/asked for (66/overloading) NAT for their firewall environments. A few think about very specific deployments of NPTv6 like stuff for connections to supplier/partner networks (to map those to their own address space) but these are corner cases not even relevant for their firewalls. How many of those networks were implementing with IPv6 PI space? all of them My experience has been that those customers are not interested in IPv6 NAT, but instead utilize network segmentation to define internal vs. external. OTOH, customers for whom PI space is not realistic (for whatever reasons, and yes there are reasons) are very interested in the combination of ULA + NTPv6 to handle internal resources without having to worry about renumbering down the road. true. it's just we don't see many of those (actually I've yet to encounter a single one) and it could be debatable if they belong to Enterprise networks (which is in the title of the ID). best Enno Doug -- 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 isn't SMTP
Hi, On Thu, Mar 27, 2014 at 01:52:27PM +, Tony Finch wrote: John Levine jo...@iecc.com wrote: There are also some odd things in the spec. For example, according to RFC 5321 this is not a syntactically valid e-mail address: mailbox@[IPv6:2001:12:34:56::78:ab:cd] You aren't allowed to use :: to abbreviate one zero hexadectet according to RFC 5952. well, RFC 5952 _recommends_ against using that. Still, it's perfectly valid as of RFC 4291 and the approach can be found in quite large vendors' implementations, see http://labs.apnic.net/blabs/?p=309. RFC 5952 explicitly states: all implementations must accept and be able to handle any legitimate RFC 4291 format. best Enno http://www.rfc-editor.org/errata_search.php?eid=2467 Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Malin: East 5 or 6. Moderate or rough, occasionally very rough in northwest. Showers. Good, occasionally moderate. -- 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: turning on comcast v6
Hi, On Thu, Jan 02, 2014 at 08:57:14PM -0800, Matthew Kaufman wrote: On 12/30/2013 4:56 PM, Owen DeLong wrote: You can accomplish the same thing in IPv4?. Plug in Sally?s PC with Internet Connection Sharing turned on and watch as her DHCP server takes over your network. for the record it should be noted that this particular issue was fixed by Microsoft a while ago (see http://support.microsoft.com/kb/2750841/en-us). best Enno Not nearly as fast as bad RAs do (as others have pointed out). Yes, you have to pay attention when you plug in a router just like you?d have to pay attention if you plugged in a DHCP server you were getting ready to recycle. But the ability to plug in a not-router and break things is oh so much greater. Incompetence in execution really isn?t the protocol?s fault. But it is the protocol designer's fault... and once shipped, the protocol's fault. There's all sorts of things that were known at the time IPv6 was designed that the designers failed to build solutions for. As an example, routers *could* be a lot smarter about sending RAs on a network where routers are already present, but that's not in the spec. Neither the ND DOS attack nor the need to protect against bogus RAs on every port of your switch but one (or rarely, two) are things that should have been a post-deployment surprise (to name just a couple pet peeves of mine... there's more design flaws that could have been easily avoided had enough people cared to do so). Matthew Kaufman -- 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 ===
Re: NSA able to compromise Cisco, Juniper, Huawei switches
Hi, some approaches were discussed in 2010, by Graeme Neilson from NZ here: https://www.troopers.de/wp-content/uploads/2012/10/TROOPERS10_Netscreen_of_the_Dead_Graeme_Neilson.pdf a later year, at the same conference, he gave a private session demonstrating basically the same stuff for JunOS, as ongoing (and, at the time, non-public) research. happy NYE to everybody Enno On Tue, Dec 31, 2013 at 06:50:11PM +0200, Saku Ytti wrote: On (2013-12-31 09:03 -0600), Leo Bicknell wrote: If I were Cisco/Juniper/et all I would have a team working on this right now. It should be trivial for them to insert code into the routers that say, hashes all sorts of things (code image, BIOS, any PROMS and EERPOMS and such on the linecards) and submits all of those signatures back. Any I asked earlier today JTAC (#2013-1231-0033) and JTAC asked SIRT for tool to read BIOS and output SHA2 or SHA3 hash, and such tool does not exist yet. I'm dubious, it might be possible even with existing tools. At least it's possible to reflash the BIOS with stock JunOS, as lot of us had to do due to misformatted SSD disks. But fully agreed some of these sanity checks should be added, it's not cure all, maybe the attack changes the answers before showing them, maybe BIOS comes infected from Juniper or from Kontron. But it would create additional barrier. I also emailed Kontrol and told it would be prudent for them to do press release also. Just to know what their public/official statement is. I also wonder how this will change engineering going forward. Maybe the BIOS should be a ROM chip, not an EEPROM again. Maybe the write line needs to be run through a physical jumper on the motherboard that is normally not present. We can take page from XBOX360 which is designed to be resistant against attack with physical access. Key idea is that use PKI and hide key in such place where it's difficult to recover, namely, if it's inside modern lithography CPU in read-only, it's just financially unviable vector. MS just goofed and forgot to sign DVD firmware. Why do we accept our devices, be it a PC or a router, can be persistently infected. The hardware industry needs to do better. I'm still taking all these revelations with grain of salt, until real speciment is dissected. -- ++ytti -- 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 ===
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Mon, Dec 30, 2013 at 04:03:07PM +, Dobbins, Roland wrote: On Dec 30, 2013, at 10:44 PM, valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote: What percentage of Cisco gear that supports a CALEA lawful intercept mode is installed in situations where CALEA doesn't apply, and thus there's a high likelyhood that said support is misconfigured and abusable without being noticed? AFAIK, it must be explicitly enabled in order to be functional. It isn't the sort of thing which is enabled by default, nor can it be enabled without making explicit configuration changes. at least back in 2007 it could be enabled/configured by SNMP RW access [see slide 43 of the presentation referenced in this post http://www.insinuator.net/2013/07/snmp-reflected-amplification-ddos-attacks/] so knowing the term private m ight be enough to perform the task remotely. have a good one Enno --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton -- 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 ===
Re: Automatic IPv6 due to broadcast
Hi, On Mon, Apr 23, 2012 at 12:27:53PM -0400, valdis.kletni...@vt.edu wrote: On Mon, 23 Apr 2012 11:23:14 -0400, Chuck Anderson said: On Mon, Apr 23, 2012 at 06:38:09AM -0700, Owen DeLong wrote: In a lot of cases, enforcing that all address assignments are via DHCP can still be counter-productive. Especially in IPv6. If a specific managed environment provides DHCPv6 and doesn't provide SLAAC, and the policies of said environment forbid static addressing, That's totally different from Owen's in a lot of cases. Incidentally, there's absolutely nothing except for LLT being the default DUID generation mechanism on pretty much every OS... thanks Enno preventing a DHCPv* server from being configured to always hand out the same IP address to a given MAC address, making it effectively static (in fact, I've seen more than one site that carries nailed down DHCP entries for servers, just to ensure that even if the server gets borked and decides to DHCP itself, it will still come up with the right address anyhow). how can enforcing the use of DHCPv6 be counter-productive? Remember, Owen was talking about in a lot of cases. I suspect Owen was saying that if you enforce that all source addresses are ones that the DHCPv6 server handed out, you just broke a host that tries to do RFC4941 addresses or other similar things. -- Enno Rey ERNW GmbH - Breslauer Str. 28 - 69124 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 174 3082474 PGP FP 055F B3F3 FE9D 71DD C0D5 444E C611 033E 3296 1CC1 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de ===
