Re: BGP route hijack by AS10990

[Jeff Bilyk]

We appeared to be impacted with some address space within 206.47.0.0/16
which AS577 normally advertises, but that was between 15:50 and 16:30
Eastern.

Jeff

On Wed, Jul 29, 2020, 10:48 PM Clinton Work  wrote:

> We saw a bunch of our IP blocks hijacked by AS10990 from 19:15 MDT until
> 20:23 MDT.   Anybody else have problems with that.
>
> ASpath:  1299 7219 10990
>
> 50.92.0.0/17AS10990
> 198.166.0.0/17   AS10990
> 198.166.128.0/17AS10990
> 162.157.128.0/17AS10990
> 162.157.0.0/17  AS10990
> 50.92.128.0/17  AS10990
>
>
>
> --
> Clinton Work
> Airdrie, AB
>

Re: Massive Spectrum Outage

[Roy]

Northern CA is fine.  Cable and fiber both operating

On 7/29/2020 7:36 PM, Kenneth McRae via NANOG wrote:

Anyone outside of S. California affected?

BGP route hijack by AS10990

[Clinton Work]

We saw a bunch of our IP blocks hijacked by AS10990 from 19:15 MDT until 20:23 
MDT.   Anybody else have problems with that. 

ASpath:  1299 7219 10990

50.92.0.0/17AS10990
198.166.0.0/17   AS10990
198.166.128.0/17AS10990
162.157.128.0/17AS10990
162.157.0.0/17  AS10990
50.92.128.0/17  AS10990



--
Clinton Work
Airdrie, AB

Massive Spectrum Outage

[Kenneth McRae via NANOG]

Anyone outside of S. California affected?

Re: Finish Line/JD Sports Contact

[Chris Gross]

Got a contact, delisted and found a local contact we had too, thank you 
everyone.

Chris Gross
NineStar Connect


From: NANOG  on behalf of 
Chris Gross 
Sent: Tuesday, July 28, 2020 4:22 PM
To: nanog list 
Subject: Finish Line/JD Sports Contact

Does anyone have a contact from Finish Line/JD Sports or someone that can 
resolve a block issue reach out to me please? Seems my whole AS is being 
blocked by their configured Akamai filtering. Chris G
Danger (External, cgr...@ninestarconnect.com)
Potential Sender Forgery, Spoofed Internal Sender   
Details
Report This 
Email


Does anyone have a contact from Finish Line/JD Sports or someone that can 
resolve a block issue reach out to me please? Seems my whole AS is being 
blocked by their configured Akamai filtering.



Chris Gross

Re: Question on BlackBox or Commworks

[Brandon Svec]

For national (U.S.), on site techs I can recommend
http://www.servicecommunications.com we subcontract for them on the regular
and they run a tight ship and have many large national accounts.  I would
not get hung up on choosing someone with their own employees vs.
contracting or hybrid, but more on choosing a company with experience
managing projects like yours and a good project management team to run the
show.

It all depends on the nature of your project, of course. There are "self
service" tools like Field Nation and Work Market that you can find all your
own techs and they handle 1099 and insurance, etc. for you.
*Brandon Svec*

*15106862204 <15106862204> voice | sms**teamonesolutions.com
*


On Wed, Jul 29, 2020 at 10:06 AM Joseph Jenkins 
wrote:

> Do you know or have experience with either company? Do they have their own
> techs are they just bidding out for local techs in the area? I have work
> that needs to be done all across the US and just trying to look for some
> options.
>

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Owen DeLong]

> On Jul 29, 2020, at 09:43 , Douglas Fischer  wrote:
> 
> Does anybody here knows what Gambiarra means?

The english translation would be “Jury Rig” or “Hack”.
Synonyms include “McGyverism”, “Rube Goldberg”, “Kludge”, etc.

Foreign address family as next-hop is definitely in this category.

> 
> Alejandro mentioned that IPv6 NextHop on IPv4 routing breaks traceroute and 
> difficult troubleshooting.

It doesn’t really break trace route, but it does complicate troubleshooting.

