On Fri, Sep 6, 2013 at 9:23 PM, Tim Chown t...@ecs.soton.ac.uk wrote:
If #2, then perhaps this option needs a lifetime value? Unless the plan
is that a) who/whatever solves the problem statement in RFC 4076 will solve
this too, or b) that everyone needing this option will use stateful DHCPv6.
On Fri, Jun 14, 2013 at 2:19 PM, Tony Hain alh-i...@tndh.net wrote:
Focus on the real operational requirement (firewall functionality), then
make sure that the constraint automatically tracks evolution in firewall
functionality. Getting there leads to L4 in the first fragment, and
anything
On Thu, Jun 6, 2013 at 6:10 PM, Niall O'Reilly niall.orei...@ucd.ie wrote:
On 6 Jun 2013, at 04:26, Lorenzo Colitti wrote:
indeed, the letter of the policy above suggests that a /48 is
acceptable only in the case of extra large end sites
How do you read that into the extract you
On Thu, Jun 6, 2013 at 8:25 PM, Ted Lemon ted.le...@nominum.com wrote:
You should reread the text. It says sites that need _more_ than a /48
are extra large end sites.
Yes, Niall pointed that out to me. But the argument is the same, see my
reply to him.
On Thu, Jun 6, 2013 at 10:14 PM, Ted Lemon ted.le...@nominum.com wrote:
Sorry, but no. This is clearly spelled out in the policy which I quoted
earlier. Surely you're not saying that hearsay from an employee who happens
to work in the research group of an RIR is more authoritative than than
On Thu, Jun 6, 2013 at 10:56 PM, Ted Lemon ted.le...@nominum.com wrote:
Saying it says nothing of the sort without even citing it is not a
very convincing argument. If you want to state convincingly that it says
nothing of the sort, then why not start from the text I posted earlier and
On Fri, Jun 7, 2013 at 10:26 AM, Ted Lemon ted.le...@nominum.com wrote:
If you claim you gave a customer a /48 and the customer reports that
they are not allowed to exercise control over the use of that /48, then,
you have not, in fact, delegated authority over that /48 as you have
claimed
On Fri, Jun 7, 2013 at 10:54 AM, Ted Lemon ted.le...@nominum.com wrote:
What about the APNIC policy I cited a few emails ago? You have not
explained why you think it supports your point of view that using semantic
bits does not make it harder for ISPs to assign /48s to users.
The policy
On Wed, Jun 5, 2013 at 11:54 PM, Ted Lemon ted.le...@nominum.com wrote:
I still don't understand. What the above sentences seem to be saying is
that there are bits available for semantic prefix assignment because RIRs
assume /48 but users don't actually get /48. Is that your point?
No.
On Thu, Jun 6, 2013 at 1:11 AM, Ted Lemon ted.le...@nominum.com wrote:
On Jun 5, 2013, at 12:04 PM, Sander Steffann san...@steffann.nl wrote:
Keep in mind that RIRs won't give you extra address space though. If you
assign /56s to your users then that is what the RIR need-base calculations
On Wed, Jun 5, 2013 at 2:05 AM, Ted Lemon ted.le...@nominum.com wrote:
So even though we have solutions to allocate prefixes efficiently in
arbitrary home network topologies
We don't have solutions. We only have ideas on how solutions might be
built, and it must be noted that those ideas
On Wed, Jun 5, 2013 at 11:46 AM, Ted Lemon ted.le...@nominum.com wrote:
Be that as it may, ISPs all seem to be deploying networks with /56's to
the home, not /48's. Edge-rooted PD is an ops doc—no new protocol work is
required.
So then your argument should be RIRs should not plan to
On Wed, Jun 5, 2013 at 12:02 PM, Ted Lemon ted.le...@nominum.com wrote:
So then your argument should be RIRs should not plan to assign /48s to
subscribers because ISPs are assigning /56s to subscribers anyway?
No, it shouldn't. My argument is that the belief that no bits are
available
On Wed, Jun 5, 2013 at 12:20 PM, Ted Lemon ted.le...@nominum.com wrote:
So the point isn't that a /48 is a waste of space. It's that a /48 is
assumed, and because it is assumed, there are definitely bits available for
semantic prefix assignment.
I still don't understand. What the above
On Mon, Jun 3, 2013 at 11:59 PM, Vízdal Aleš ales.viz...@t-mobile.czwrote:
If I am reading this correctly, in the end this is riven by the fact
that existing boxes
can easily filter on addresses (although it will take a lot of filters),
but can not apply
ACLs to DSCPs or extension
On Tue, Jun 4, 2013 at 10:29 AM, Sheng Jiang shengji...@gmail.com wrote:
They are stealing from the consumer's flexibility to
provide (questionable) functionality to the provider.
What's the problem if the consumer get /48 as you want, and providers play
their 28 bits (bit 20~47)?
The
An unadopted draft does not an implementation (or a deployment!) make.
On Sun, Jun 2, 2013 at 4:05 AM, Tim Chown t...@ecs.soton.ac.uk wrote:
On 1 Jun 2013, at 13:42, Owen DeLong o...@delong.com wrote:
On Jun 1, 2013, at 5:58 AM, Ted Lemon ted.le...@nominum.com wrote:
On May 31, 2013, at
On Sun, Jun 2, 2013 at 3:51 PM, Ted Lemon ted.le...@nominum.com wrote:
This is trivially solved with PD at the PE router that gets the
delegation from the ISP. I thought you were talking about a multi-homed
topology. Also trivially solved, but might involve two edge routers each
with
On Mon, Jun 3, 2013 at 5:47 AM, Ralph Droms rdroms.i...@gmail.com wrote:
Yes, draft-baker-homenet-prefix-assignment describes non-hierarchical
assignment, in which all prefixes are delegates from a single server.
I'll resuscitate it, as it seems to be a useful reference for this
discussion.
On Mon, Jun 3, 2013 at 11:53 AM, Ted Lemon ted.le...@nominum.com wrote:
If your point is that zOSPF is a better solution, you may be right. If
your point is that hierarchical delegation within the homenet is better,
you would be wrong. The original discussion was about that question, not
On Fri, May 31, 2013 at 11:02 PM, bingxu...@gmail.com
bingxu...@gmail.comwrote:
[Qiong] I'm trying to answer this question from operator's aspect. When we
are trying to encode semantics e.g service type, subscriber type, etc., in
some flag, it should have the following features:
1) It should
On Thu, May 30, 2013 at 4:13 PM, Sheng Jiang jiangsh...@huawei.com wrote:
Yes, there is no intension to change ARIN’s policy at all. ARIN should
remain the current policy of assign IPv6 address block. But the network
providers, who has already get address block, can choose to use the
On Tue, Mar 30, 2010 at 5:03 AM, Mark Smith
i...@69706e6720323030352d30312d31340a.nosense.org wrote:
I'm happy with using /64s for PPPoE links. However, if the /127 draft is
accepted, then I'd want to be able to take advantage of them on
PPP/PPPoE sessions - if there is an approved mechanism
On Tue, Mar 30, 2010 at 4:00 AM, Mark Smith
i...@69706e6720323030352d30312d31340a.nosense.org wrote:
Apologies for that. Can we generalise the subject into non-64 bit
IIDs, as it also covers the /127 case, and nearly all the reasons for
non-/64s on LANs are the same as in the draft?
No,
On Thu, Mar 25, 2010 at 2:06 PM, Mark Smith
i...@69706e6720323030352d30312d31340a.nosense.org wrote:
I don't see anywhere it specifically says RFC4291 is to be updated, or
replacement text for the impacted section(s).
The header says updates 4291. But yes, there is no text that says what
On Fri, Mar 26, 2010 at 10:49 AM, Miya Kohno mko...@juniper.net wrote:
I'd say an adequate prefix length can be chosen based on operators
policy. (/64, /112, etc.)
But as for the draft, more than two routers is out of the scope of the
document.
Agreed. I think the draft is explicitly not
On Thu, Mar 25, 2010 at 2:53 AM, Mark Smith
i...@69706e6720323030352d30312d31340a.nosense.org wrote:
One should note that [ADDRARCH] specifies universal/local bits (u/g),
which are the 70th and 71st bits in any address from non-000/3 range.
When assigning prefixes longer than 64 bits,
27 matches
Mail list logo
