RE: Review comments on IPv6 for Second and Third Generation Cellu lar Hosts
Does this (paraphrased) assessment seem correct? I wouldn't want 3GPP to mandate a behaviour that they would believe contributed to identity privacy but, based on some other procedure, did not. = But the person tracking would have to know that the host is a 3GPP host. Isn't this fairly trivial todo? I.e., the cellphone will likely have an IPv6 address assigned out of a address block that is widely-known to belong to a carrier providing 3G IPv6 service. Right? Depends if that carrier only provides 3G IPv6 service. It may provide fixed and 3G service out of the same block, where the assignment is done differently in the fixed and wireless parts. Also, it may provide IPv6 service to corporate users which use prefixes belonging to their fixed corporate network. It's true that it doesn't provide privacy in all cases, but it's not necessarily a trivial thing to find out if a host is a 3GPP host. /Karim IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: draft-ietf-ipngwg-rfc2553bis-05: getnameinfo() arguments
While making a related change in NetBSD I noticed that although getnameinfo() was correctly aligned with POSIX with respect to size_t vs. socklen_t, it was apparently missed to change its `flags' argument from int to unsigned int as part of that edit. Yes, I noticed this discrepancy between posix and rfc2553 about a year ago, and have been actively trying to fix the posix spec in this regard. The 'unsigned' flags argument occurred at some point during the incorporation of the IPv6 API into the Open Group's Networking Services issue 5.2 spec in 1999, and was propagated from there into the posix 1003.1-2001 spec. We've been looking back at archives to see how this change was introduced, but have not completed the e-paper trail yet. From what I can tell, most implementations have implemented type 'int' as per the RFC, including Solaris, Windows XP, AIX, Tru64 UNIX, HP-UX, FreeBSD, OpenBSD, NetBSD, and OpenVMS. The only implementation I have seen that uses 'unsigned int' is GNU libc, which originally implemented using type 'int', but which changed to 'unsigned int' in January 2001 (I speculate this was done to align with XNS 5.2 or perhaps one of the early drafts of 1003.1-2001). Given the widespread implementation of 'int', I believe the right thing to do is get the posix spec changed, and leave rfc2553bis as is. Stay tuned, Technical Corrigenda 1 (TC1) for 1003.1-2001 is active right now, I hope to have this fixed in TC1. - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: draft-ietf-ipngwg-rfc2553bis-05: getnameinfo() arguments
Jack McCann [EMAIL PROTECTED] writes: The 'unsigned' flags argument occurred at some point during the incorporation of the IPv6 API into the Open Group's Networking Services issue 5.2 spec in 1999, and was propagated from there into the posix 1003.1-2001 spec. We've been looking back at archives to see how this change was introduced, but have not completed the e-paper trail yet. FWIW, I went through my collection of C808 drafts and found the `unsigned' argument appeared with the introduction of getnameinfo() in D3.0. Unfortunately no e-paper trail over here either; I've never been an XNET participant. From what I can tell, most implementations have implemented type 'int' as per the RFC, including Solaris, Windows XP, AIX, Tru64 UNIX, HP-UX, FreeBSD, OpenBSD, NetBSD, and OpenVMS. The only implementation I have seen that uses 'unsigned int' is GNU libc, which originally implemented using type 'int', but which changed to 'unsigned int' in January 2001 (I speculate this was done to align with XNS 5.2 or perhaps one of the early drafts of 1003.1-2001). Given the widespread implementation of 'int', I believe the right thing to do is get the posix spec changed, and leave rfc2553bis as is. Actually, I did switch NetBSD over to `unsigned int' the other day; however, that and the amount of prior art (my survey didn't cover quite that much) are good reasons to reconsider this (same is true for the Austin Group). Stay tuned, Technical Corrigenda 1 (TC1) for 1003.1-2001 is active right now, I hope to have this fixed in TC1. I didn't occur to me to look there earlier (shame on me), but I just noticed your Aardvarks on that subject; unfortunately they (XBD ERN 24, XSH ERN 22) were rejected at the May meeting. In any case, I'll be watching austin-group-l. - Klaus IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: draft-ietf-ipngwg-rfc2553bis-05: getnameinfo() arguments
Stay tuned, Technical Corrigenda 1 (TC1) for 1003.1-2001 is active right now, I hope to have this fixed in TC1. I didn't occur to me to look there earlier (shame on me), but I just noticed your Aardvarks on that subject; unfortunately they (XBD ERN 24, XSH ERN 22) were rejected at the May meeting. In any case, I'll be watching austin-group-l. Yup. But we have a few more days before the results are finalized, to take issue with any decisions of the review team. - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Proposed IPv6 DNS Discovery Requirements
Date:Mon, 13 May 2002 19:15:46 +0700 From:Robert Elz [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | How can this work if the server isn't in the same site as the client? In reply to this query of mine, a private message (thanks for that) reminded me of a message that Itojun sent to the list back in early April... | Message-id: [EMAIL PROTECTED] | To: Ralph Droms [EMAIL PROTECTED] | Cc: [EMAIL PROTECTED] | From: [EMAIL PROTECTED] | Subject: Re: Stateless DNS discovery draft | Date: Fri, 05 Apr 2002 11:25:54 +0900 | if CPE can become dual-sited (participate into ISP's site and | customer's site) it can relay DNS query requests/responses between | clients in customer's site to DNS server in the ISP. which is true, messages could be relayed - however I believe that breaks the serverless requirement that is being suggested. That is, to relay a site local message effectively, the reply also needs to be relayed (the message into the ISP needs to be sent from the relay's address inside the ISP's address space, as the customer's site local address is useless there). So the reply will return to the CPE, and then needs to be relayed back to the end node (with the appropriate address substitutions made) To accomplish that, either the relay needs to retain state (it would be close enough to a specialised NAT server) or the protocol needs to include enough information so the relay can tell from the reply where the reply needs to be sent (which makes the whole protocol close enough to isomorphic to DHCP, and certainly could not just be DNS packets to a well known address). Either way, I don't think this meets the objective. Aside from the we aren't sure deployment will be good enough is there some reason why multicast isn't being used for this search? Or more bluntly perhaps, why svrloc isn't just being used? Multicast deployment will follow closely upon a requirement for multicast deployment - as long as no-one wants to use it because it isn't deployed, it never will be. Require it for a worthwhile application, and deployment will simply happen. kre IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