The next hop device won’t know that the IPv4 packet arrived via IPv6 next hop. 
If the device has an IPv4 address, it will still
report that in the trace route. Of course, that won’t match the expected 
next-hop from the routing table on the previous device,
but it will still be reported.

If it doesn’t have an IPv4 address, then one has to wonder how that’s going to 
work for what it will do with the packet anyway.
In such a case, I would expect that it breaks more than trace route.

Troubleshooting is difficult because it requires significant indirection to 
figure out what’s really going on and because it creates
a good bit of cognitive dissonance in the human analysis part of the 
troubleshooting effort.

> Well... Since a while I have been thinking about a Gambiarra that I'm using 
> on other scenarios, but I think could help to reduce de bad impacts of IPv6 
> NextHop on IPv4 routing.
> 
> O router with several interfaces with IPv6 only and at least one public IPv4 
> /32 on his loopback.
> On the IPv4 address on each of that v6 only interfaces, use "IP address 
> unnumbered loopback 0".
> 
> This would make the ICMP responses for TTL expired be sourced with that 
> public IPv4.
> 
> Would not be as good as one public IP for each interface, but at least, on a 
> traceroute, would be possible to Defined what ASN is responsible for that 
> hop, and exactly in what router it occurs.

You most likely get the same result whether you add the unnumbered 
configuration or not on a router where the only IPv4 address is on the loopback 
interface.

Owen

RE: Question on BlackBox or Commworks

[Marshall, Quincy]

I back Mike’s comments, they support some of our on-prem hardware/software. To 
my knowledge their senior techs/engineers work remote. For on-site they do not 
farm services to 3rd parties but to the local BB office. This means the field 
tech may be trained in the solution but may not be an expert. (I’m certain 
there is some logic to the assignment, if the expert should come from the 2nd 
closest location.) There are going to be those who understand it and those who 
can just follow the script.

We’ve not needed to dispatch local. Our engineer contact have been excellent so 
far.
LQ Marshall | Sr. Network Engineer

From: NANOG  On Behalf Of 
Mike Bolitho
Sent: Wednesday, July 29, 2020 1:33 PM
To: Joseph Jenkins 
Cc: NANOG 
Subject: Re: Question on BlackBox or Commworks

We currently use BlackBox and they use their own techs where I'm at (Phoenix). 
We also used them extensively when I worked for Level 3 several years ago. As 
with anything, your experience with them will vary largely by location and can 
even vary within a market. I have dealt with some awesome BlackBox techs. And I 
have dealt with some really bad BlackBox techs. The guys I work with on a 
regular basis in Phoenix are great.

- Mike Bolitho


On Wed, Jul 29, 2020 at 10:05 AM Joseph Jenkins 
mailto:j...@breathe-underwater.com>> wrote:
Do you know or have experience with either company? Do they have their own 
techs are they just bidding out for local techs in the area? I have work that 
needs to be done all across the US and just trying to look for some options.
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

Re: Question on BlackBox or Commworks

[Mike Bolitho]

We currently use BlackBox and they use their own techs where I'm at
(Phoenix). We also used them extensively when I worked for Level 3 several
years ago. As with anything, your experience with them will vary largely by
location and can even vary within a market. I have dealt with some awesome
BlackBox techs. And I have dealt with some really bad BlackBox techs. The
guys I work with on a regular basis in Phoenix are great.

- Mike Bolitho


On Wed, Jul 29, 2020 at 10:05 AM Joseph Jenkins 
wrote:

> Do you know or have experience with either company? Do they have their own
> techs are they just bidding out for local techs in the area? I have work
> that needs to be done all across the US and just trying to look for some
> options.
>

Question on BlackBox or Commworks

[Joseph Jenkins]

Do you know or have experience with either company? Do they have their own
techs are they just bidding out for local techs in the area? I have work
that needs to be done all across the US and just trying to look for some
options.

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Douglas Fischer]

Does anybody here knows what Gambiarra means?

Alejandro mentioned that IPv6 NextHop on IPv4 routing breaks traceroute and
difficult troubleshooting.

