Hi Bert,
On Thu, 12 May 2011 17:22:05 -0500
"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 re
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
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 embedded ones. So perhaps it could be
> worth m
Hi Thomas,
On Thu, 12 May 2011 09:23:20 -0400
Thomas Narten wrote:
> Ole,
>
> Getting back to some of your other points...
>
> Ole Troan writes:
> > >> * RFC2675: I would just remove that.
> > >
>
> However, I do not see evidence that the WG has changed its thinking
> and would now be wil
On Thu, 12 May 2011 15:20:30 +0200
Ole Troan wrote:
> >> To put it another way, if we think there is a good use case for this
> >> as Ole describes, we will be doing a service to the devices that
> >> don't have their IPv6 code yet, to make it a SHOULD so they are
> >> more likely to implement it
On 2011-05-13 01:23, Thomas Narten wrote:
...
> I personally would support having DHCP be a SHOULD rather than a
> MAY. The justification in my mind is that if you want the network
> operator to have the choice of whether they want to use Stateless
> addrconf OR DHCP, they only have that choice of
Ran,
On May 12, 2011, at 7:55 AM, RJ Atkinson wrote:
> On Friday 6th May 2011, Ole Troan wrote in part:
>> basically I want the document to say that IETF has standardised
>> two mechanisms to configure hosts. one using ND and one using DHCP.
>> As they apply to different management models, nodes
> I personally would support having DHCP be a SHOULD rather than a
> MAY.
thank you
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
---
On Friday 6th May 2011, Ole Troan wrote in part:
> basically I want the document to say that IETF has standardised
> two mechanisms to configure hosts. one using ND and one using DHCP.
> As they apply to different management models, nodes SHOULD implement both.
On 12th May 2011, Thomas Narten res
Ole,
Getting back to some of your other points...
Ole Troan writes:
> >> * RFC2675: I would just remove that.
> >
> > The docuent currently says:
> >
> > IPv6 Jumbograms [RFC2675] MAY be supported.
> >
> > How about I replace that with:
> >
> > IPv6 Jumbograms [RFC2675] are an opti
>> To put it another way, if we think there is a good use case for this
>> as Ole describes, we will be doing a service to the devices that
>> don't have their IPv6 code yet, to make it a SHOULD so they are
>> more likely to implement it.
>
> Here is some proposed text:
>
> 5.3. Default Router
> To put it another way, if we think there is a good use case for this
> as Ole describes, we will be doing a service to the devices that
> don't have their IPv6 code yet, to make it a SHOULD so they are
> more likely to implement it.
Here is some proposed text:
5.3. Default Router Prefere
Hi Thomas,
On Wed, 11 May 2011 17:12:55 -0400
Thomas Narten wrote:
> Ole Troan writes:
> > > That is, a CPE router with multiple LAN interfaces is not allowed to
> > > advertise itself as a default router (when it loses internet
> > > connectivity), when that is arguably a fine thing for it to
Thomas,
>>> That is, a CPE router with multiple LAN interfaces is not allowed to
>>> advertise itself as a default router (when it loses internet
>>> connectivity), when that is arguably a fine thing for it to do.
>>>
>>> I have to wonder whether RFC 6204 has gotten this wrong. It is very
>>> CPE
Ole Troan writes:
> > That is, a CPE router with multiple LAN interfaces is not allowed to
> > advertise itself as a default router (when it loses internet
> > connectivity), when that is arguably a fine thing for it to do.
> >
> > I have to wonder whether RFC 6204 has gotten this wrong. It is ve
Thomas,
>>> Can someone explain to me the rationale for mandating 4191 in 6204?
>>> What was the scenario that was envisioned that necessitates 4191?
>
>> it was the only way we found to keep support for ULA prefixes. the
>> scenario is if you have a home CPE with ULA enabled, but no upstream
>
On Mon, 9 May 2011, Bob Hinden wrote:
iOS and Symbian appear to do IPv6 pretty well. I think iOS is ahead of
MacOS as it get's updated more often. Not sure about Android, Win7
phone, and the others.
Android 2.3.4 actually has GUI options to configure IPv6 APN, but we have
yet to find a pho
>
>
>
>On May 9, 2011, at 5:37 PM, Fred Baker wrote:
>
>>
>> On May 9, 2011, at 5:15 PM, Thomas Narten wrote:
>>
>>> When are we going to start counting cell phones, tablets and other
>>>electronic devices?
>>
>> When they start implementing IPv6 at all...
>
>iOS and Symbian appear to do IPv6 pr
On May 9, 2011 6:26 PM, "Bob Hinden" wrote:
>
>
> On May 9, 2011, at 5:37 PM, Fred Baker wrote:
>
> >
> > On May 9, 2011, at 5:15 PM, Thomas Narten wrote:
> >
> >> When are we going to start counting cell phones, tablets and other
electronic devices?
> >
> > When they start implementing IPv6 at al
On May 9, 2011, at 5:37 PM, Fred Baker wrote:
>
> On May 9, 2011, at 5:15 PM, Thomas Narten wrote:
>
>> When are we going to start counting cell phones, tablets and other
>> electronic devices?
>
> When they start implementing IPv6 at all...
iOS and Symbian appear to do IPv6 pretty well. I
> > Can someone explain to me the rationale for mandating 4191 in 6204?
> > What was the scenario that was envisioned that necessitates 4191?
> it was the only way we found to keep support for ULA prefixes. the
> scenario is if you have a home CPE with ULA enabled, but no upstream
> IPv6 connect
On May 9, 2011, at 5:15 PM, Thomas Narten wrote:
> When are we going to start counting cell phones, tablets and other electronic
> devices?
When they start implementing IPv6 at all...
IETF IPv6 working group mailing list
ipv6@
Thomas,
On May 9, 2011, at 5:15 PM, Thomas Narten wrote:
>> My personal observation, if it's implemented in Windows Vista &
>> WIn7, Linux, BSD, (and probably Macs), then this sounds like widely
>> implemented. This plus Ole's use scenario, leads me to think it
>> should be a SHOULD.
>
> I coul
> My personal observation, if it's implemented in Windows Vista &
> WIn7, Linux, BSD, (and probably Macs), then this sounds like widely
> implemented. This plus Ole's use scenario, leads me to think it
> should be a SHOULD.
I could probably go with a SHOULD.
But, I wonder if we are living in
Thomas,
My personal observation, if it's implemented in Windows Vista & WIn7, Linux,
BSD, (and probably Macs), then this sounds like widely implemented. This plus
Ole's use scenario, leads me to think it should be a SHOULD.
Bob
On May 9, 2011, at 12:58 PM, JINMEI Tatuya / 神明達哉 wrote:
> At
At Fri, 06 May 2011 13:48:19 -0400,
Thomas Narten wrote:
> I'm not entirely sure what to do here. RFC 4191 is not widely
> implemented, AFAIK. It's in Windows Vista (and onwards) and also
> Linux. Not sure where else (I'm guessing not on Macs?)
(I'm not sure if the following information is reall
Thomas,
One small comment and one small nit, inline:
> > * 5.9.4 Default Address Selection
> > As RFC3484 generates IPv6 brokenness. I think we should change
> > this reference to RFC3484bis.
>
> Can't do that. That would delay publication of the RFC.
>
> BTW, you could make the same argueme
Thomas,
> Thanks for the review!
>
>> I'm on the fence with regards to this document. if this document is
>> meant to be the RFC1122/1812 document for IPv6, I think we are too
>> early in the deployment of IPv6 to have gathered enough experience
>> with what works and what doesn't. as a profile
Hi Ole.
Thanks for the review!
> I'm on the fence with regards to this document. if this document is
> meant to be the RFC1122/1812 document for IPv6, I think we are too
> early in the deployment of IPv6 to have gathered enough experience
> with what works and what doesn't. as a profile of an IP
b Hinden
Subject: Re: Short 6MAN WG Last Call:
Ole,
On May 5, 2011, at 6:49 AM, Ole Troan wrote:
> I'm on the fence with regards to this document. if this document is
> meant to be the RFC1122/1812 document for IPv6, I think we are too early in
> the deployment of IPv6 to have ga
Ole,
On May 5, 2011, at 6:49 AM, Ole Troan wrote:
> I'm on the fence with regards to this document. if this document is meant to
> be the RFC1122/1812 document for IPv6,
> I think we are too early in the deployment of IPv6 to have gathered enough
> experience with what works and what doesn't.
>
I'm on the fence with regards to this document. if this document is meant to be
the RFC1122/1812 document for IPv6,
I think we are too early in the deployment of IPv6 to have gathered enough
experience with what works and what doesn't.
as a profile of an IPv6 node though, it isn't too far off.
a
[Resend w/ correct link]
All,
This message starts a short 6MAN Working Group Last Call on advancing:
Title : IPv6 Node Requirements RFC 4294-bis
Author(s) : E. Jankiewicz, et al.
Filename: draft-ietf-6man-node-req-bis-09.txt
Pages
All,
This message starts a short 6MAN Working Group Last Call on advancing:
Title : IPv6 Node Requirements RFC 4294-bis
Author(s) : E. Jankiewicz, et al.
Filename: draft-ietf-6man-node-req-bis-09.txt
Pages : 30
Date
34 matches
Mail list logo
