Re: UDP+Fragmentation

On 08/06/2013 03:07 PM, Templin, Fred L wrote: If we are going to define a new protocol type, let's define one that addresses everything we are currently struggling with and has the extensibility to address additional requirements moving forward into the future. So in other words let's make all

Re: ra-privacy: my responses to comments

On 08/01/2013 09:01 AM, Erik Nordmark wrote: On 8/1/13 2:31 PM, Keith Moore wrote: Hosnieh clarified the slide by explaining that by using "public addresses" she meant addresses resolvable from DNS lookups. But then the idea that a node should not use "public addresses" is problematic for dif

Re: "Deprecate"

On 07/30/2013 02:55 PM, Ronald Bonica wrote: I was thinking of tunnels as legacy applications Yeah, please stop doing that. :) While some of the transitional technologies like 6to4 or proto 41 tunnels will fade away more over time, there is no Internet future where tunnels do not play a crit

Re: Meta-issues: On the deprecation of the fragmentation function

On 07/09/2013 11:12 AM, Ronald Bonica wrote: Doug, It might be interesting to revisit what we mean by deprecating IPv6 fragmentation It means that the IETF will not approve any new protocols that rely upon IPv6 fragmentation. Nothing more, nothing less. Thanks for clarifying. FWIW, I un

Re: Meta-issues: On the deprecation of the fragmentation function

I stated it a while back, but now that folks seem to be coming around I thought it might be worthwhile to restate that I agree that deprecating fragmentation is a bad idea. My part of this elephant is that we need fragmentation/PMTUD/Window Scaling to work reliably as we look toward future netw

Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt

On 06/28/2013 09:20 PM, Brian E Carpenter wrote: On one point... On 29/06/2013 10:44, Templin, Fred L wrote: ... and (b) accepting that strapping the MTU at 1280 is a reasonable short term policy. If (a) progressively pervades the installed base then (b) can be dropped as the years go by. On

Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt

On 06/21/2013 01:52 PM, Brian E Carpenter wrote: On 22/06/2013 07:53, Ronald Bonica wrote: I don't 100% agree. In the case that PMTUD is broken, there'd be nothing to stop a current DNSSEC implementation from always assuming a default path MTU of 1280, without awaiting confirmation from PMTUD, a

Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt)

On 06/19/2013 10:09 AM, Hosnieh Rafiee wrote: In my opinion, if the purpose of your scan is the last one, then this is a security issue. If it concerns users' information, then it is a privacy issue. If you think that it is out of the scope of this group to deal with the users' data, then it is p

Re: [6MAN] Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain)

On 06/14/2013 03:00 PM, Warren Kumari wrote: I've already mentioned this in one of the N (where is is becoming distressingly large) threads on this Yeah, you would be one of those "more knowledgeable" folks I was referring to. :) --

Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain)

On 06/14/2013 02:19 PM, Tony Hain wrote: While guidance is useful to establish a consistent-behavior baseline across vendors and deployments, care must be taken to avoid the trap of precluding innovation and evolution. Well-meaning limits based on current hardware capabilities will become doctrin

Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain)

On 06/14/2013 01:39 AM, t.petch wrote: - Original Message - From: "Doug Barton" To: Sent: Thursday, June 13, 2013 9:23 PM On 06/13/2013 01:17 AM, Randy Bush wrote: FWIW, I don't think anyone has proposed "if the chain is larger than X, then drop". i am sa

Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

On 06/13/2013 01:17 AM, Randy Bush wrote: FWIW, I don't think anyone has proposed "if the chain is larger than X, then drop". i am saying that i am telling my neighbor that, if the header length is larger than X, it is likely that their packet will not propagate. it's an ops bcp statement, not

Re: Router advertisement based privacy - I-D: Action :draft-rafiee-6man-ra-privacy

On 05/25/2013 09:06 AM, Hosnieh Rafiee wrote: As I explained in my answer to Ray in my last message, if monitoring and other things are your first priority, then you can use another approach rather than that of RFC 4941. But you cannot say that this RFC will not be used in future because we thin

