Open Bug 79242 Opened 20 years ago Updated 4 years ago

IPv6: PAC: isInNet function needs to support new addressing

Categories

(Core :: Networking, defect, P5)

defect

Tracking

()

Future

People

(Reporter: benc, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted, Whiteboard: [necko-would-take][proxy])

From bug 58030

------- Additional Comments From timeless@mac.com 2001-01-15 07:55 -------
+"function isInNet(ipaddr, pattern, maskstr) {\n"+
this _definitely_ doesn't look ipv6 friendly. :-(

Possible issues:

1- decision on whether we need a new function call or can make use of the
exsiting paratmeters)
2- support for the actual IPv6 addressing data types.
qa to me. 
QA Contact: tever → benc
Target Milestone: --- → mozilla0.9.3
-->PAC bugs to Jussi
Assignee: neeti → jpm
QA Contact: benc → pacqa
Serge, can you take a look at these PAC issues? Thanks - Jussi-Pekka
Assignee: jpm → serge
Doesn't look like this is getting fixed before the freeze tonight.
Pushing out a milestone.  Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
this is an enhancement, removing TM.
Target Milestone: mozilla0.9.4 → ---
Blocks: 79893
Blocks: IPv6
moving to future, enhancement requests will be reviewed at a later date
Status: NEW → ASSIGNED
Priority: -- → P5
Summary: IPv6 + PAC: isInNet function needs to support new addressing → [RFE]IPv6 + PAC: isInNet function needs to support new addressing
Target Milestone: --- → Future
Severity: enhancement → normal
I respectfully request that the status of this bug be reconsidered.  I believe
that it is a full-fledged bug, not a request for enhancement.

I am currently running Mozilla 1.1a on Tru64 UNIX V5.1B.  Mozilla is intended to
be my primary browser on my workstation.  However, this bug is preventing my
proxy configuration from working, forcing me to constantly diddle with the proxy
configuration myself or fall back to Netscape Navigator 4.7x.

It took me a long time to identify the issue, but eventually I was able to
determine that dnsResolve(hostname) was returning an IP address in the format
"::ffff:15.1.2.3".  This breaks isInNet, since convert_addr is splitting on ".",
and the first part thus becomes "::ffff:15", not a valid integer.  As a result,
isInNet() incorrectly returns false.

Note that this is not an issue on Netscape Navigator 4.7x.  Thus, this behavior
is a regression from previous behavior.  It is currently inhibiting my ability
to use Mozilla.

I would respectfully request that if the owner of this bug disagrees with my
assessment, that he say so, so that at least I know that my comments have been
addressed.  I will wait for the owners response, instead of changing the status
of the bug myself (which would probably be annoying for the owner).

Thank you.
4xp.
putting into the triage queue w/ helpwanted.
Assignee: serge → new-network-bugs
Status: ASSIGNED → NEW
Keywords: 4xp, helpwanted
QA Contact: pacqa → benc
Target Milestone: Future → ---
future
Target Milestone: --- → Future
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: normal → enhancement
Summary: [RFE]IPv6 + PAC: isInNet function needs to support new addressing → IPv6 + PAC: isInNet function needs to support new addressing
I'm sorry, but I'm still wondering why this is a RFE/enhancement bug.  I believe
it to be a bug in isInNet that is forcing me to revert to NN4 in some cases.
okay.
Severity: enhancement → normal
There is no explict support for IPv6 in the original specs. This is  "4xp", so
the fact that Comm somewhat does this correctly (and that this is to some degree
a product-level regresssion) is marked w/ that keyword.
Blocks: 223403
Summary: IPv6 + PAC: isInNet function needs to support new addressing → IPv6 + PAC2: isInNet function needs to support new addressing
bobbell: 

I think Darin fixed the function so that it would stop breaking isInNet (it now
only returns IPv4 addresses).

Please let me know if this is fixed, if so, mark this RESOLVED/FIXED.
No longer blocks: 223403
Depends on: 191715
Summary: IPv6 + PAC2: isInNet function needs to support new addressing → IPv6: PAC: isInNet function needs to support new addressing
I personally haven't seen this recently.  I think my configuration changed, but
I'd say to go ahead and mark this FIXED.  I can't do so because I'm not the
submitter.
This is still not really fixed.  isInNet should fully support IPv6 addresses or some new function should be added which does.  IMHO, the use of 'mask' is pretty IPv6 unfriendly.  Prefixes (i.e. addr/bits ala 192.168.43.0/24) is better suited for both IPv4 and IPv6.
Whiteboard: [necko-would-take]
Whiteboard: [necko-would-take] → [necko-would-take][proxy]
You need to log in before you can comment on or make changes to this bug.