#1093 closed request (wontfix)
Couple of queries about access point setup
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | tbd | Milestone: | ietf-098 |
| Component: | wireless | Keywords: | |
| Cc: | My Current Location: | ||
| My MAC Address: | My OS: |
Description
After hackathon and post-hackathon activities we have a couple of questions about the setup of the IETF wireless access points. 1) Summarising what Michael asked on the weekend on the hackathon list: Do the access points implement the equivalent of BCP38 egress filtering for IPv6? When we tried to set up manual IPv6 Unique Local Address usage on a couple of hosts, the packets were sent (said Wireshark) but never received. That's not expected behavior from a pure Layer 2 switch. (We had a work-around, i.e. wired Ethernet and a dumb switch.) 2) From some tests yesterday: Do the access points throttle the rate of IPv6 link-local multicasts? We saw quite long periods (up to 4 minutes) when valid link local multicasts to ff02::114 vanished in the air. But when I cheated by sending them ten times more frequently, enough of them arrived to make things work. That strongly suggests throttling. (The good news is that MLD snooping definitely worked.) Regards Brian Carpenter
Attachments (1)
Change history (9)
comment:1 Changed 16 months ago by
| Component: | incoming → wireless |
|---|---|
| Owner: | changed from < default > to Clemens Schrimpe |
| Status: | new → assigned |
comment:2 Changed 16 months ago by
| Owner: | changed from Clemens Schrimpe to panda@… |
|---|---|
| Status: | assigned → accepted |
comment:3 follow-up: 3 Changed 16 months ago by
Hi Hirochika, thanks for the answer. We had no problem with link-local addresses. The problem was with manually assigned ULA addresses. To be very specific fd63:45eb:dc14::1 on one machine (Linux) fd63:45eb:dc15::3 on another machine (Windows) with host routes like fd63:45eb:dc14::/48 2001:67c:370:128:31f2:b395:31b5:6562 but could not ping fd63:45eb:dc14::1 from fd63:45eb:dc15::3 For the multicast question, thanks for the information. Regards Brian Carpenter On 30/03/2017 04:06, IETF Tickets/NOC wrote: > #1093: Couple of queries about access point setup > --------------------------------------+-------------------------------- > Reporter: brian.e.carpenter@… | Owner: panda@… > Type: request | Status: accepted > Priority: tbd | Milestone: ietf-98 > Component: wireless | Resolution: > Keywords: | My Current Location: > My MAC Address: | My OS: > --------------------------------------+-------------------------------- > Changes (by panda@…): > > * owner: Clemens Schrimpe => panda@… > * status: assigned => accepted > > > Comment: > > Hi Brian, > > > Do the access points implement the equivalent of BCP38 egress filtering > for IPv6? > They don't for IPv6. We configure DHCP-snooping-based BCP38-like > filtering for IPv4 on ietf* SSIDs but not for IPv6. I tried to reproduce > your case but I could not. Can you tell me what unique link local > addresses you have tried? > > What I tried to reproduce the case is the following and get the > reachability to our gateway with the manually assigned link local address: > $ sudo ifconfig en0 inet6 fe80::dead:1234:5678/64 > $ ifconfig en0 inet6 > en0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu > 1500 > inet6 fe80::dead:1234:5678%en0 prefixlen 64 scopeid 0x4 > nd6 options=201<PERFORMNUD,DAD> > $ ping6 -c 3 fe80::128:1%en0 > PING6(56=40+8+8 bytes) fe80::dead:1234:5678%en0 --> fe80::128:1%en0 > 16 bytes from fe80::128:1%en0, icmp_seq=0 hlim=64 time=1.412 ms > 16 bytes from fe80::128:1%en0, icmp_seq=1 hlim=64 time=1.773 ms > 16 bytes from fe80::128:1%en0, icmp_seq=2 hlim=64 time=1.513 ms > > --- fe80::128:1%en0 ping6 statistics --- > 3 packets transmitted, 3 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 1.412/1.566/1.773/0.152 ms > > One possible cause of your issue is ARP/NS proxy feature on our wireless > LAN controllers. Did you perform DAD? > > > > Do the access points throttle the rate of IPv6 link-local multicasts? > Yes, we do MLD snooping on our wireless LAN controllers to prevent > multicast storms over the air. The MLD timeout and MLD query interval are > set to 60 seconds and 20 seconds, respectively. > > Thank you. > Hirochika Asai > > -- > Ticket URL: <https://tickets.meeting.ietf.org/ticket/1093#comment:2> > IETF Tickets/NOC <https://tickets.meeting.ietf.org> > IETF Meeting Tickets - NOC pages >
comment:4 Changed 16 months ago by
Hi Brian,
Thank you for telling me your configuration to reproduce this issue. I could reproduce it by building the similar environment to yours.
Let me correct my previous answer for BCP38-like filtering to be more precise. The current configuration of our wireless LAN does following two things:
- Our wireless LAN configuration does not allow clients to use manually configured *IPv4* addresses. Wireless LAN controllers snoop DHCP to do this.
- Our wireless LAN configuration filters both *IPv4* and *IPv6* packets with the source addresses that cannot be resolved via ARP/NS. Wireless LAN controllers perform proxy ARP/ND to achieve this filtering.
My apologies. I only mentioned the first one in my previous comment. However, the second configuration is applied to both IPv4 and IPv6. I missed the second one. Any IPv6 addresses can be used as source address on our wireless unless the IPv6 addresses can be resolved via NS. Since source addresses of routed packets are not in the neighbor table on wireless LAN controllers, they will be dropped.
Please let us know if you have the request to remove these BCP38-like filtering. We will discuss our operational policy among NOC members.
Thank you.
Hirochika Asai
comment:5 follow-up: 5 Changed 16 months ago by
Thanks, that is a complete explanation of what we saw in the hackathon. No, I don't think you should change the policy. What we were doing was indeed hacking and any such traffic on the main network would be suspect. It might be worth warning hackathon participants, so I have cc'ed Charles. TL;DR version: if you use invented source addresses on the IETF network, your packets will probably be dropped, even if the destination is local. Regards Brian Carpenter On 30/03/2017 09:02, IETF Tickets/NOC wrote: > #1093: Couple of queries about access point setup > --------------------------------------+-------------------------------- > Reporter: brian.e.carpenter@… | Owner: panda@… > Type: request | Status: accepted > Priority: tbd | Milestone: ietf-98 > Component: wireless | Resolution: > Keywords: | My Current Location: > My MAC Address: | My OS: > --------------------------------------+-------------------------------- > > Comment (by panda@…): > > Hi Brian, > > Thank you for telling me your configuration to reproduce this issue. I > could reproduce it by building the similar environment to yours. > > Let me correct my previous answer for BCP38-like filtering to be more > precise. The current configuration of our wireless LAN does following two > things: > > 1. Our wireless LAN configuration does not allow clients to use manually > configured *IPv4* addresses. Wireless LAN controllers snoop DHCP to do > this. > > 2. Our wireless LAN configuration filters both *IPv4* and *IPv6* packets > with the source addresses that cannot be resolved via ARP/NS. Wireless > LAN controllers perform proxy ARP/ND to achieve this filtering. > > My apologies. I only mentioned the first one in my previous comment. > However, the second configuration is applied to both IPv4 and IPv6. I > missed the second one. Any IPv6 addresses can be used as source address > on our wireless unless the IPv6 addresses can be resolved via NS. Since > source addresses of routed packets are not in the neighbor table on > wireless LAN controllers, they will be dropped. > > Please let us know if you have the request to remove these BCP38-like > filtering. We will discuss our operational policy among NOC members. > > Thank you. > Hirochika Asai > > -- > Ticket URL: <https://tickets.meeting.ietf.org/ticket/1093#comment:4> > IETF Tickets/NOC <https://tickets.meeting.ietf.org> > IETF Meeting Tickets - NOC pages >
comment:6 follow-up: 6 Changed 16 months ago by
Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> No, I don't think you should change the policy. What we were doing was
> indeed hacking and any such traffic on the main network would be
> suspect.
And we configured our ULA as /128 aliases on loopback with explicit LL routes
to get to adjacent nodes, rather than as /64 aliases on our wireless interfaces.
>> 2. Our wireless LAN configuration filters both *IPv4* and *IPv6* packets
>> with the source addresses that cannot be resolved via ARP/NS. Wireless
>> LAN controllers perform proxy ARP/ND to achieve this filtering.
So, next time we'll have to have a proper ACP and/or plan to have a private
wired lan.
--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
comment:7 Changed 16 months ago by
| Resolution: | → wontfix |
|---|---|
| Status: | accepted → closed |
Hi Brian,
Thank you. We will discuss the best way to announce these filters, especially to the participants in hackathon. I hereby close this ticket.
Best,
Hirochika Asai
Note: See TracTickets for help on using tickets.
Hi Brian,
They don't for IPv6. We configure DHCP-snooping-based BCP38-like filtering for IPv4 on ietf* SSIDs but not for IPv6. I tried to reproduce your case but I could not. Can you tell me what unique link local addresses you have tried?
What I tried to reproduce the case is the following and get the reachability to our gateway with the manually assigned link local address:
$ sudo ifconfig en0 inet6 fe80::dead:1234:5678/64
$ ifconfig en0 inet6
en0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
$ ping6 -c 3 fe80::128:1%en0
PING6(56=40+8+8 bytes) fe80::dead:1234:5678%en0 --> fe80::128:1%en0
16 bytes from fe80::128:1%en0, icmp_seq=0 hlim=64 time=1.412 ms
16 bytes from fe80::128:1%en0, icmp_seq=1 hlim=64 time=1.773 ms
16 bytes from fe80::128:1%en0, icmp_seq=2 hlim=64 time=1.513 ms
--- fe80::128:1%en0 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 1.412/1.566/1.773/0.152 ms
One possible cause of your issue is ARP/NS proxy feature on our wireless LAN controllers. Did you perform DAD?
Yes, we do MLD snooping on our wireless LAN controllers to prevent multicast storms over the air. The MLD timeout and MLD query interval are set to 60 seconds and 20 seconds, respectively.
Thank you.
Hirochika Asai