Re: Heads up - Plea for allocating a /8 to ISPs

Victor,

Yes, I miss the important constrain "in some case". :)

Actually, I'm worry about the situation like this:
(Assuming the new reserved space is 5.x.x.x/8)

Currently: (in some case)

          /---------------------------\
        <    ISP Backbone      >    non-RFC1918 can be routed in backbone,
so it includes 5.x,x,x/8
          \--------------------------/
            /                       \
[  MAN 1 ]       ...    [ MAN X]       RFC1918 may be routed in some MAN


Cheers!

Jin Yan Lin
China Telecom

On Fri, Nov 12, 2010 at 12:41 AM, Victor Kuarsingh <
[email protected]> wrote:

>  Jason,
>
> I would have to disagree with that position.  In our case, it would be
> exactly the opposite.  The non-RFC1918 block would replace public addresses,
> therefore the same class of security policy applies.
>
> Using RFC1918 (other then the other technical reasons given as to what it’s
> problematic) would require more uplifts of security polices, ACLs, and
> network related configuration.
>
> I think the points is it is provider by provider dependant.  If the provide
> historically used RFC1918 for addressing, then perhaps in that case it would
> be as you said, but this is definitely not true for providers that current
> supply public space to endpoints (until we run out of course).
>
> Regards,
>
> Victor
>
>
>
> On 12/11/10 12:24 AM, "Jason Lin" <[email protected]> wrote:
>
> hi,
>
> Considering currently security policies that have been deployed in the
> network, the new reserved /8 prefix may lead to not only re-design the
> security policies, but also reconfigure the related nodes which has high
> risk.
>
> so, my point is negative.
>
> Jin Yan Lin
> China Telecom
>
>
> On Fri, Nov 12, 2010 at 12:15 AM, Gert Doering <[email protected]> wrote:
>
> Hi,
>
> On Thu, Nov 11, 2010 at 04:18:49PM +0800, Rémi Després wrote:
> > But you won't be hurt if some others use this new /8 prefix.
>
> Sure.  Someone else might have a good use for a /22 that they can't
> get because the last /8 was taken away for NAT444 services.
>
> Especially content providers will need small bits of IPv4 space to
> provide content to large masses of not-yet-IPv6 capable eyeballs.
>
> Against this proposal.
>
> Gert Doering
>         -- NetMaster
> --
> did you enable IPv6 on something today...?
>
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279
> _______________________________________________
> v6ops mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> ------------------------------
> _______________________________________________
> v6ops mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

_______________________________________________
v6ops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/v6ops