Well... Since a while I have been thinking about a Gambiarra that I'm using
on other scenarios, but I think could help to reduce de bad impacts of IPv6
NextHop on IPv4 routing.

O router with several interfaces with IPv6 only and at least one public
IPv4 /32 on his loopback.
On the IPv4 address on each of that v6 only interfaces, use "IP address
unnumbered loopback 0".

This would make the ICMP responses for TTL expired be sourced with that
public IPv4.

Would not be as good as one public IP for each interface, but at least, on
a traceroute, would be possible to Defined what ASN is responsible for that
hop, and exactly in what router it occurs.

Em qua, 29 de jul de 2020 08:25, Alejandro Acosta <
alejandroacostaal...@gmail.com> escreveu:

> Long time ago I tried it out:
>
>
> https://blog.acostasite.com/2013/02/publicar-prefijos-ipv4-sobre-una-sesion.html
>
>
> https://blog.acostasite.com/2013/02/publicando-prefijos-ipv6-sobre-sesiones.html
>
>
> I did not like, difficult troubleshooting in case something goes wrong
> (however I can understand it's a nice feature to have and in might be
> useful in some scenarios).
>
>
> But you are right I do not know much about networks doing it, I also would
> like hear about it.
>
>
> Alejandro,
>
>
> On 7/29/20 1:51 AM, Douglas Fischer wrote:
>
> Let's just jump all the arguing about lack of IPv4, the need of IPv6, and
> etc...
>
> I must confess that I don't know all the RFCs.
> I would like it, but I don't!
>
> And today, I reached on https://tools.ietf.org/html/rfc5549
>
> I knew that was possible to transfer v4 routes over v6 BGP sessions, or v6
> routes over v4 BGP sessions.
> But I got surprised when I saw this youtube vídeo of AMS-IX guys
> considering use a v6 only Lan, and doing v6 next-hops to v4 routes.
> https://www.youtube.com/watch?v=uJOtfiHDCMw
>
> Well... I guess that idea didn't go to production.
>
>
>
> But the questions are:
> There is any network that really implements RFC5549?
> Can anyone share some information about it?
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>
>

NANOG Women in Tech: A conversation with Kat Ronay

[NANOG News]

*“In talking to some of the other women in the industry, I'm sort of a
unicorn — I‘ve actually been very, very fortunate.”*

Our newest series on NANOG TV explores the stories and career paths of some
of the most exceptional women we know. Watch our second interview,
featuring Kat Ronay of Microsoft, to learn more about her experience as a
woman navigating the world of network engineering.

Watch Now 

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Mark Tinka]

On 29/Jul/20 18:35, Nick Hilliard wrote:

> You can't use hostnames, if that's what you're asking.

Yes, couldn't fathom how.

So really it's convenience of troubleshooting, not convenience of setup
:-). I can live with that.


>   FRR will also do
> unnumbered BGP with auto-config.

Interesting...

Mark.

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Nick Hilliard]

Mark Tinka wrote on 29/07/2020 17:06:
> Meaning the initial setup would still require the use of literal IP
> addresses?

You can't use hostnames, if that's what you're asking.  FRR will also do
unnumbered BGP with auto-config.

Nick

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Chriztoffer Hansen]

On Wed, 29 Jul 2020 at 18:06, Mark Tinka wrote:
> On 29/Jul/20 16:54, Nick Hilliard wrote:
> > it's a capability negotiation, so is handled on session setup.
>
> Meaning the initial setup would still require the use of literal IP addresses?

Unless your (e.g. DC equipment) is set up for automatic bgp neighbour
discovery using IPv6 ND+RA [2]. Then yes.

[0]: 
https://github.com/FRRouting/frr/commit/04b6bdc0ee6275442464edec1d14b3f4d3eaa246
[1]: https://github.com/FRRouting/frr/search?p=3=hostname=Commits
[2]: 
https://docs.cumulusnetworks.com/cumulus-linux/Layer-3/Border-Gateway-Protocol-BGP/#configure-bgp-unnumbered-interfaces