Re: Router advertisement based privacy - I-D: Action :draft-rafiee-6man-ra-privacy

On 05/24/2013 08:17 AM, Hosnieh Rafiee wrote: I just wonder why, when you can use a monitoring system to log all your events (MAC + IP) when you are inside a corporate network, you see this as a big issue. I work primarily with customers who implement networks inside their own borders. Ray is

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

On 04/29/2013 01:12 PM, Fernando Gont wrote: On 04/29/2013 05:00 PM, Doug Barton wrote: I only peripherally followed the early discussion about this topic (only so many hours in the day). I confess that I never "got" the need for this, but lots of people seemed enthusiastic about it

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

On 04/29/2013 12:39 PM, Ray Hunter wrote: Christian Huitema wrote: The "problem" here is that don't have all the names/IDs we'd like. For example, using the MAC address as the Interface_ID would do for this purpose... but the the IPv6 address is tied to the MAC address, and would change upon r

Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/03/2013 06:13 PM, Michael Richardson wrote: | So, we have assumed that a 802.11p sniffer sitting in Times Square | can sniff the prefix used by passing vehicles. If I put another | sniffer outside Wrigley Field, I can do correlation... how d

Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/03/2013 09:00 AM, Michael Richardson wrote: | So, I have a question: how much privacy is actually contained in the | VIN or indexed by the VIN? Given that it's printed on the windshield. | Yes, it contains model, year and manufacturer of the

Re: 6MAN Agenda for IETF86

On 03/08/2013 12:06 AM, Fernando Gont wrote: Hi, Bob, Please replace the link to with a link to It's better to leave the -NN off the end altogether, then th

Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt

On 02/19/2013 12:40 PM, Alexandru Petrescu wrote: Le 19/02/2013 18:39, Doug Barton a écrit : On 02/19/2013 07:40 AM, Alexandru Petrescu wrote: Such a concern would be all the more valid if there were a specification which said 'each vehicle MUST form its IIDs based on their VINs'.

Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt

On 02/19/2013 07:40 AM, Alexandru Petrescu wrote: Such a concern would be all the more valid if there were a specification which said 'each vehicle MUST form its IIDs based on their VINs'. But this is not the case. We are not trying for such a definitive document. We are certain that some vehi

Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt]

Rémi, I think you've misunderstood me. Please see below. On 02/06/2013 02:01 AM, Rémi Després wrote: 2013-02-06 00:45, Doug Barton : On 02/05/2013 05:57 AM, Rémi Després wrote: Hi, Doug, Please see inline. 2013-02-04 à 18:37, Doug Barton : On 02/04/2013 12:38 AM, Rémi Després

Re: Keeping the 4rd-range issue separate from the general u/g discussion

On 02/07/2013 06:01 AM, Rémi Després wrote: Besides, these remaining concerns are aside from the question asked by Softwire Rémi, Do you admit to the possibility that the design coming from softwire might have flaws that should be addressed before it proceeds? I'm not saying necessarily tha

Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt]

On 02/05/2013 05:57 AM, Rémi Després wrote: Hi, Doug, Please see inline. 2013-02-04 à 18:37, Doug Barton : On 02/04/2013 12:38 AM, Rémi Després wrote: It remains that IIDs having u=1 SHOULD be unique, i.e. with rare enough exceptions. This is somewhat similar to the expectation that ULA

Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt]

On 02/04/2013 07:12 PM, Randy Bush wrote: In scenarios where privacy matters a lot, if our default policy is "no privacy", those users "opting in" for privacy would be flagged as "suspicious" just for the act of "opting in". and 82.3% would not realize they needed to opt out. i would think tha

Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt]

On 02/04/2013 12:38 AM, Rémi Després wrote: It remains that IIDs having u=1 SHOULD be unique, i.e. with rare enough exceptions. This is somewhat similar to the expectation that ULA collisions shouldn't be seen). This theoretical unicity has been extensively used to assign stable IIDs, without

Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt

