http://permalink.gmane.org/gmane.ietf.v6ops hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.v6ops/22646 <pre> I really don't see what's wrong with the Abstract of RFC 4193. If you don't see a need personally or for your customers, that's fine. All the IETF does is provide mechanisms; users decide which ones to use. Brian _______________________________________________ v6ops mailing list v6ops-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/v6ops </pre> Brian E Carpenter 2013-05-26T02:48:58 http://permalink.gmane.org/gmane.ietf.v6ops/22645 <pre> ----- Original Message ----- I think the "LAN interface" in this draft is from the perspective of IPv6, and in your scenario, all those interfaces, if they're all using the same /64, are a single LAN (perhaps they're bridged or some similar trick below IPv6). However, maybe it would be better to adopt the IPv6 RFC2461 "Link" terminology i.e. this draft is extending the use of the 3GPP /64 prefix onto another link available on the UE, such as a Wifi interface etc. _______________________________________________ v6ops mailing list v6ops-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/v6ops </pre> Mark Smith 2013-05-26T02:08:32 http://permalink.gmane.org/gmane.ietf.v6ops/22644 <pre> On May 24, 2013, at 20:16 , Doug Barton &lt;dougb-qLNbe+GRMJz7+bCfF+nZqw&lt; at &gt;public.gmane.org&gt; wrote: I'm still waiting for someone to clearly state what that purpose is. Owen _______________________________________________ v6ops mailing list v6ops-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/v6ops </pre> Owen DeLong 2013-05-26T01:58:03 http://permalink.gmane.org/gmane.ietf.v6ops/22643 <pre> You can go even further if you take out the IP stack altogether. At some point, there's diminishing returns. Failure to support RA and SLAAC at a minimum is, IMHO, below that threshold. How does one reach the other? How do these preconfigured addresses find each other? If you're proposing building in a limitation that they all have to be on the same link, then there's no reason to use ULA, you can just use link local. If not, you have some 'splaining to do in answering the above question. Such as? Note, ways which require all devices to be on the same link are not a valid answer as such ways do not need ULA and can use LL instead. Owen _______________________________________________ v6ops mailing list v6ops-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/v6ops </pre> Owen DeLong 2013-05-26T01:53:32 http://permalink.gmane.org/gmane.ietf.v6ops/22642 <pre>alexandru.petrescu-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: the At the same time? In any event, that implementation you mentioned is not publicly documented. The folks at Apple and Verizon are welcome to share their wisdom on this topic. In any event, the work of this draft is to use the open ietf process to get folks on the same page so the wheel does not get reinvented several times in a vacume. CB to me. _______________________________________________ v6ops mailing list v6ops-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/v6ops </pre> cb.list6 2013-05-25T20:26:36 http://permalink.gmane.org/gmane.ietf.v6ops/22641 <pre> On May 24, 2013, at 11:45 , Alexandru Petrescu &lt;alexandru.petrescu-Re5JQEeQqe8&lt; at &gt;public.gmane.orgm&gt; wrote: How can that work in the real world? For example, with my iPhone 5 running on VZW, I seem to get the same /64 over the WiFi (mobile hotspot), the Cellular_PDP0 interface (the actual cellular interface), BlueTooth (mobile hotspot), and USB (mobile hotspot). From my perspective that's 3 LAN interfaces and a WAN interface sharing the same /64. This part makes sense to me. But bridging the 64share prefix across multiple LAN interfaces on the device (or even extending it via bridges on the LAN side) does not seem to be a problem IMHO. I wouldn't go quite that far. Acknowledging the limitations makes sense to me. Expanding upon those limitations to say that nobody can make a decision to accept them and deploy anyway is not correct, IMHO. Owen _______________________________________________ v6ops mailing list v6ops-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/v6ops </pre> Owen DeLong 2013-05-25T18:42:26 http://permalink.gmane.org/gmane.ietf.v6ops/22640 <pre>This draft proposes to redefine IPv6 multicast scope 0x03 from "reserved" to "Network-Specific scope, greater than Link-Local scope, defined automatically from the network topology". The expectation is that mesh trickle multicast, as defined in draft-ietf-roll-trickle-mcast, will define multicast scope 0x03 as "all interfaces attached to links in the mesh", for use in multicast delivery. I've requested a slot on the 6man agenda in Berlin to discuss the draft. - Ralph Begin forwarded message: _______________________________________________ v6ops mailing list v6ops-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/v6ops </pre> Ralph Droms 2013-05-25T14:06:00 http://permalink.gmane.org/gmane.ietf.v6ops/22638 <pre>Hi, I think what everybody is trying to tell you is that using a networking protocol only works if you follow the protocol's rules. IPv6 networks are divided into subnets, usually a /64 net network. Devices on the network need to know (a) which network they are on (prefix) and (b) what the gateway to other networks is. Depending on the setup and additional rules defined by the environment you might be able to hard-code (b). Hard-coding (a) is the problem that everybody is pointing at: there will be &gt;1 networks so you don't know up front which network the device will be connected to. Now you can pretend that there is only 1 network and hard-code all addresses from the same /64 prefix (ULA or global, doesn't matter, it's just a number) but then devices from other networks will have no way of communicating with them (because the rest of the world can't distinguish between the different instances of that 'one' network). This is scenario 1 that Owen described: "Multiple devices with the same prefix not on the </pre> Sander Steffann 2013-05-25T11:28:46 http://permalink.gmane.org/gmane.ietf.v6ops/22637 <pre> From: Lorenzo Colitti [mailto:lorenzo-hpIqsD4AKlfQT0dZR+AlfA&lt; at &gt;public.gmane.org] Sent: Friday, May 24, 2013 7:42 PM To: Liubing (Leo) Cc: v6ops-EgrivxUAwEY&lt; at &gt;public.gmane.org; draft-ietf-v6ops-ula-usage-recommendations-nZLwadvX8BAe0aqkDbg58A&lt; at &gt;public.gmane.orgrg Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) &lt;leo.liubing-hv44wF8Li93QT0dZR+AlfA&lt; at &gt;public.gmane.org&lt;mailto:leo.liubing-hv44wF8Li93QT0dZR+AlfA&lt; at &gt;public.gmane.org&gt;&gt; wrote: V. "the network needs ULA as the on-demand and stable addressing which doesn't need much code to support address assignment mechanisms like DHCP or ND." I don't think this makes sense. Are you saying such nodes only support manual address assignment? How is it possible that a sensor doesn't support automatic address assignment due to lack of resources, but has enough resources to implement a UI for manual address assignment? [Bing] The lack of resources mainly regarding the network environment, </pre> Liubing (Leo 2013-05-25T06:16:16 http://permalink.gmane.org/gmane.ietf.v6ops/22636 <pre> Or, ULAs are just fine for their intended purpose, it's just that you don't like the purpose. :) _______________________________________________ v6ops mailing list v6ops-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/v6ops </pre> Doug Barton 2013-05-25T03:16:51 http://permalink.gmane.org/gmane.ietf.v6ops/22635 <pre>Hi Alex, As a packet has its destination it is 'destined to' an address ... Let's keep it as is to avoid confusion. Section 3.0 General Behavior for All Scenarios clearly states: "If the 3GPP interface goes down or changes the IPv6 prefix, that state should be reflected in the LAN IPv6 configuration." So the solution is not limited to UEs with a static IPv6 prefix. Any changes on the 3GPP link shall be propagated to the LAN. (the old IPv6 prefix to be deprecated and the new one to be advertised to the LAN) Cheers, Ales _______________________________________________ v6ops mailing list v6ops-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/v6ops </pre> Vízdal Aleš 2013-05-24T23:18:30 http://permalink.gmane.org/gmane.ietf.v6ops/22634 <pre>I'd love to get away from non-working devices too... but the printer didn't have a static address assignment until you programmed the dhcp server. and if you connect it to a different network it will get a new address (which it will helpfully share). And then you'll change out the adsl modem. the next one, will assuming it assigns itself a ula pick a different one, and the printer will either have two or more ips,forget about the old one, be more conveniently addressed using link-local (different dicussion) or stop being accessible because it's only on the old subnet for which there's no RA and which your laptop will never discover. the consumer is going to push the reset button or cycle the power when it doesn't work, and things are going to have sort themselves out. _______________________________________________ v6ops mailing list v6ops-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/v6ops </pre> joel jaeggli 2013-05-24T23:03:42 http://permalink.gmane.org/gmane.ietf.v6ops/22633 <pre>... Well, I dunno. I am currently living in someone else's house for a few weeks, and only yesterday, I had to reboot the ADSL box, after which I could no longer print. Guess what? The printer's IPv4 address had changed. Since the Bonjour mechanism provided for the printer had already collapsed a couple of days earlier, the fix was to log into the ADSL box, force DHCP to give the previous IPv4 address to the printer's MAC address, and reboot everything again. Of course I'd love to get away from that, but I suspect that the ability to force the printer address to &lt;ULA_prefix&gt;::6 instead of 192.168.1.6 would have been handy if this house had IPv6. Brian _______________________________________________ v6ops mailing list v6ops-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/v6ops </pre> Brian E Carpenter 2013-05-24T22:48:29 http://permalink.gmane.org/gmane.ietf.v6ops/22632 <pre> &gt; Hi Lorenzo &gt; &gt; &gt; &gt;&gt; So you can use any type of address, not only ULA. So this is not a &gt;&gt; use case for ULA. &gt; &gt; &gt; &gt; The ULA reasoning starts elsewhere. It is tied to a deployment use &gt; case: &gt; &gt; &gt; &gt; When nodes are installed in a new house, there may be no internet &gt; connectivity - and even more importantly: Even if there is internet &gt; connectivity, then you can be certain that at some time, the ISP will &gt; change your assigned prefix. &gt; &gt; This is critical to certain 6LoWPAN applications such as home &gt; automation. &gt; &gt; Remote controls, sensors and wall controllers are spread all over the &gt; house. They control lights, garage doors and aircon devices. &gt; &gt; The addresses of the lights, garage doors and aircon devices MUST NOT &gt; change since the remote controls, sensors and wall controllers are &gt; permanently paired to the IPv6 addresses of lights, garage doors and &gt; aircon devices on the application level. &gt; If we look at how these things are done today, I think it's pretty rare to </pre> joel jaeggli 2013-05-24T22:09:47 http://permalink.gmane.org/gmane.ietf.v6ops/22631 <pre>Le 24/05/2013 23:11, joel jaeggli a écrit : That was then. Since then even smaller platforms are tried. An autoconfiguration feature is a functionality, and compares badly to whatever static preconfiguration, in terms of memory/cpu constraints. I really dont see why arguing against this, it's simply basics. Alex Frankly I don't see it. IETF _______________________________________________ v6ops mailing list v6ops-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/v6ops </pre> Alexandru Petrescu 2013-05-24T21:19:45 http://permalink.gmane.org/gmane.ietf.v6ops/22630 <pre>A decade ago dallas-semiconductor had a working v6 stack on a 8051 based 8 bit microcontroller with 64k of rom... There seems to be small but quite persistent faction that insists on the notion that functionally limited systems are incapable of operating around the incredibly basic set of functional building blocks for an ipv6 network on their link-layer of choice. Frankly I don't see it. IETF participants have invested a lot of productive time and energy in low-power/low signalling/low bandwidth embedded networking, stripping out the things that make it flexible robust and easy to deploy in the interest of something that might notionally be more compact then the toolkit we have at present, seems incredibly limiting. Can you do it? Sure. In fact, nobody is going to stop you. Is it an "improvement"? Maybe by some measure, but I kind of doubt it. _______________________________________________ v6ops mailing list v6ops-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/v6ops </pre> joel jaeggli 2013-05-24T21:11:20 http://permalink.gmane.org/gmane.ietf.v6ops/22629 <pre>Le 24/05/2013 22:36, Gert Doering a écrit : My point being that ULA could be very much appropriated for constrained devices (without SLAAC) - and yet have a network stack. Alex _______________________________________________ v6ops mailing list v6ops-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/v6ops </pre> Alexandru Petrescu 2013-05-24T20:39:10 http://permalink.gmane.org/gmane.ietf.v6ops/22628 <pre>Hi, On Fri, May 24, 2013 at 08:51:05PM +0200, Alexandru Petrescu wrote: As could a device without a network stack. Your point being? Gert Doering -- NetMaster </pre> Gert Doering 2013-05-24T20:36:15 http://permalink.gmane.org/gmane.ietf.v6ops/22627 <pre>Le 24/05/2013 17:53, Owen DeLong a écrit : Not sure what you mean. But sure a device which has its address pre-configured could go very far in reducing its memory/cpu print. Alex ? Its sufficient for the remote apps to be preconfigured with the devices' addresses, no need to preconfigure the other way around. Its a way of doing it. And there are other simpler ways. Alex _______________________________________________ v6ops mailing list v6ops-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/v6ops </pre> Alexandru Petrescu 2013-05-24T18:51:05 http://permalink.gmane.org/gmane.ietf.v6ops/22626 <pre> On May 24, 2013, at 11:21 , Tim Chown &lt;tjc-jaJdc+oKuOm+cE1VCfRBVw&lt; at &gt;public.gmane.org&gt; wrote: Correct... This means that you cannot count on it persisting. I agree. That is not the same as being able to count on it changing. There will be cases where it does not change. For example, my home has a direct ARIN IPv6 assignment. I realize this is not necessarily the norm, but it's also not out of the question. Many other homes I know of subscribe to business class services in order to get persistent addressing. I have no reason to believe this practice will be less common in the future. Understood. I think it's a horrible assumption (per my previous example), but I understand the reasoning behind it. Sure. I don't know. Certainly, they should support RA. They don't really need to do so when sleeping as they can send an RS when they wake up if necessary. I don't know. My point is that I don't believe the IETF should be designing RFCs around the brokenness of current designs. Rather we should document the </pre> Owen DeLong 2013-05-24T18:45:59 http://permalink.gmane.org/gmane.ietf.v6ops/22625 <pre>Le 24/05/2013 13:42, Lorenzo Colitti a écrit : RA could be used to just communicate the default route, not the link prefix - that makes for a smaller RA which is ok for constrained devices. Actually, RA may not be needed at all for a constrained device. You could have a constrained device that just knows its default route. Alex _______________________________________________ v6ops mailing list v6ops-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/v6ops </pre> Alexandru Petrescu 2013-05-24T18:48:22 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.v6ops