Re: RFC-2472 IPV6CP extension

> in my analysis and past history, IPv6CP option for assigning address > space has been discussed and rejected (i guess i mentioned the history > in the draft). this partly because that this does not belong to > PPP layer. rough agreement at this point is to (1) use RA i

Re: a), b), c), d), or e)

Francis Dupont wrote: > > In your previous mail you wrote: > >> => I understand but I shan't support the c) option until the 5-tuple >> re-classifier monster is killed. > >In fact the c) option is not using the 5-tuple classifier. > > => in your question you didn't specify if c)

Re: a), b), c), d), or e)

Francis Dupont wrote: > > >For this case, if the providers have networks in which they use only >Diffserv, why not allow them to use the flow label with Diffserv? > > => they don't need this. This is your interpretation. This is needed wherever there is a Diffserv router which does M

Re: a), b), c), d), or e)

Robert Elz wrote: > > [...] > | That is because RFC 2460 appendix A, through the PRN rule and some others, > | excludes Diffserv. > > No, it doesn't allow diffserv type use of the flow label field. That's correct. > > | No. In fact it was in our scope, Brian and I, and those who su

Re: RFC-2472 IPV6CP extension

>I've read draft-itojun-ipv6-dialup-requirement-01.txt, >I thought that we must discuss IPV6CP options. in my analysis and past history, IPv6CP option for assigning address space has been discussed and rejected (i guess i mentioned the history in the draft). this partly b

RE: refocusing: what about the flow label?

I can live with this. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Christian Huitema > Sent: Thursday, September 06, 2001 3:34 PM > To: Brian E Carpenter; Michael Thomas > Cc: ipng > Subject: refocusing: what about the flow label? > > > I hope

refocusing: what about the flow label?

I hope that after three weeks of exchanges, everybody is convinced that we will not get any consensus on whether the best handling of QoS is diffserv, intserv, or maybe no QoS at all. Let's try to be practical. We have a simple problem to solve, the definition of the flow label in the IPv6 specifi

Re: a doubt on MTU discovery in IPv6

Pekka Savola wrote: > > Your confusion may be based on the difference that in IPv4, routers also > may fragment packets. IPv6 fragmentation is end-to-end, and you either > use minimum MTU 1280, or implement Path MTU Discovery (above). This makes me think about something strange in Path MTU Dis

RFC-2472 IPV6CP extension

Hi ALl, this is my first time to participate ipngwg. If I'm wrong, tell me please. If ipngwg did not discuss RFC-2472 IPV6CP, why don't you discuss RFC-2472 IPV6CP extension? Because current IPV6CP option is not enough to offer native IPv6 connectivity for ISP services. PPP has two merits fo

Re: a), b), c), d), or e)

Robert Elz wrote: ... > | I didn't mind working with the premise that the label space must not be > | statically divided. > > If there's been a proposal which avoids that, I must have missed it. > Where was that? > It's been hinted at in several messages; it will work if you can assert that

Re: a), b), c), d), or e)

Michael, to be precise it is not interior routers, but ISP border routers, that would reclassify. But it doesn't change the principle of what you say. Indeed, it is clear that users who wish to be protected against anthing beyond source/destination traffic analysis cannot use the proposed flow-l

Re: a), b), c), d), or e)

Francis Dupont writes: > In your previous mail you wrote: > >This entire controversy surrounds whether diffserv >networks which have interior routers do the >classification is legitimate. Considering that it >breaks a perfectly reasonable user desire -- >privacy -- I'd

Re: a), b), c), d), or e)

In your previous mail you wrote: > => I understand but I shan't support the c) option until the 5-tuple > re-classifier monster is killed. In fact the c) option is not using the 5-tuple classifier. => in your question you didn't specify if c) uses it or not. So I do not underst

Re: a), b), c), d), or e)

In your previous mail you wrote: >Since, with IP QoS, the QoS information is in the same class, relative >to privacy, >with the forwarding information, if one needs to apply full privacy to >QoS information, >it will apply the same criteria as for forwarding in

Re: a), b), c), d), or e)

In your previous mail you wrote: This entire controversy surrounds whether diffserv networks which have interior routers do the classification is legitimate. Considering that it breaks a perfectly reasonable user desire -- privacy -- I'd say that's a pretty good reason to quest

Re: Routing Header Considered Harmful

In your previous mail you wrote: >A flag will not, but how the flag would be set for hosts by default would >:-) > > => where in RFC 2460 you have read that. I am still looking for this kind > of statements and I can't find it. the spec talks about node. Hosts and

Re: a), b), c), d), or e)

In your previous mail you wrote: > => so you give up the appendix A of draft-conta-ipv6-flow-label-02.txt? > The diffserv flow label in proposition c) will be an extension of > the DS field with same kind of properties? Sure, it was included as FYI. => so the next version of

Re: Portmanteau reply Re: a), b), c), d), or e)

In your previous mail you wrote: Actually the diffserv architecture does not formally require MF classifiers and does not formally require them to be port/protocol based, although the 5tuple classifier is cited. => this is my concern: the door is open for stupidity. If somebody com