[FS#1430] MAP rule parsing incorrectly handles additional FMR rules

LEDE Bugs lede-bugs at lists.infradead.org
Wed Mar 14 11:01:24 PDT 2018


A new Flyspray task has been opened.  Details are below. 

User who did this - Det (detobate) 

Attached to Project - OpenWrt/LEDE Project
Summary - MAP rule parsing incorrectly handles additional FMR rules
Task Type - Bug Report
Category - Packages
Status - Unconfirmed
Assigned To - 
Operating System - All
Severity - Low
Priority - Very Low
Reported Version - Trunk
Due in Version - Undecided
Due Date - Undecided
Details - When [[https://github.com/openwrt/openwrt/blob/master/package/network/ipv6/map/files/map.sh#L117-L122|map.sh parses FMR rules]], it incorrectly assumes that all FMR rules should have remote.style MAP.

Only FMRs pointing towards other MAP CPEs should use remote.style MAP.   Other destinations (such as CDNs or other IPv6 servers), should use remote.style RFC6052
This distinction could be inferred when both remote.ea-len and remote.psid-offset are 0.   (Although this wouldn't be 100% accurate, as it's possible a deployment might do 1:1 v4:v6 mapping, use multiple MAP domains and have FMRs for each MAP domains)

Another method could be to check to see if the remote.v4 and remote.v6 pair has been seen previously as local.v4 and local.v6.  If it has, then it should use style MAP.   If the pair hasn't been seen, then it should use style RFC6052.   This would require the network admin to make sure all MAP domain BMRs are sent to all CPEs, regardless of which domain they're in.


As an additional side bug, mapcalc.c appears to generate a negative PSIDLEN when presented with an FMR that has EALEN 0.
This appears to only be aesthetic when generating /tmp/map-wan6_4.rules
I believe this could be resolved by adjusting: 
[[https://github.com/openwrt/openwrt/blob/master/package/network/ipv6/map/src/mapcalc.c#L312|if (psidlen 



More information about the lede-bugs mailing list