On 10/20/2012 9:36 AM, sth...@nethelp.no wrote: >> There is also the question of availability of DHCP software on smaller >> platforms which have no SIM card. It may be easier to do this with ND >> in smaller settings. > > The obvious conclusion to this argument is that a *lot* of DHCP > function

Re: about DHCPv6/SLAAC interaction

On 8/1/2012 5:58 PM, Alexandru Petrescu wrote: > Le 01/08/2012 13:35, Liubing (Leo) a écrit : >> Hi, all >> >> Firstly, thanks for Karl's elaborate analysis and solution proposal >> for the M/O issue. I think that's definitely reasonable reference if >> we want to fix the issue. >> >> But as some c

Re: 3484bis and privacy addresses

On 3/29/2012 6:13 AM, Alex Abrahams wrote: > I'm sorry, but while I agree we have to think outside > the corporate environment, I think we have to think way outside and we > need to remember the kind of reasons why privacy exists, before saying > the privacy extensions are only to keep a few hundre

Re: 3484bis and privacy addresses

On 3/27/2012 2:43 PM, Karl Auer wrote: > On Tue, 2012-03-27 at 21:05 +0200, Ray Hunter wrote: >> IMHO the proper *default* behavior is still "off" = option A. In other >> words, default = IPv4-like behavior, at least until we really figure >> out how to operate all of these fancy new features of IP

Re: Fragmentation-related security issues

On 01/06/2012 01:54, sth...@nethelp.no wrote: Looks like FreeBSD should patch. :-) >>> >>> FYI, FreeBSD 7.4 is the last release of the 7.x branch, and was released >>> almost a year ago. It's scheduled to EOL in a little more than a year. >>> >>> It would be much more interesting to know if th

Re: Fragmentation-related security issues

On 01/05/2012 14:54, Fernando Gont wrote: > On 01/05/2012 07:45 AM, Florian Weimer wrote: >> > Steinar wrote that atomic fragments break FreeBSD 7.4 (and there might >> > be others, of course). Not sending them breaks important transition >> > technology. > > Looks like FreeBSD should patch. :-)

Re: Fragmentation-related security issues

On 01/03/2012 18:45, Fernando Gont wrote: > On 01/03/2012 10:22 PM, Dan Wing wrote: >>> ... and this is not a feature because? And no, don't quote the >>> robustness principle. The floor for MTU has been hard-coded since day >>> 1, so anyone who breaks that deserves what they get. >> >> Yes, I agre

Re: Fragmentation-related security issues

On 01/04/2012 05:55, RJ Atkinson wrote: > Earlier, Doug Barton wrote: >> On 01/03/2012 11:02, Dan Wing wrote: >>> If IPv6 hosts don't handle >>> ICMP packet-too-big of less than 1280, those IPv4/IPv6 translators >>> won't work with sub-1280 MTU I

Re: Fragmentation-related security issues

On 01/03/2012 13:52, Eric Vyncke (evyncke) wrote: > Rather than dropping those ICMP PTB, let's accept them but let the OS decide > which is the minimum size path MTU that it can accept/tolerate... As someone who works for a router company I can see why the "punt it to the OS" option seems attrac

Re: Fragmentation-related security issues

On 01/03/2012 11:02, Dan Wing wrote: > If IPv6 hosts don't handle > ICMP packet-too-big of less than 1280, those IPv4/IPv6 translators > won't work with sub-1280 MTU IPv4 paths. ... and this is not a feature because? And no, don't quote the robustness principle. The floor for MTU has been hard-co

Re: IPv6 Router Advertisement Option for NTP Server Configuration

On 12/21/2011 15:52, Bhatia, Manav (Manav) wrote: > Hi Doug, > >> >> Sort of surprised that no one else has responded so far, but I'll >> bite. Quite simply, "no." Slightly less simply, "use DHCP since >> that's what it's for." >> > > I wish it were this simple. Well good news for you then, i

Re: IPv6 Router Advertisement Option for Foobar Configuration

ry Agent is optional). > > A combination of basic RA plus directory-less SLP would be > necessary and sufficient for small unmanaged networks, I think. > > Regards >Brian > > On 2011-12-22 09:22, Doug Barton wrote: >> On 12/21/2011 11:44 AM, Brian E Carpenter wro