--
Cheers,
CHRIZTOFFER

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Mark Tinka]

On 29/Jul/20 16:57, Saku Ytti wrote:

> I'm not sure I understand what the option space is. This is like ISIS
> TLV137, protocol will populate some trash there and you'll politely
> access. It won't allow you to refer to the peer with any name prior to
> having the session up. Much like you won't see ISIS neighbours name
> when session is establishing, until it has actually loaded and
> processed the TLV137.

The IS-IS comparison came to mind as well, yes. But IS-IS is different
in that LSP's are dynamically flooded upon activation on an interfaces,
and those LSP's carry router information, including hostname.

BGP is not dynamically setup, so in my mind, you still need literal IP
addresses to set sessions up, and then this BGP hostname capability
would translate those IP addresses to remote hostnames after the
sessions have been established.

I just wanted to clarify if this is the practical implementation and
operation of the same, as the draft isn't specific on it, as I'm sure
others may consider the same thought process.

Mark.

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Mark Tinka]

On 29/Jul/20 16:54, Nick Hilliard wrote:

>
> it's a capability negotiation, so is handled on session setup.

Meaning the initial setup would still require the use of literal IP
addresses?

Mark.

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Saku Ytti]

On Wed, 29 Jul 2020 at 18:51, Owen DeLong  wrote:

> In reality, next hop isn’t really a layer 3 address. The layer 3 address is a 
> stand-in that is resolved to
> a layer 2 address for forwarding. The layer 3 next-hop address never makes it 
> into the packet.

I wish you had shared in the draft process so they could have
benefitted from your insight into the proper verbiage.

-- 
  ++ytti

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Owen DeLong]

> On Jul 29, 2020, at 02:13 , Saku Ytti  wrote:
> 
> On Wed, 29 Jul 2020 at 10:03, Vincent Bernat  wrote:
> 
>> This is the solution Cumulus is advocating to its users, so I suppose
>> they have some real users behind that. Juniper also supports RFC 5549
>> but, from the documentation, the forwarding part is done using
>> lightweight tunnels.
> 
> I'm not sure if you claim otherwise, but no real 'tunneling' takes
> place, as far as I know, it's internal implementation detail having
> IPV6 next-hop for IPV4. I don't think there is any additional headers
> or any additional lookup or cost.
> Cisco supports extended nexthop encoding too, so it is fairly well
> supported by shipping products.

In reality, next hop isn’t really a layer 3 address. The layer 3 address is a 
stand-in that is resolved to
a layer 2 address for forwarding. The layer 3 next-hop address never makes it 
into the packet.
As such, the relationship between the destination address family and the 
next-hop address
family is mostly to avoid breaking the brains of humans. Software to handle 
mixed-address-families
in next hop vs. destination should be a relatively trivial difference from 
software that requires the
address families to match.

Owen

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Saku Ytti]

On Wed, 29 Jul 2020 at 17:54, Mark Tinka  wrote:

> I'm curious to know if this is after-the-fact, as I can't think of a way
> that BGP would find hostnames to setup sessions with, outside of some
> kind of upper layer name resolution capability.
>
> The draft isn't clear on how this happens, if it is, indeed,
> before-the-fact.

I'm not sure I understand what the option space is. This is like ISIS
TLV137, protocol will populate some trash there and you'll politely
access. It won't allow you to refer to the peer with any name prior to
having the session up. Much like you won't see ISIS neighbours name
when session is establishing, until it has actually loaded and
processed the TLV137.



-- 
  ++ytti

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Nick Hilliard]

Mark Tinka wrote on 29/07/2020 15:51:
> I'm curious to know if this is after-the-fact, as I can't think of a way
> that BGP would find hostnames to setup sessions with, outside of some
> kind of upper layer name resolution capability.
> 
> The draft isn't clear on how this happens, if it is, indeed,
> before-the-fact.

it's a capability negotiation, so is handled on session setup.

Nick

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Mark Tinka]

On 29/Jul/20 16:30, Nick Hilliard wrote:

>
> afaik, this is an implementation of draft-walton-bgp-hostname-capability.

Nice.

I'm curious to know if this is after-the-fact, as I can't think of a way
that BGP would find hostnames to setup sessions with, outside of some
kind of upper layer name resolution capability.

The draft isn't clear on how this happens, if it is, indeed,
before-the-fact.

Mark.

Re: Tips on dealing with illicit BGP announcements

[Douglas Fischer]

The primary thing that you need to do is to create ROAs of your block
allowing only your ASN as Origin.

Second, as Siyuan and Justin mentioned, get in touch with Merit RADB.
They are great! If you do the full job right in the first e-mail,
presenting the allocation of the RIR and the transfer, they solve at the
first interaction.

And, beyond asking RADB to remove the wrong route objects, you need to
create your correct route objects.
You can use any IRR that is replicated with RADB... But RADB is a de-facto
standard.

Em sex., 24 de jul. de 2020 às 03:07, Randy Carpenter 
escreveu:

>
> I am working with a client that has recently purchased and transferred an
> IPv4 block.
>
> Sometime in between when the purchase and research was done and when the
> transfer was actually complete, an entity in Asia started illicitly
> announcing a larger block that includes the block in question. They even
> have gotten an RADB entry in place for it.
>
> Does anyone have some tips on how to deal with this? I have a feeling that
> dealing directly with the offending entity will not be very fruitful.
>
> thanks,
> -Randy
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Nick Hilliard]

Mark Tinka wrote on 29/07/2020 15:09:
> Are the names based on DNS look-ups, or is there some kind of protocol
> association between the device underlay and its hostname, as it pertains
> to neighbors?

afaik, this is an implementation of draft-walton-bgp-hostname-capability.

Nick

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Mark Tinka]

On 29/Jul/20 15:51, Simon Leinen wrote:

>
> Neighbor   V   AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down 
> State/PfxRcd
> sw-o(swp16)465108  953559  938348000 03w5d00h 
>  688
> sw-m(swp18)465108  885442  938348000 03w5d00h 
>  688
> s0001(swp1s0.3)465300  748971  748977000 03w5d00h 
>1
> s0002(swp1s1.3)465300  661787  661794000 03w1d23h 
>1
> s0003(swp1s2.3)465300  748970  748977000 03w5d00h 
>1
> s0004(swp1s3.3)465300  661868  661875000 03w1d23h 
>1
> s0005(swp2s0.3)465300  748970  748976000 03w5d00h 
>1
> [...]
>
> Note the host names/interface names - this is how you generally refer to
> neighbors, rather than using literal (IPv6) addresses.

Are the names based on DNS look-ups, or is there some kind of protocol
association between the device underlay and its hostname, as it pertains
to neighbors?

Mark.

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Simon Leinen]

Douglas Fischer writes:
> And today, I reached on https://tools.ietf.org/html/rfc5549
[...]
> But the questions are:
> There is any network that really implements RFC5549?

We've been using it for more than two years in our data center networks.
We use the Cumulus/FRR implementation on switches and FRR on Ubuntu on
servers.

> Can anyone share some information about it?

Sure.  We found the FRR/Cumulus implementation very easy to set up.  We
have leaf/spine networks interconnecting hundreds of servers (IPv4+IPv6)
with very minimalistic configuration.  In particular, you generally
don't have to configure neighbor addresses or AS numbers, because those
are autodiscovered.  I think we're basically following the
recommendations in the "BGP in the Data Center" book including the "BGP
on the Host" part (though our installation predates the book, so there
might be some differences).

The network has been working very reliably for us, so we never really
had anything to debug.  If you're coming from a world where you used
separate BGP sessions to exchange IPv4 and IPv6 reachability
information, then the operational commands take a little getting used
to, but in the end I find it very intuitive.

For example, here's one of the "show bgp ... summary" commands on a leaf
switch:

leinen@sw-f:mgmt-vrf:~$ net show bgp ipv6 uni sum
BGP router identifier 10.1.1.46, local AS number 65111 vrf-id 0
BGP table version 96883
RIB entries 1528, using 227 KiB of memory
Peers 54, using 1041 KiB of memory
Peer groups 2, using 128 bytes of memory

Neighbor   V   AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down 
State/PfxRcd
sw-o(swp16)465108  953559  938348000 03w5d00h   
   688
sw-m(swp18)465108  885442  938348000 03w5d00h   
   688
s0001(swp1s0.3)465300  748971  748977000 03w5d00h   
 1
s0002(swp1s1.3)465300  661787  661794000 03w1d23h   
 1
s0003(swp1s2.3)465300  748970  748977000 03w5d00h   
 1
s0004(swp1s3.3)465300  661868  661875000 03w1d23h   
 1
s0005(swp2s0.3)465300  748970  748976000 03w5d00h   
 1
[...]

Note the host names/interface names - this is how you generally refer to
neighbors, rather than using literal (IPv6) addresses.

Otherwise it should look very familiar if you have used vendor C's
"industry-standard CLI" before.

(In case you're wondering, the first two neighbors in the output are
spine switches, the others are servers.)

Cheers,
-- 
Simon.

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Saku Ytti]

Hey,

On Wed, 29 Jul 2020 at 14:26, Alejandro Acosta
 wrote:

> https://blog.acostasite.com/2013/02/publicar-prefijos-ipv4-sobre-una-sesion.html
> https://blog.acostasite.com/2013/02/publicando-prefijos-ipv6-sobre-sesiones.html
>
> I did not like, difficult troubleshooting in case something goes wrong 
> (however I can understand it's a nice feature to have and in might be useful 
> in some scenarios).

Your experiment predates extended nexthop encoding, but otherwise it
is indeed the very same thing. Just less operational overhead now.

Of course everyone has done 6PE and 6VPE longest time, because
obviously you can fit IPv4 next-hop in IPv6 coding, so nothing was
needed. This extended nexthop encoding only exists to fix the problem
that wire-format didn't support signalling IPv6 next-hop for IPv4
NLRI.

-- 
  ++ytti

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Alejandro Acosta]

Long time ago I tried it out:

https://blog.acostasite.com/2013/02/publicar-prefijos-ipv4-sobre-una-sesion.html

https://blog.acostasite.com/2013/02/publicando-prefijos-ipv6-sobre-sesiones.html


I did not like, difficult troubleshooting in case something goes wrong 
(however I can understand it's a nice feature to have and in might be 
useful in some scenarios).



But you are right I do not know much about networks doing it, I also 
would like hear about it.



Alejandro,


On 7/29/20 1:51 AM, Douglas Fischer wrote:
Let's just jump all the arguing about lack of IPv4, the need of IPv6, 
and etc...


I must confess that I don't know all the RFCs.
I would like it, but I don't!

And today, I reached on https://tools.ietf.org/html/rfc5549

I knew that was possible to transfer v4 routes over v6 BGP sessions, 
or v6 routes over v4 BGP sessions.
But I got surprised when I saw this youtube vídeo of AMS-IX guys 
considering use a v6 only Lan, and doing v6 next-hops to v4 routes.

https://www.youtube.com/watch?v=uJOtfiHDCMw

Well... I guess that idea didn't go to production.



But the questions are:
There is any network that really implements RFC5549?
Can anyone share some information about it?

--
Douglas Fernando Fischer
Engº de Controle e Automação

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Saku Ytti]

On Wed, 29 Jul 2020 at 12:58, Vincent Bernat  wrote:

> I didn't test, but the documentation states:

I think only disconnect here is definition of tunnel, there are no
additional headers and I don't think the document implies it and the
RFC it refers to does not. I've not tried it myself, but my
expectation is that internally the next-hop is represented as ipv6
with ipv4 resolution copied for L2 so I anticipate the magic to be
local here  and when they talk about tunnel, I suspect they refer to
that adjacency as tunnel.

-- 
  ++ytti

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Vincent Bernat]

 ❦ 29 juillet 2020 12:13 +03, Saku Ytti:

