Looking for 32-bit AS numbers, I get some strange results from routeviews:
route-views>sh ip bgp regexp _23456_
BGP table version is 2393809200, local router ID is 128.223.51.103
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 31.177.16.0/22 128.223.253.10 0 3582 3701 3356 23456 3.1043 i
* 46.29.72.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i
* 46.243.96.0/21 154.11.11.113 0 0 852 174 39704 39704 23456 3.787 i
* 91.208.62.0/24 154.11.11.113 0 0 852 174 39704 39704 23456 3.787 i
* 91.217.87.0/24 194.85.40.15 0 3267 174 23456 3.661 i
* 91.230.169.0/24 208.51.134.254 13905 0 3549 29152 29152 29152 29152 23456 23456 23456 23456 3.1426 i
* 91.238.8.0/24 194.85.40.15 0 3267 8220 23456 3.2040 i
* 111.235.148.0/22 194.85.40.15 0 3267 9498 9730 23456 i
* 141.0.176.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i
Unless I missed something, AS 23456 is supposed to show up as a stand-in for 32-bit ASNs on 16-bit BGP implementations, not in _addition_ to 32-bit ASNs. So the penultimate line would make sense if the other lines weren't there and the others don't make sense period.
Maybe a bug in the IOS they're running?
route-views>sh ver
Cisco IOS Software, 7200 Software (C7200P-ADVENTERPRISEK9-M), Version 12.4(24)T2, RELEASE SOFTWARE (fc2)
Or is something else going on?
This can happen when a old 2-byte only routers are doing prepends with the
neighbor address (4-byte). Then the magic in the 4-byte AS RFC to fix up
ASPATH has no chance to work and you will see 23456.
After a careful re-read of RFC4893 section 4.2.3 Processing Received
Updates, I am fairly sure it is either an implementation issue with the
involved 4-octet ASN routers, or else their transit providers are using
as-path-*expand* when learning their routes for some reason (customers ask
for the strangest things.)
The specification for 4-octet AS refers to "old" and "new" BGP speakers,
which I'll do here:
When NEW speaker receives a route from an OLD speaker, its job is to make
AS_PATH and AS4_PATH the same length by using ASNs from from AS_PATH, which
cannot have been inserted into AS4_PATH by the OLD speaker(s) that do not
support the Attribute.
If a NEW speaker implements as-path-prepend incorrectly, and puts 23456
(AS_TRANS) into AS4_PATH instead of his real ASN, then the route passes
through some OLD speakers and out to a NEW one again, the second NEW
speaker has no opportunity to reconstruct the correct path.
On the other hand, if an OLD speaker is configured for as-path-*expand* as
it learns routes from a NEW speaker, then it may insert AS_TRANS into the
AS_PATH but no entries are being pushed to AS4_PATH. This is a limitation
of the specification and cannot be avoided. In effect, the use of as-path-*
expand* at a NEW->OLD boundary where the NEW router has a 4-octet ASN and
OLD router is performing *expand* means the correct AS_PATH cannot be
rebuilt.
I think you've just found a number of AS's that are at high risk of
being mystified when D-root shuts down 7 months from now. 
Off topic, this reminds me I would rather have ASPLAIN
again. We switched a couple of years ago on a particular
user request.
If there is no objection, I would love to switch back
ASAP. This would be on route-views, and on route-views3.
Just asking if others concur?
rfc5396. I'd say go for it.
Nick
Off topic, this reminds me I would rather have ASPLAIN
again. We switched a couple of years ago on a particular
user request.
listening to those pesky users, eh?
If there is no objection, I would love to switch back
ASAP. This would be on route-views, and on route-views3.
Just asking if others concur?
makes sense to me
randy