Re: IPv6 Router Advertisement Option for Foobar Configuration

On 12/21/2011 11:44 AM, Brian E Carpenter wrote: > On 2011-12-22 07:37, Doug Barton wrote: >> On 12/19/2011 5:24 PM, Bhatia, Manav (Manav) wrote: >>> Hi, >>> >>> We have posted a new draft that extends Router Advertisements to >>> include information

Re: IPv6 Router Advertisement Option for NTP Server Configuration

On 12/19/2011 5:24 PM, Bhatia, Manav (Manav) wrote: > Hi, > > We have posted a new draft that extends Router Advertisements to > include information about the one or more NTP servers present in the > network. This is useful where the delays in acquiring server > addresses and communicating with th

Re: Conflict between RA and DHCP in MIF case

On 11/13/2011 20:04, Karl Auer wrote: > I didn't say people should do these things, just that there are things > that *can be* delivered via RA and that *can be* delivered via DHCP, and > that *can conflict*. Given that this is a configuration error by definition, why can't we just say that the be

Re: /64 ND DoS

On 07/12/2011 01:48, Philip Homburg wrote: > So what I was thinking of, what if a router that is under attack would > periodically multicast to the all-nodes multicast address a message saying > "help I'm under attack". Upon receiving such a message all nodes send a > neighbor solication to the r

Re: Node Requirements: Revised text for DHCP on routers