>> This is the solution Cumulus is advocating to its users, so I suppose
>> they have some real users behind that. Juniper also supports RFC 5549
>> but, from the documentation, the forwarding part is done using
>> lightweight tunnels.
>
> I'm not sure if you claim otherwise, but no real 'tunneling' takes
> place, as far as I know, it's internal implementation detail having
> IPV6 next-hop for IPV4. I don't think there is any additional headers
> or any additional lookup or cost.

I didn't test, but the documentation states:

> Starting in Release 17.3R1, Junos OS devices can forward IPv4 traffic
> over an IPv6-only network, which generally cannot forward IPv4
> traffic. As described in RFC 5549, IPv4 traffic is tunneled from CPE
> devices to IPv4-over-IPv6 gateways. These gateways are announced to
> CPE devices through anycast addresses. The gateway devices then create
> dynamic IPv4-over-IPv6 tunnels to remote customer premises equipment
> and advertise IPv4 aggregate routes to steer traffic. Route reflectors
> with programmable interfaces inject the tunnel information into the
> network. The route reflectors are connected through IBGP to gateway
> routers, which advertise the IPv4 addresses of host routes with IPv6
> addresses as the next hop.

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/multiprotocol-bgp.html#id-configuring-bgp-to-redistribute-ipv4-routes-with-ipv6-next-hop-addresses

If you have a pointer around the subject on Juniper, I would be quite
interested!

Thanks.
-- 
Write and test a big program in small pieces.
- The Elements of Programming Style (Kernighan & Plauger)

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Saku Ytti]

On Wed, 29 Jul 2020 at 10:03, Vincent Bernat  wrote:

> This is the solution Cumulus is advocating to its users, so I suppose
> they have some real users behind that. Juniper also supports RFC 5549
> but, from the documentation, the forwarding part is done using
> lightweight tunnels.

I'm not sure if you claim otherwise, but no real 'tunneling' takes
place, as far as I know, it's internal implementation detail having
IPV6 next-hop for IPV4. I don't think there is any additional headers
or any additional lookup or cost.
Cisco supports extended nexthop encoding too, so it is fairly well
supported by shipping products.


-- 
  ++ytti

Re: [v6ops] Question about "Operational Implications of IPv6 Packets with Extension Headers"

[Fernando Gont]

Hi, Fred,

On 29/7/20 05:15, Fred Baker wrote:

Fernando, I asked a specific question, not "send me all of your comments". 
General discussion of your draft still belongs on the v6...@ietf.org list. Please don't 
confuse the issue.


Apologies if I may have lead to confusion. I just meant to forward your 
request, and let folks know what the email alias for the chairs is 
(sometimes I get it wrong myself e.g. @ietf.org vs. @tools.ietf.org).


I just didn't say "send your support comments" because I didn't want to 
bias the request.


My apologies,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Re: [v6ops] Question about "Operational Implications of IPv6 Packets with Extension Headers"

[Fred Baker]

Fernando, I asked a specific question, not "send me all of your comments". 
General discussion of your draft still belongs on the v6...@ietf.org list. 
Please don't confuse the issue.

> On Jul 28, 2020, at 11:44 PM, Fernando Gont  wrote:
> 
> Folks,
> 
> FYI. You can send your comments to  if you wish.
> 
> Thanks,
> Fernando
> 
> 
> 
> 
>  Forwarded Message 
> Subject: [v6ops] Question about "Operational Implications of IPv6 Packets 
> with Extension Headers"
> Date: Tue, 28 Jul 2020 22:55:45 -0700
> From: Fred Baker 
> Reply-To: V6Ops-Chairs 
> To: IPv6 Operations 
> 
> It looks like Fernando (et al) revised this and posted draft -04 on Saturday, 
> and there has been a flurry of discussion. I haven't been through the 
> document or the entire thread yet, but I do observe that a number of people 
> have comments, and several people have expressed interest in the document.
> 
> Let me ask the obvious question: you we want to adopt this as a working group 
> draft? I won't ask you to hum; whether you wish to say "yes", "no", or 
> "abstain", please reply to this email *privately* (which is to say, to 
> v6ops-chairs) with that word prepended on the subject line. I'll give us 48 
> hours, which is to say that I will evaluate and state the result Thursday 
> evening Pacific time.
> 
> https://mailarchive.ietf.org/arch/search/?qdr=a=%22draft-gont-v6ops-ipv6-ehs-packet-drops%22
> https://mailarchive.ietf.org/arch/search/?qdr=a=%22Operational Implications 
> of IPv6 Packets with Extension Headers%22
> https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops
> https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops
>  "Operational Implications of IPv6 Packets with Extension Headers", Fernando 
> Gont, Nick Hilliard, Gert Doering, Warren Kumari, Geoff Huston, 2020-07-25,
> 
> ___
> v6ops mailing list
> v6...@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Vincent Bernat]

