Announcing /48 to BGP peer

yon 0

DIG Output:
dig @2001:da8::666 yahoo.com SOA

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.3 <<>> @2001:da8::666 yahoo.com SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41270
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;yahoo.com. IN SOA

;; ANSWER SECTION:
yahoo.com. 1800 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2021022619 3600 300 1814400 600

;; Query time: 418 msec
;; SERVER: 2001:da8::666#53(2001:da8::666)
;; WHEN: Sat Feb 27 01:00:26 CET 2021
;; MSG SIZE rcvd: 102

---- Finished ------

Derelict

@yon-0 Yet here you are with problems.

Untitled 2.png

Instead of arguing with me about it, please argue with Douglas Comer instead.

Derelict

@yon-0 You are confusing routes and allocations with interface addressing. Please read up on the difference. Happy to help you but in this case you are wrong (and continue to belabor an incorrect position) and your IPv6 journey will be much more successful if you adhere to the established rules, standards, and protocols instead of making up your own.

yon 0

@derelict

I tested it with a previous version of pfsense before, and /48 works. DHCP can work with /48 test in windows 10. /48 SLAAC maybe can't work for andriod system. This is the result of the previous test. But if you set static ip, there is no problem. for all system.
I have always used /48 on the LAN interface and BGP broadcasts, and it has been working. This time you adjusted the limit, so I found this change. I suggest that the decision is given to users to decide how large the IP segment to use.
You can prompt the recommended value and other information, but don't force the user to use what

yon 0

@derelict

I used to set /48 on the LAN interface to work, but it pf2.5 doesn’t work anymore now. This is the actual change

johnpoz

@yon-0 said in IPv6 broken beyond pfSense after 2.5 upgrade:

it is using /28 ipv6 for interface and bgp

Just because AS45275 is a /28, where did you get that idea that address is 240C::6666 is using a /28 on some interface?? Sorry but that is just insane!

I used to set /48 on the LAN interface to work, but it pf2.5 doesn’t work anymore now. This is the actual change

Yeah because they prob put in logic to stop users from doing insane shit ;)

I suggest that the decision is given to users to decide how large the IP segment to use.

Not when they are going to BREAK all logic and think they could put a /48 on an interface..

yon 0

@johnpoz

These IP addresses run DNS servers, so the 240C::6666 IP must be set in the interface. if that ip has no setup in interface, how we can connect it? if your not allow /48 or other setup interface , how i do setup use /32 or /48 Shortest ip in LAN's servers?

No, I don’t think so, I think you force others what you think is impossible.

DIG Output:
dig  @2620:0:ccc::2 yahoo.com SOA 


; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.3 <<>> @2620:0:ccc::2 yahoo.com SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38691
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;yahoo.com.			IN	SOA

;; ANSWER SECTION:
yahoo.com.		127	IN	SOA	ns1.yahoo.com. hostmaster.yahoo-inc.com. 2021022619 3600 300 1814400 600

;; Query time: 7 msec
;; SERVER: 2620:0:ccc::2#53(2620:0:ccc::2)
;; WHEN: Sat Feb 27 01:24:57 CET 2021
;; MSG SIZE  rcvd: 99


 ---- Finished ------

Derelict

@yon-0 said in IPv6 broken beyond pfSense after 2.5 upgrade:

2620:0:ccc::2

That is 2620:0:ccc:0::2/64. Guaranteed. You do realize that zero compression can include bits from both the subnet and interface portion of the address, right?

yon 0

@derelict

Does this 240C::6666 ip use /64 or what?
My point of view is to leave it to users to decide what is right, and we can provide suggested values.

Derelict

@yon-0 The standards and RFCs dictate what's right.

Derelict

@yon-0 said in IPv6 broken beyond pfSense after 2.5 upgrade:

@derelict

Does this 240C::6666 ip use /64 or what?

Yes, if it is on an interface it is 240c:0:0:0::6666/64

You certainly cannot tell from afar based on the allocation or the route. I GUARANTEE they do not have a 240c::/16 on an interface though.

lnguyen

@yon-0 You are just flat out wrong. The largest subnet to be used on an interface is /64. To suggest anything else just means you do not understand or have not read the RFCs for IPv6.

yon 0

https://www.ripe.net/publications/docs/ripe-690

johnpoz

Yeah so.. What does that have to do with anything?

The part where they say you should allocate a /48 to users? Completely agree - that has ZERO to do with putting a /48 on an interface.

I have a /48 from HE for example.. Putting a /48 on interface would make all 65k of those 64's useless!

yon 0

FRR v7.5.1 change to must setup /48 or above in Lan interface now, if the pfsense has no any interface setup /48 prefix, then ipv6
lost normal work. i have been test frr7.5.1 in ubuntu 20..10 system get the same result.

johnpoz

@yon-0 said in IPv6 broken beyond pfSense after 2.5 upgrade:

FRR v7.5.1 change to must setup /48 or above in Lan interface now

Dude NO is doesn't... I am sorry you are not understanding how this works... But you DO NOT PUT a /48 on an interface - PERIOD!!

yon 0

@johnpoz

Maybe I don't understand the theory, I just summarize the practical experience, if I run FRR7.5.1 then this happens. I just reflect the situation encountered.

johnpoz

Your not understanding how to setup a route without putting in on the interface??

This goes same for IPv4... If have a /30 that connects 2 routers, are you saying I can not route a /8 through those? Or a /16 etc.. Because the network needs to be on the interface? How would routing ever work..

Derelict

@yon-0 The whole point of BGP is to announce routes that are reachable. If the route is not reachable, it will not be announced.

That does not mean that the only method of making a route reachable is to number an interface with it.

This is what you get when you simply add a network statement for a /48 without the route being reachable:

# show bgp ipv6
BGP table version is 5, local router ID is 172.25.232.1, vrf id 0
Default local pref 100, local AS 65001
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> ::/0             fe80::bc7f:82ff:feea:ecf8
                                             0         32768 ?
   2001:470:beef::/48
                    ::                       0         32768 i

Displayed  2 routes and 2 total paths

Note there is no * indicating a valid route. That means it will not be announced by BGP.

Now,

Now it is both active * and best > and announced to the peer

Codes: K - kernel route, C - connected, S - static, R - RIPng,
       O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
       v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
       f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

K>* ::/0 [0/0] via fe80::bc7f:82ff:feea:ecf8, lo0, 00:01:15
S>* 2001:470:beef::/48 [1/0] unreachable (blackhole), weight 1, 00:01:15

vtysh# show bgp ipv6 neighbors 172.25.228.58 advertised-routes 
BGP table version is 3, local router ID is 172.25.232.1, vrf id 0
Default local pref 100, local AS 65001
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> ::/0             ::                       0         32768 ?
*> 2001:470:beef::/48
                    ::                       0         32768 ?

I sent that traffic to Null/Blackhole but if there are any longer prefixes (like /64 interface routes) they will be the preferred route for that traffic. It also has a status of unreachable because it is a null route but BGP is coerced into announcing it.

yon 0

@derelict

I had used /48 in pf 2.4.5 and pf 2.5beta was
normal work.