I think this is much better, and I would not object to the text as is (modulo Ralph's suggestions). I would like to make a couple of suggestions of my own for the middle two paragraphs that you should feel free to ignore. :) On 5/27/2011 10:51 AM, Thomas Narten wrote: Going through this threa

Re: review of draft-ietf-node-req-bis

On 05/27/2011 17:52, Mark Smith wrote: Hi Doug, On Thu, 26 May 2011 15:47:04 -0700 Doug Barton wrote: On 05/26/2011 15:03, Mark Smith wrote: Exactly. That's the problem. If you know you can't or aren't very likely to be able to relay DHCP options to customer's end-nod

Re: review of draft-ietf-node-req-bis

On 05/26/2011 15:03, Mark Smith wrote: Exactly. That's the problem. If you know you can't or aren't very likely to be able to relay DHCP options to customer's end-nodes, you don't bother sending them. The myriad of DHCP(v4 and v6) options that exist that may be useful to an SP are currently of no

Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD

On 05/24/2011 15:00, Templin, Fred L wrote: Good point; yes, even DHCPv6 requires link-locals. The link-locals could be manually configured, but it seems reasonable to assume that they would often be autoconfigured using SLAAC. I'm confused (nothing new about that). In FreeBSD the OS creates th

Re: Short 6MAN WG Last Call:

On 5/12/2011 3:22 PM, Manfredi, Albert E wrote: Mark Smith wrote: I think it would be reasonable to make DHCP a SHOULD, however I've thought that one of the reasons SLAAC exists is to provide simpler and lighter weight address configuration method for resource constrained end-nodes such as embe

Re: Introducing draft-6man-addresspartnaming

On 04/14/2011 13:23, Richard Hartmann wrote: Hi all, after renaming to draft-hartmann-6man-addresspartnaming, I am still waiting for feedback. I am not sure how the exact procedures are: Does lack of feedback mean people are mostly OK with this or that no one cares? To be painfully honest, m

Re: draft-gont-6man-managing-privacy-extensions-00.txt

On 03/12/2011 16:44, Christian Huitema wrote: It doesn't. The I-D aims at allowing routers specify which policy they want hosts to employ when generating their IPv6 addresses. Uh? I definitely don't want to give the router at Starbucks the means to specify the privacy configuration of my lapt

Re: draft-gont-6man-managing-privacy-extensions-00.txt

On 03/09/2011 06:57, Mikael Abrahamsson wrote: If you want to know the mac address of the computer who used an IP address at a certain time, then you need to tell the host to only use EUI64 based address and nothing else, you don't tell it to disable privacy extensions. Just because privacy exten

Re: draft-yhb-6man-slaac-improvement-00

On 03/03/2011 06:50, Yu Hua bing wrote: DHCPv6 can be deployed in the sites which use the prefixes longer than 64.Why can't SLAAC? Because SLAAC was not designed as a general-purpose mechanism, and should not be modified (further) to be so. Doug -- Nothin' ever doesn't change, but

Re: DHCPv6 vs ND strikes again

On 9/21/2010 7:29 PM, Brian E Carpenter wrote: On 2010-09-22 14:03, Doug Barton wrote: On 9/21/2010 4:16 PM, Brian E Carpenter wrote: we already have an IPv6 legacy As much as I wish it were otherwise, I don't think there is yet enough of a deployment at this point to really make this a

Re: DHCPv6 vs ND strikes again

On 9/21/2010 4:16 PM, Brian E Carpenter wrote: we already have an IPv6 legacy As much as I wish it were otherwise, I don't think there is yet enough of a deployment at this point to really make this a show-stopper. But even if we do, I don't see any reason we couldn't have a no-ND solution

Re: New version available (Was Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt)

On 9/10/2010 5:59 AM, Jari Arkko wrote: Some of the discussion has gone into the history of IPv6 design, what configuration model was intended by the original designers as the right one, and so on. I would suggest that while that's interesting, it may be secondary to what we are discussing here.

Re: New version available

On 9/10/2010 7:13 AM, Wojciech Dec wrote: 3. Set a bar on the minimum _CPE_ requirements that will be supported by the network (ensuring connectivity) within the given scenarios, along with potentially having a single configuration/provisioning method? An example of this would be requiring a rout

Re: New version available

On 9/8/2010 11:25 AM, Joel M. Halpern wrote: The question of whether DHCP should be used to supplement SLAAC< when SLAAC is used for address assignment, woudl seem to be a separate question. I think that's part of what the WG needs to decide, which is why I (and now others) have voiced an opin

Re: New version available (Was Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt)

Your message is very carefully crafted rhetorically, for which I credit you with many style points. In terms of standards development less so, but I'll take everything you say here at face value just in case. On 09/08/2010 11:01 AM, Joel M. Halpern wrote: Doug, I am confused by your comments.

Re: New version available (Was Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt)

f the situation is correct, such a device requires manual installation of the IPv6 stack and still requires IPv4 for DNS. - Ralph On Sep 8, 2010, at 5:36 PM 9/8/10, Suresh Krishnan wrote: Hi Doug, On 10-09-08 02:02 AM, Doug Barton wrote: On 09/07/2010 06:38 AM, JOSHI, SHRINIVAS ASHOK (SHRI

Re: New version available (Was Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt)

On 09/07/2010 06:38 AM, JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK) wrote: 5. Creating an alternative to DHCPv6 ? One SLAAC is defined to do functionality similar to DHCP (including per host prefixes/options) how long before options are added so SLAAC becomes an alternative to DHCPv6 ? This is t

Re: Question about SLAAC: how the host determines the prefixes allocated from different prefix pools

On 06/17/10 19:31, Fortune HUANG wrote: Hi Doug, Please note that "Fortune HUANG wants it to be that way" has never been used as any kind of reason in this discussion by myself. Actually that's the only justification you've provided so far. so please respond to my reason as you quoted below

Re: Question about SLAAC: how the host determines the prefixes allocated from different prefix pools

On 06/17/10 17:39, Fortune HUANG wrote: Since the service type of the prefix should be classified to the prefix related configuration, it should be carried in RA ... and what Mark, myself, and everyone else who have +1'ed our statements is saying is that "Fortune HUANG wants it to be that way"

Re: Question about SLAAC: how the host determines theprefixesallocated from different prefix pools

On 6/10/2010 6:23 PM, Fortune HUANG wrote: > 1) Assuming DHCPv6 is always available in the scenario where there are > multiple prefix pools for different services, just use DHCPv6 as you and > Shree said. +1 RA and/or SLAAC are for _simple_ automatic configuration. If your configuration isn't sim

