In message <5201cce6.2040...@pacbell.net>, Eduardo Bonsi writes:
> Dear Noel and Mark,
>
> Thanks for your input!
>
> After thinking about the ipv6 network configuration pros and cons, I
> decided to go for the ULA for my internal network and use the /64
> creating static ips for my WAN. To get a set of ULA addresses I logged to:
>
> http://www.simpledns.com/private-ipv6.aspx
>
> All BIND configurations and Apache for the virtual hosts are working
> good so far. Ipv6 does connect direct using the OS X System Preferences
> Network Interface. I am going step by step and waiting to see if
> everything will be fine as the time runs. The good thing about ipv6 is
> that it free us to assign ips for every possible thing you can put your
> hands on out there. Mark, sorry, I did laugh when you said that my ISP
> should give me a /56 or /48. If with /64 I have plenty of addresses, I
> have no idea what I would do with /56 or /48. Probably I would open one
> ISP for myself and start to sell ips. Looks like we are thinking in
> gazillions now. That is very good! I am one happy cow now!
It's not about address other than having more than you will ever
need per subnet. It's about not having to think about the size of
a subnet. It's about using the same size subnet everywhere and
everyone in the world using the same sized subnets. IPv6 addresses
were made as big as they were so this was possible.
Alternatives to the the current 128 bit addresses used 64 bits of
addressing and variable sized subnets. Going to 128 bits and having
/64 bits per subnet was seen as a good use of addresses space as
it simplifies operational complexity. IPv6 nodes still need to
support variable sized subnets in case this decision ended up being
wrong in practice but it is hoped that we will never need to use
that capability except when testing.
You use a /64 per subnet. /60, /56, /52 and /48 give you 16, 256,
4096 and 65536 subnets to use respectively and are easily delegatable
in ip6.arpa as they fall on nibble boundaries. Those are per site
allocations.
The smallest ISP's get /32's.
Mark
> On 8/4/13 7:17 PM, Noel Butler wrote:
> > On Sun, 2013-08-04 at 13:28 -0700, Eduardo Bonsi wrote:
> >> Hello Everyone,
> >>
> >> I have some questions about ipV6 transition and DNS configuration!
> >>
> >> I am preparing to make my transition to a dual stack ipv4, ipv6 and I
> >> have some concerns in regards to the security of the network since ipv6
> >> do not have NAT. My ISP gave me a Global
> >> 2602:000:000:000:000:000:000:000/64 Range and I can just turn on ipV6 on
> >> the router and set the network to automatic on the computer and I am
> >> connected through what they call a SLAAC ipV6 automatic conf network,
> >> that runs using the machine MAC address in which I am not very happy to
> >> adopt. I well know there is a way to mask the MAC address to random
> >> addresses as a security measure but I am still not happy about it.
> >> Beside, there are all the BIND DNS configuration that needs to be routed
> >> or I am stack with a slow broke SLAAC connection that it works, but not
> >> to the level of the a DNS Server that I want to achieve. Therefore, as a
> >> network design after analyzing my options, I have decided to use the
> >> static ipv4, ipV6 deployment approach that uses my ipV6 with the 3 last
> >> bit of the ipv4 NAT addresses already in place. This static option does
> >> not expose the machine MAC addresses. However the addresses are directed
> >> connected through ipV6 bypassing the NAT environment. On BIND, the only
> >> change I have in the named.conf file is the,
> >>
> >> listen-on-v6 { any; };
> >>
> >
> > listen-on-v6 ::1 and your dns server ipv6 address
> >
> >> Therefore, here are my questions:
> >>
> >> 1. I am open to ideas or anything you think is best choosing the best
> >> internal network design for ipV6.
> >>
> >
> > Static IP assignments on your LAN, as far as your ISP is concerned they
> > will just route your /64 via your routers IP. sure you can do auto
> > assignments, but I think if they are servers its best to do static.
> >
> >> 2. Since this static ipV6 deployment lacks the non-rotatable NAT
> >> environment, what are the security measures to take on BIND in regards
> >> to the recursive issues on ipV6?
> >>
> >
> > with ipv6, no more do you have security by accident (NAT) if you have a
> > /64 your router will route for all, forget all the bad habits of the
> > lazy ipv4 days, now you need to configure access lists on your router,
> > but also play it safe and configure firewalls on each machine,
> > especially if they are winblows boxes
> >
> >
> >> 3. Are there any other security issues that should I considerate?
> >>
> >
> > Don't be over aggressive with filtering, you do not mention the OS, but
> > if its linux -
> >
> > ip6tables -P INPUT DROP
> > ip6tables -P OUTPUT ACCEPT
> > ip6tables -P FORWARD DROP
> >
> > ip6tables -A INPUT -i lo -j ACCEPT
> > ip6tables -A INPUT -s fe80::/10 -j ACCEPT
> > ip6tables -A INPUT -d ff00::/8 -j ACCEPT
> > ip6tables -A INPUT -p tcp -m tcp --dport 22 -m state --state INVALID,NEW
> > -j LOG
> > ip6tables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
> >
> > ... insert ACCEPT's for your lan and whatever other ipv6 addresses you
> > need with full access here...
> >
> > ip6tables -A INPUT -p udp -d you:ipv6:dns:server:address --dport 25 -j
> > ACCEPT
> > ip6tables -A INPUT -p tcp -d you:ipv6:dns:server:address --dport 25 -j
> > ACCEPT
> >
> >
> > and.. importantly..
> > ip6tables -A INPUT -p icmpv6 --icmpv6-type 1 -j ACCEPT # Destination
> > unreachable
> > ip6tables -A INPUT -p icmpv6 --icmpv6-type 2 -j ACCEPT # Packet too big
> > ip6tables -A INPUT -p icmpv6 --icmpv6-type 3 -j ACCEPT # Time exceeded
> > ip6tables -A INPUT -p icmpv6 --icmpv6-type 4 -j ACCEPT # Parameter
> > problem
> > ip6tables -A INPUT -s your:gateway:ip -p icmpv6 --icmpv6-type 135 -j ACCEPT
> > ip6tables -A INPUT -s your:gateway:ip -p icmpv6 --icmpv6-type 136 -j ACCEPT
> >
> > You *will* need the above accepts regardless since your default policy
> > is DROP, if not, you may find ipv6 reachable problems, in fact, you may
> > not even be able to connect outbound without types 135/136 (neighbour
> > discovery)
> >
> >
> >
> >
> >
> > _______________________________________________
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> > unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> >
>
>
> --
> Eduardo Bonsi
> System - Network Admin
> beart...@pacbell.net
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
