It has been noticed by some people that some Windows 2000, (and Windows XP, and Windows Server 2003) etc machines send a multicast packet to group address I have some information on this subject... I hope it will be of use.

In summary I do not believe that these packets create any security risk.

Alan J. McFarlane


It is a UDP packet destined to IP Group Address and port 9753. The data content of the UDP packet is "Hostname=" followed by the PC's hostname (and then a LF and a NUL). The multicast address is registered at IANA's Multicast Addresses list as "rasadv" i.e.

... Site-Local Scope           [Meyer,RFC2365]  rasadv                                    [Thaler]
Note also that the address is within the "IPv4 Local Scope" range [RFC2365], that is the range to (i.e. Traffic destined to destinations should be kept within a 'local' area, and certainly within a physical site.

Port 9753 is defined in the Port Numbers list also as "rasadv" i.e.

rasadv		9753/tcp    rasadv
rasadv		9753/udp    rasadv
#			    Dave Thaler <>

A packet as captured by Netmon (on my PC's LAN interface) is shown here:

Frame   Time   Src MAC Addr   Dst MAC Addr   Protocol   Description   Src Other Addr   Dst Other Addr   Type Other Addr

3   1136.811782  LOCAL   USC IN7F0202   UDP   IP Multicast: Src Port: Unknown, (1034); Dst Port JYRAALAN2K    
+ Frame: Base frame properties
  ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol
    + ETHERNET: Destination address : 01005E7F0202
    + ETHERNET: Source address : 100000112233
      ETHERNET: Frame Length : 63 (0x003F)
      ETHERNET: Ethernet Type : 0x0800 (IP:  DOD Internet Protocol)
      ETHERNET: Ethernet Data: Number of data bytes remaining = 49 (0x0031)
  IP: ID = 0x1F4D; Proto = UDP; Len: 49
      IP: Version = 4 (0x4)
      IP: Header Length = 20 (0x14)
      IP: Precedence = Routine
      IP: Type of Service = Normal Service
      IP: Total Length = 49 (0x31)
      IP: Identification = 8013 (0x1F4D)
    + IP: Flags Summary = 0 (0x0)
      IP: Fragment Offset = 0 (0x0) bytes
      IP: Time to Live = 15 (0xF)
      IP: Protocol = UDP - User Datagram
      IP: Checksum = 0x6A9E
      IP: Source Address =
      IP: Destination Address =
      IP: Data: Number of data bytes remaining = 29 (0x001D)
+ UDP: IP Multicast: Src Port: Unknown, (1034); Dst Port: Unknown (9753); Length = 29 (0x1D)

00000:  01 00 5E 7F 02 02 10 00 00 11 22 33 08 00 45 00   ..^...........E.
00010:  00 31 1F 4D 00 00 0F 11 6A 9E C0 69 5A 66 EF FF   .1.M............
00020:  02 02 04 0A 26 19 00 1D BE 38 48 6F 73 74 6E 61   ....&...¾8Hostna
00030:  6D 65 3D 74 68 65 70 63 73 6E 61 6D 65 0A 00      me=thepcsname.. 

(Personal information in the trace has been changed i.e. source MAC and IP address and hostname).


Monitoring shows that a packet is send once per hour.


It is presumed that the packets are sent to advertise that the local machine is running RAS/RRAS (that is "[Routing and] Remote Access Server" for any non-Microsoft aware readers). No documentation of this has been found however.

This behaviour is useful in a corporate network where it will allow administrators to detect any Windows machines that are running RAS. Unauthorised RAS devices create a very dangerous security risk, no use in having that super-duper firewall if people can dial-in to your network through some unprotected RAS device.

It appears that the netsh tool within Windows can be used to show the advertising RAS servers. It has a command show activeservers within the ras context that will display any advertisements received. It listens on the multicast address and will thus receive any of these advertisements sent on the 'Local Scope' network. For instance:

ras>show activeservers

Timestamp                 Sender
------------------------  ----------------------------------
Tue Dec 10 18:36:49 2002 (

There is a tool in the Resource Kit called raslist.exe that serves a similar purpose. When run, it produces initially:

C:\>"\Program Files\Resource Pro Kit\raslist.exe"
RASLIST - list of RAS servers on the net
press <ESC> to exit
Ready to receive RAS announces on LANA0

The LANA0 identifier suggests to me NetBIOS use, which is odd. Anyway on my machine when I use it I do not see the IGMP Report appear on my active LAN card, this is likely due to the machine having multiple NIC and dial-up connections defined (if not active). It is probably best to use the netsh version.

Note: As for all Multicast receive usage, if you are running a packet sniffer or a personal firewall that logs such outgoing traffic, when you run either of the commands you will (should) see an IGMP Membership report packet for the group (i.e. being sent. This is the Internet Group Management Protocol being used to tell the network that this machines wants to receive traffic on the multicast group. If your network is multicast enabled then your machine will start to receive the advertisement from the machines running RAS on your network. You also will continue being sent regular IGMP Membership Query packets from the elected Multicast router on your network, your machine will send the same Report in reply to each. If your network is not multicast enabled then you will only receive advertisement from machines on the same LAN segment.

How (does it affect me)

If you are connected directly to the Internet, whether through dial-up, CableModem, xDSL, you may be worried that the sending of this packet poses some security risk to you.

Firstly I do not hold to the idea that a device is safer if arbitrary machines on the Internet cannot detect its presence. If an attacker is going to run an attack, he just runs the attack on the given service on a large arbitrary set of addresses. He does not bother to attempt to find which machines are active by Pinging etc. Nor is it worth trying to find out by secondary means whether a particular service is active, just attack the service and see if it responds or fails...

Scope of delivery

As this packet is being sent to a group address it requires that a Multicast enabled network exists to forward it. A router that does not have special multicast configuration applied will not forward such packets. I personally know of no ISPs that have multicast enabled their network. If any have it is likely that they are set up to deliver multicast to the clients but not allow them to send multicasts. You would have to be specifically authorised to send multicast packets through its network. Usually the first router (remote access device, CMTS, DSLAM etc) will not forward multicasts and will just drop them. As noted in the What section the group address used by these packets should restrict the delivery of them to within the local site. The only receiver of these packets could thus be the ISP itself and only then if they have carried out special configuration on the first hop router.

Information exposed

Now lets look at what information the packets might expose. There are four pieces of information possibly exposed

The first three pieces of information will be provided already to your ISP at connect time; for dial-up though PPP negotiation and on Cable Modem etc through DHCP. So it does not provide any new information.

The information that RAS is running is the only piece of new information being exposed to your ISP. The fact that you are running RAS is not terribly useful anyway, to try an attack dial-in they will have to know the phone number of the attached modem.

I thus feel that the risk created by these packets is low to non-existent.

Later notes

It has also been pointed out to me that RRAS could be being used to accept VPN connections from the Internet. This creates a different risk from when only modems are being used: there is no need to know the phone number that the modem is attached to...

For a long while I was not seeing any of these packets from RRAS even though RRAS was running. At the time I had no modem devices configured, but was just using the IrNet ("Infrared Port") connection type. So, does RRAS only send the rasadv packets when a modem is configured, or was I just not seeing them because I wasn't looking hard enough..., or was something else at play...? Anyway they have returned now.

Later. Of course, after all that waffling about them disappearing and reappearing, they have now disappeared again.

This feature also exists in Windows XP, and I've had a report that this feature exists in Windows Server 2003 (thanks).

Any information on this or any other relevant information including any errors in this document would be appreciated in order to improve this document. Please send emails to alanjmcf AT
Copyright © 2002,2004 Alan J. McFarlane. All rights reserved.
Document for information only, no warranties blah de blah, all trademarks etc.