Re: next steps with 6man-text-addr-representation

On 3/5/2010 4:07 PM, Seiichi Kawamura wrote: Hi Jari ..resending. this time making sure its to the 6man list... I think the points rasied at the IESG teltechat have been cleared and the 6man WG feels comfortable with the latest version of the draft. Will this be placed on the agenda of the next

Re: I-D Action:draft-ietf-6man-text-addr-representation-07.txt

On 02/25/10 18:30, internet-dra...@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Maintenance Working Group of the IETF. > > > Title : A Recommendation for IPv6 Address Text Representatio

Re: I-D Action:draft-ietf-6man-text-addr-representation-06.txt

On 02/25/10 16:16, Seiichi Kawamura wrote: > Brian, Doug, Antonio > > Thanks for the text idea. > So the final fix will probably look like this. > >As IPv6 deployment increases there will be a dramatic increase in the >need to use IPv6 addresses in text. >While the IPv6 address archit

Re: I-D Action:draft-ietf-6man-text-addr-representation-06.txt

On 02/25/10 14:29, Juergen Schoenwaelder wrote: > Adding one more to the beauty contest: > > This document defines a canonical textual representation format. It > does not define a format for internal storage, such as within an > application or database. That's fine with me. Doug --

Re: I-D Action:draft-ietf-6man-text-addr-representation-06.txt

On 02/25/10 00:10, Antonio Querubin wrote: > On Mon, 22 Feb 2010, Brian E Carpenter wrote: > >> I think it's out of scope of a *protocol* standard. However, I think Doug >> has a valid point, so maybe we should add an explicit statement that >> the document defines what should be transmitted and p

Re: I-D Action:draft-ietf-6man-text-addr-representation-06.txt

On 02/21/10 11:01, Brian E Carpenter wrote: > On 2010-02-21 19:38, Doug Barton wrote: >> On 02/20/10 22:30, Antonio Querubin wrote: >>> On Sat, 20 Feb 2010, Doug Barton wrote: >>> >>>> 4.2.4. Exception to the "::" Shortening Rule >>

Re: I-D Action:draft-ietf-6man-text-addr-representation-06.txt

On 02/20/10 22:30, Antonio Querubin wrote: > On Sat, 20 Feb 2010, Doug Barton wrote: > >> 4.2.4. Exception to the "::" Shortening Rule >> >> When it is necessary to record an address with consecutive 16 bit 0 >> fields without the use of the "::

Re: I-D Action:draft-ietf-6man-text-addr-representation-06.txt

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 02/19/10 02:00, internet-dra...@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Maintenance Working Group of the IETF. > > > Title :

Re: next steps with 6man-text-addr-representation

On 2/6/2010 1:40 PM, Brian E Carpenter wrote: > On 2010-02-06 13:19, Bob Hinden wrote: >> Doug, >> >> On Feb 5, 2010, at 3:59 PM, Doug Barton wrote: >> >>> On 2/5/2010 2:37 PM, Brian E Carpenter wrote: >>>> Oh, OK, that is fine for conformance of

Re: next steps with 6man-text-addr-representation

On 2/5/2010 2:37 PM, Brian E Carpenter wrote: > Oh, OK, that is fine for conformance of course, but leaves things > open when you are talking about generating strings. If we want the > new recommendation to be a MUST, we may have to consider wording to > make it clear how widely it applies. Many ex

Re: How to use IPv6 feature in WINDOWS XP on laptop

Li Defeng wrote: Who can tell me one public tunnel broker IPv4 address? I hope to use it to set up a IPv6 over IPv4 tunnel to access some IPv6 application. http://www.research.earthlink.net/ipv6/ This works quite well for me. hth, Doug -- If you're never wrong, you're not trying hard e

Re: Question about precluding use of autonomous address-configuration

Ralph Droms wrote: > Suppose the nodes on a link are to be restricted to the use of addresses > assigned through DHCP, and precluded from the use of autonomous address- > configuration. I can also think of a third case, addresses are assigned statically. > It seems there are two ways to accomplis