Hello,

This is implemented in FRR and will also be available in BIRD 2.0.8.
Linux accepts IPv6 next-hop for IPv4 natively since 5.3 (no tunnels).
This is the solution Cumulus is advocating to its users, so I suppose
they have some real users behind that. Juniper also supports RFC 5549
but, from the documentation, the forwarding part is done using
lightweight tunnels.

Maybe David Ahern is reading this list and could comment more. I don't
use this solution myself as the vendor support is still quite limited
but if I were to start a network from scratch, I would definitively go
for it.
-- 
Let the machine do the dirty work.
- The Elements of Programming Style (Kernighan & Plauger)

 ――― Original Message ―――
 From: Douglas Fischer 
 Sent: 29 juillet 2020 02:51 -03
 Subject: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?
 To: nanog@nanog.org

> Let's just jump all the arguing about lack of IPv4, the need of IPv6, and
> etc...
>
> I must confess that I don't know all the RFCs.
> I would like it, but I don't!
>
> And today, I reached on https://tools.ietf.org/html/rfc5549
>
> I knew that was possible to transfer v4 routes over v6 BGP sessions, or v6
> routes over v4 BGP sessions.
> But I got surprised when I saw this youtube vídeo of AMS-IX guys
> considering use a v6 only Lan, and doing v6 next-hops to v4 routes.
> https://www.youtube.com/watch?v=uJOtfiHDCMw
>
> Well... I guess that idea didn't go to production.
>
>
>
> But the questions are:
> There is any network that really implements RFC5549?
> Can anyone share some information about it?

Fwd: [v6ops] Question about "Operational Implications of IPv6 Packets with Extension Headers"

[Fernando Gont]

Folks,

FYI. You can send your comments to  if you wish.

Thanks,
Fernando




 Forwarded Message 
Subject: [v6ops] Question about "Operational Implications of IPv6 
Packets with Extension Headers"

Date: Tue, 28 Jul 2020 22:55:45 -0700
From: Fred Baker 
Reply-To: V6Ops-Chairs 
To: IPv6 Operations 

It looks like Fernando (et al) revised this and posted draft -04 on 
Saturday, and there has been a flurry of discussion. I haven't been 
through the document or the entire thread yet, but I do observe that a 
number of people have comments, and several people have expressed 
interest in the document.


Let me ask the obvious question: you we want to adopt this as a working 
group draft? I won't ask you to hum; whether you wish to say "yes", 
"no", or "abstain", please reply to this email *privately* (which is to 
say, to v6ops-chairs) with that word prepended on the subject line. I'll 
give us 48 hours, which is to say that I will evaluate and state the 
result Thursday evening Pacific time.


https://mailarchive.ietf.org/arch/search/?qdr=a=%22draft-gont-v6ops-ipv6-ehs-packet-drops%22
https://mailarchive.ietf.org/arch/search/?qdr=a=%22Operational 
Implications of IPv6 Packets with Extension Headers%22

https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops
  "Operational Implications of IPv6 Packets with Extension Headers", 
Fernando Gont, Nick Hilliard, Gert Doering, Warren Kumari, Geoff Huston, 
2020-07-25,


___
v6ops mailing list
v6...@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops