Opened 16 months ago

Closed 16 months ago

Last modified 8 months ago

#1093 closed request (wontfix)

Couple of queries about access point setup

Reported by: brian.e.carpenter@… Owned by: panda@…
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)

signature.asc (487 bytes) - added by mcr+ietf@… 16 months ago.
Added by email2trac

Download all attachments as: .zip

Change history (9)

comment:1 Changed 16 months ago by llynch@…

Component: incomingwireless
Owner: changed from < default > to Clemens Schrimpe
Status: newassigned

comment:2 Changed 16 months ago by panda@…

Owner: changed from Clemens Schrimpe to panda@…
Status: assignedaccepted

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

comment:3 in reply to:  3 ; Changed 16 months ago by brian.e.carpenter@…

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 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.
  1. 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 in reply to:  5 ; Changed 16 months ago by brian.e.carpenter@…

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 in reply to:  6 ; Changed 16 months ago by mcr+ietf@…

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 =-



signature.asc

Changed 16 months ago by mcr+ietf@…

Attachment: signature.asc added

Added by email2trac

comment:7 Changed 16 months ago by panda@…

Resolution: wontfix
Status: acceptedclosed

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

comment:8 Changed 8 months ago by Rick Alfvin

Milestone: ietf-98ietf-098

Milestone renamed

Note: See TracTickets for help on using tickets.