nat64: Handle "Well-Known Prefix" 64:ff9b::/96 #1141
Conversation
|
Seems legit to me, are there any comments about this? I would suggest squashing into a single commit and merge. |
| } | ||
|
|
||
| /* 198.51.100.0/24 */ | ||
| uip_ipaddr(&ipaddr, 198, 51, 100, 0); |
There was a problem hiding this comment.
I would add the uip_ipaddr(&mask, 255, 255, 255, 0); line here and in the following check as well.
Otherwise these will quickly fail if someone misses to see the link and adds a check in between somewhere.
There was a problem hiding this comment.
I think that some code doesn't need to be added here. I think that some comments will be enough. They should say that those checks depend on the mask value from the previous check.
|
This code will break existing NAT64 example as the prefix used is ::ffff:0, the examples should also be updated, or make the NAT64 prefix configurable (This is what we did in 6LBR) Also, forbiding private network is not a good idea, in several deployment NAT64 is used to allow communication between the WSN and the LAN which is using private addresses. |
|
@laurentderu thanks! I forgot about the NAT64 example. |
|
@uknoblic any update about this PR? |
I added the well-known-prefix to the list of allowed prefixes in ip64-addr.c. Private IPv4 addresses are dropped as specified in RFC 6052.